Basic Jenkins Information
Доступ
Ім'я користувача + Пароль
Найпоширеніший спосіб входу в Jenkins - це за допомогою імені користувача або пароля.
Cookie
Якщо вкрадено авторизований cookie, його можна використовувати для доступу до сеансу користувача. Зазвичай cookie називається JSESSIONID.*. (Користувач може завершити всі свої сеанси, але спочатку йому потрібно дізнатися, що було вкрадено cookie).
SSO/Плагіни
Jenkins може бути налаштований за допомогою плагінів для доступу через сторонній SSO.
Токени
Користувачі можуть генерувати токени, щоб надавати доступ до додатків для імітації їх через CLI або REST API.
SSH-ключі
Цей компонент надає вбудований SSH-сервер для Jenkins. Це альтернативний інтерфейс для Jenkins CLI, і команди можна викликати цим способом за допомогою будь-якого SSH-клієнта. (З документації)
Авторизація
У /configureSecurity можна налаштувати метод авторизації Jenkins. Є кілька варіантів:
Будь-хто може робити все: Навіть анонімний доступ може адмініструвати сервер
Режим спадщини: Те ж саме, що і в Jenkins <1.164. Якщо у вас є роль "адміністратор", ви отримаєте повний контроль над системою, і інакше (включаючи анонімних користувачів) ви отримаєте доступ на читання.
Залогінені користувачі можуть робити все: У цьому режимі кожен залогінений користувач отримує повний контроль над Jenkins. Єдиний користувач, який не отримає повний контроль, - це анонімний користувач, який отримує лише доступ на читання.
Безпека на основі матриці: Можна налаштувати, хто може робити що в таблиці. Кожен стовпець представляє дозвіл. Кожен рядок представляє користувача або групу/роль. Це включає спеціального користувача 'анонімний', який представляє неаутентифікованих користувачів, а також 'аутентифікований', який представляє всіх аутентифікованих користувачів.
Стратегія авторизації на основі матриці, заснована на проекті: Цей режим є розширенням до "Безпеки на основі матриці", яке дозволяє додатково визначати матрицю ACL для кожного проекту окремо.
Стратегія на основі ролей: Дозволяє визначати авторизації за допомогою стратегії на основі ролей. Керуйте ролями в
/role-strategy.
Область безпеки
У /configureSecurity можна налаштувати область безпеки. За замовчуванням Jenkins включає підтримку кількох різних областей безпеки:
Делегувати контейнеру сервлетів: Для делегування аутентифікації контейнеру сервлетів, що працює з контролером Jenkins, таким як Jetty.
Власна база даних користувачів Jenkins: Використовуйте власне вбудоване сховище даних користувачів Jenkins для аутентифікації замість делегування до зовнішньої системи. Це увімкнено за замовчуванням.
LDAP: Делегувати всю аутентифікацію на налаштований сервер LDAP, включаючи користувачів та групи.
База даних користувачів/груп Unix: Делегує аутентифікацію до бази даних користувачів рівня ОС Unix на контролері Jenkins. Цей режим також дозволить повторне використання груп Unix для авторизації.
Плагіни можуть надавати додаткові області безпеки, які можуть бути корисними для включення Jenkins у існуючі системи ідентифікації, такі як:
Вузли, Агенти та Виконавці Jenkins
Визначення з документації:
Вузли - це машини, на яких працюють агенти збірки. Jenkins відстежує кожен приєднаний вузол для дискового простору, вільного тимчасового простору, вільного обміну, часу/синхронізації годинника та часу відповіді. Вузол видаляється з лінії, якщо будь-які з цих значень виходять за налаштований поріг.
Агенти керують виконанням завдань від імені контролера Jenkins за допомогою виконавців. Агент може використовувати будь-яку операційну систему, яка підтримує Java. Інструменти, необхідні для збірок та тестів, встановлені на вузлі, де працює агент; їх можна встановити безпосередньо або в контейнері (Docker або Kubernetes). Кожен агент фактично є процесом з власним PID на хост-машині.
Виконавець - це слот для виконання завдань; фактично, це потік в агенті. Кількість виконавців на вузлі визначає кількість одночасних завдань, які можуть бути виконані на цьому вузлі одночасно. Іншими словами, це визначає кількість одночасних стадій конвеєра, які можуть виконуватися на цьому вузлі одночасно.
Секрети Jenkins
Шифрування Секретів та Облікових записів
Визначення з документації: Jenkins використовує AES для шифрування та захисту секретів, облікових записів та відповідних ключів шифрування. Ці ключі шифрування зберігаються в $JENKINS_HOME/secrets/ разом із головним ключем, який використовується для захисту цих ключів. Цей каталог слід налаштувати так, щоб лише користувач операційної системи, під яким працює контролер Jenkins, мав доступ на читання та запис до цього каталогу (тобто значення chmod 0700 або використання відповідних атрибутів файлу). Головний ключ (іноді називається "ключем шифрування ключа" в криптожаргоні) зберігається незашифрованим на файловій системі контролера Jenkins в $JENKINS_HOME/secrets/master.key, що не захищає від нападників з прямим доступом до цього файлу. Більшість користувачів та розробників будуть використовувати ці ключі шифрування опосередковано через API Secret для шифрування загальних секретних даних або через API облікових записів. Для цікавих криптографів, Jenkins використовує AES у режимі ланцюжка шифрування блоків (CBC) з заповненням PKCS#5 та випадковими IV для шифрування екземплярів CryptoConfidentialKey, які зберігаються в $JENKINS_HOME/secrets/ з ім'ям файлу, що відповідає їх ідентифікатору CryptoConfidentialKey. Загальні ідентифікатори ключів включають:
hudson.util.Secret: використовується для загальних секретів;com.cloudbees.plugins.credentials.SecretBytes.KEY: використовується для деяких типів облікових записів;jenkins.model.Jenkins.crumbSalt: використовується механізмом захисту від CSRF; а
Доступ до облікових даних
Облікові дані можуть бути обмежені глобальними постачальниками (/credentials/), які можуть бути доступні будь-якому налаштованому проекту, або можуть бути обмежені для конкретних проектів (/job/<project-name>/configure) і, отже, доступні лише з конкретного проекту.
Згідно з документацією: Облікові дані, які знаходяться в межах видимості, стають доступними для конвеєра без обмежень. Щоб запобігти випадковому розголошенню в журналі збірки, облікові дані маскуються від звичайного виводу, тому виклик env (Linux) або set (Windows), або програми, які друкують своє середовище або параметри, не розкриють їх в журналі збірки користувачам, які інакше не мали б доступу до облікових даних.
Тому для витягування облікових даних зловмиснику потрібно, наприклад, закодувати їх у base64.
Посилання
Last updated
