В этом уроке разберём настройку безопасности Jenkins по-взрослому: откуда брать пользователей, как раздавать права через матрицу и Role Strategy, как не отдать всем admin и почему агенты надо держать на расстоянии от контроллера. Материал актуален на 2026 год - текущая LTS это 2.541.1, под Java 17 или 21.
Аутентификация: кто ты такой
Безопасность в Jenkins состоит из двух независимых вопросов. Первый - аутентификация (Security Realm): кто пользователь и как он доказывает свою личность. Второй - авторизация: что этому пользователю разрешено. Их настраивают раздельно в Manage Jenkins -> Security, и путать их нельзя.
Начнём с источников пользователей. В реальной jenkins настройке встречаются четыре варианта.
- Встроенная база Jenkins (Jenkins' own user database). Аккаунты лежат локально, пароли хэшируются. Годится для лаборатории, маленькой команды или начального этапа. В проде на десятки людей превращается в боль: нет централизованного управления, увольнение человека не отзывает доступ автоматически.
- LDAP / Active Directory. Пользователи и группы берутся из корпоративного каталога. Уволили человека в AD - он теряет доступ к Jenkins без твоего участия. Это стандарт для классического энтерпрайза.
- SSO через OIDC / SAML. Современный путь: плагин oic-auth подключает Jenkins к Keycloak, Okta, Google или Azure Entra ID. Логин идёт через единый провайдер, поддерживаются группы и 2FA на стороне IdP. На 2026 год для новых установок это рекомендуемый вариант.
- Делегирование контейнеру - реже, для специфичных сценариев reverse-proxy.
Авторизация: матрица прав и jenkins authorization
Аутентификация сказала "это Маша". Теперь решаем, что Маше можно. За это отвечает Authorization. Худший выбор - "Anyone can do anything" и "Legacy mode": их в проде быть не должно. Рабочие стратегии такие.
Matrix-based security - глобальная таблица. Строки это пользователи и группы, столбцы - права (Overall/Read, Job/Build, Job/Configure, Run/Delete и так далее). Ставишь галочки на пересечениях. Просто и наглядно, но права действуют на весь Jenkins сразу: нельзя дать человеку конфигурировать только свои джобы.
Project-based Matrix Authorization - расширение матрицы. Кроме глобальной таблицы появляется секция Authorization в настройках каждой джобы и папки. Глобально даёшь всем Overall/Read, а права на конкретные проекты раздаёшь точечно. Уже похоже на нормальный jenkins rbac, но при сотне джоб ты утонешь в ручных галочках.
Обе матрицы живут в плагине matrix-auth. Включается всё там же, в Manage Jenkins -> Security -> Authorization.
Jenkins Role Strategy: роли вместо галочек
Когда проектов и людей много, ручная матрица не масштабируется. Тут на сцену выходит jenkins role strategy - плагин Role-based Authorization Strategy. Идея простая и знакомая всем по RBAC: ты описываешь роли (наборы прав) один раз, а потом назначаешь людей на роли. Сменился состав команды - правишь назначение роли, а не сотню галочек.
Плагин даёт три типа ролей:
- Global roles - глобальные. Задают Overall, Agent, Job, Run, View, SCM на весь инстанс. Тут живёт admin и базовая роль authenticated с одним лишь Overall/Read.
- Item roles (раньше project roles) - привязаны к джобам и папкам по регулярному выражению на имя. Создаёшь роль team-billing с паттерном billing-.* и даёшь ей Job/Build, Job/Configure. Все джобы с префиксом billing- автоматически попадают под эту роль.
- Agent roles - права на конкретные агенты, тоже по regex на имя ноды.
На 2026 год Role Strategy полноценно описывается через Configuration as Code, и это правильный способ - права лежат в git, а не накликиваются мышкой. Вот рабочий фрагмент JCasC:
Код: Выделить всё
jenkins:
authorizationStrategy:
roleBased:
roles:
global:
- name: "admin"
description: "Полный доступ, держим у 1-2 человек"
permissions:
- "Overall/Administer"
entries:
- user: "alice"
- name: "authenticated"
description: "Любой залогиненный видит дашборд"
permissions:
- "Overall/Read"
- "View/Read"
entries:
- group: "authenticated"
items:
- name: "team-billing"
description: "Команда биллинга в своей папке"
pattern: "billing/.*"
permissions:
- "Job/Read"
- "Job/Build"
- "Job/Configure"
- "Run/Replay"
entries:
- group: "billing-devs"
agents:
- name: "linux-builders"
pattern: "linux-.*"
permissions:
- "Agent/Build"
entries:
- group: "billing-devs"
CSRF, анонимы и изоляция агентов
Права роздали - закрываем остальные фланги.
Защита от CSRF. В современных версиях Jenkins crumb-токен против межсайтовой подделки запросов включён по умолчанию, и выключать его нельзя. Если внешняя система не может дёрнуть API - выдай ей API token конкретного пользователя, а не отключай CSRF на весь инстанс.
Анонимный доступ. Решай осознанно, что видит незалогиненный пользователь. Для внутреннего прода обычно не даёшь анониму вообще ничего - даже Overall/Read. Тогда без логина человек видит только форму входа.
Изоляция агентов от контроллера. Ключевой момент, который часто упускают. Контроллер не должен запускать сборки сам - на нём лежат креды и конфиги всего Jenkins. Поэтому:
- Ставь число исполнителей на встроенной ноде в 0, чтобы джобы физически не выполнялись на контроллере.
- Включи Agent -> Controller Access Control - подсистему, которая ограничивает, какие команды агент может слать контроллеру.
- В проде агенты эфемерные: в Kubernetes каждый билд поднимает свой одноразовый pod, который умирает после сборки. Скомпрометированная сборка не живёт дальше своего pod.
Код: Выделить всё
pipeline {
agent {
kubernetes {
yaml '''
apiVersion: v1
kind: Pod
spec:
containers:
- name: maven
image: maven:3.9-eclipse-temurin-21
command: ["sleep"]
args: ["infinity"]
'''
}
}
stages {
stage('Build') {
steps {
container('maven') {
sh 'mvn -B clean verify'
}
}
}
}
}
Типичные грабли
- Всем admin. Это разработчику дали Overall/Administer "чтобы не мешало". Administer - это удалённое выполнение кода на контроллере и чтение всех секретов. Держи его у одного-двух человек, остальным - точечные права. Это самая частая дыра в jenkins безопасности.
- Сначала включить безопасность, потом подумать о доступе себе. Классика: переключил Authorization, нажал Save и выкинул сам себя. Лечится правкой config.xml на диске (поставить временно unsecured) и рестартом - но лучше до сохранения убедиться, что твой аккаунт точно admin.
- Оставленный анонимный Read в проде. Анониму не нужно видеть имена джоб, переменные окружения и логи сборок - там утекают пути, хосты и иногда токены.
- Исполнители на контроллере. Ноль исполнителей на built-in node - не паранойя, а базовая гигиена.
- Сравни с соседями. У GitLab CI и GitHub Actions безопасность встроена в платформу: роли наследуются от репозитория/группы, секреты и OIDC из коробки. В Jenkins всё это собираешь сам из плагинов - больше гибкости, но и больше ответственности за конфигурацию.
- Подними Jenkins локально, в Security выбери Jenkins' own database и сними галочку саморегистрации. Заведи трёх пользователей: admin, dev, viewer.
- Включи Matrix-based security. Дай authenticated только Overall/Read, admin - Administer. Зайди под dev и убедись, что джобы он не запускает.
- Поставь плагин Role-based Authorization Strategy, переключи стратегию на него. Создай глобальную роль developer и item-роль на папку по regex.
- Вынеси всю конфигурацию ролей в JCasC-файл и перезапусти Jenkins из него - проверь, что права восстановились из кода.
- Поставь число исполнителей на built-in node в 0 и убедись, что сборки уходят на агент.
- Чем аутентификация (Security Realm) отличается от авторизации, и почему их настраивают отдельно?
- В чём разница между global, item и agent ролями в Role Strategy, и какую роль ты дашь команде на свою папку?
- Почему на контроллере выставляют ноль исполнителей и что даёт Agent -> Controller Access Control?
- Какие три-четыре галочки ты проверишь первым делом, выставляя Jenkins в прод?
Безопасный Jenkins держится на трёх китах: проверенный источник пользователей (LDAP или OIDC в проде), грамотная авторизация (Role Strategy с принципом наименьших привилегий вместо тотального admin) и изоляция контроллера от сборок (эфемерные агенты, ноль исполнителей на built-in node). Описывай всё это через JCasC, чтобы права жили в git, и включи аудит. Тогда твой Jenkins перестанет быть открытой дверью и станет нормальным боевым инструментом.
