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 на хост-машині.
Виконавець - це слот для виконання завдань; фактично, це потік в агенті. Кількість виконавців на вузлі визначає кількість паралельних завдань, які можуть бути виконані на цьому вузлі одночасно. Іншими словами, це визначає кількість паралельних етапів Pipeline, які можуть виконуватися на цьому вузлі одночасно.
Секрети 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 id. Загальні ідентифікатори ключів включають:
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
