Разграничение прав доступа в Jenkins
При работе с многими проектами, не все могут (должны) иметь доступ к другим учаскам кода или проекта. Та это и не нужно, нужно какое-то разграничение, чтобы работники из одной тимы не могли получить доступ к задачам, workspace задач других ребят. Т.е. чтобы каждый в рамках своего проекта мог делать в jenkins чего душа пожелает, но не смог даже глазком взглянуть на исходные коды проекта, на которые ему смотреть не положено.
Необходимо было решить две проблемы:
- В стандартной поставке отсутствуют средства для группировки задач, и, соответственно, нельзя раздать права группе пользователей на группу задач.
- Даже если решить первую проблему, останется вторая — пользователи могут иметь доступ к workspace задач на уровне операционной системы. Например, без особых затруднений можно выполнить bash-script, в котором заархивировать весь домашний каталог jenkins и отправить себе же почтой.
Итак, описание решения.
Установка Jenkins в Unix/Linux
Я описывал данное действие тут:
Установка Jenkins в Unix/Linux
Вот еще полезное чтиво по теме:
Мониторинг места на сервере через Jenkins
Исправляем ошибку «ERROR: anonymous is missing the Overall/Read permission» в Jenkins
Изменить/Поменять пароль для пользователя Jenkins
Изменить порт для Jenkins в Unix/Linux
Работа с jenkins через консоль (CLI) в Unix/Linux
Переходим к разграничению прав доступа в jenkins.
Разграничение прав доступа в Jenkins
Начнем с создания пользователя. Открываем УРЛ с дженкинсом, переходим в «Настроить Jenkins» -> «Configure Global Security» и выставляем следующее:
Выставляем все как у меня, назначаем всем анонимным пользователям все права (потом уберем это). Нажимаем на «Сохранить» и после этого, в шабке сайта появится кнопка «Зарегистрироваться». Регистрируем админа для Jenkins и юзеров для проектов. Назначаем «admin» юзеру полный доступ, а для других пользователей — только чтение. Для ананимусов — вообще убираем все, т.е запрещаем все. Сново открываем УРЛ с дженкинсом, переходим в «Настроить Jenkins» -> «Configure Global Security» и выставляем пермишены:
Сейчас, нужно установить плагин (CloudBees Folders Plugin) который позволит создать папки — группы задач, произвольной вложенности. На каталоги можно выдавать права конкретным пользователям. И так, открываем УРЛ с дженкинсом, переходим в «Настроить Jenkins» -> «Управление плагинами» и переходим во вкладку «Дополнительно». Скачиваем самую последнюю версию плагина и загружаем его в дженкинс.
Под админ-юзером, нужно создать задачу типа «Folder»( одна задача на тиму). Открываем «Создать Item» -> прописываем имя и выбираем «Folder» функцию, после чего — жмем на «OK». Находим поле Properties и под ним, ставим галочку над «Enable project-based security». Нужно добавить пользователя и назначить права. Должно получится что-то типа:
Итак, на глобальном уровне я ограничил пользователей создавать и просматривать задачи, соответственно, никто, кроме администратора, не может создавать задачи верхнего уровня, но внутри каталогов пользователи, у которых есть соответствующие права, ничем не ограничены. Проверяем видимость каталогов, заходим под одним из пользователей:
Как видно, для этого пользователя доступен Project_for_command_1 проекта. Внутри проекта можно будет создавать джобы (об этом позже), а сейчас — пол дела сделано!
Идем далее, сейчас стоит создать пользователей ОС. Я рассматрю вариант установки, когда Jenkins работает на той же машине, где и будут производиться сборки. Нашим пользователям ОС нужен будет доступ по ssh, должен работать sshd.
Создаем пользователей:
# useradd jenkins1 -m && passwd jenkins1 # useradd jenkins2 -m && passwd jenkins2
Собственно, юзвери созданы уже. Один логин для каждой тимы разрабов.
Разграничение доступа на уровне ОС будет реализовано посредством нод, каждая из которых будет работать под пользователем ОС, выделенным под конкретную команду.
Для начала, отключаем master: Настроить Jenkins -> Управления Средами сборки -> мастер -> Настроить, где устанавливаем «Количество процессов-исполнителей=0»:
Нажимаем на сохранить и нажимаем «вернуться к списку» для создания 2-х узлов:
В поле «Host key Verification Strategy» можно изменить на «Non verifying Verification Strategy» и тогда не будет проверяться ключ для хоста. В поле «Credentials» — создаем юзера с паролем:
И потом выбираем его из списка. Таким же образом, создаем узел для 2-й команды….
Я создал узлы созданы и работоспособны:
Определим группы задач, выполняемых на каждой из нод. Для этого нам потребуется плагин «Job Restrictions Plugin», после его установки появится возможность определить класс задач, которые будут выполняться на той или иной ноде.
Заходим в редактирование узлами и например, делаем выполнение по регулярному выражению:
Небольшой ньюанс, в данном примере, задачи, созданные до конфигурирования нод, будут привязаны к мастер-ноде, чтобы это изменить, нужно в соответствующем каталоге создать новую задачу, тогда происходит волшебство и задачи начинают запускаться на нужных нодах.
Полученный результат, следующий:
- Добился розделения пермищенов между тимами на уровне ОС.
- Добился разделения прав между тимами на уровне Jenkins.
- Возможность дать доступ пользователям к рабочим каталогам соответствующих пользователей ОС, чтобы они самостоятельно могли что-либо установить/настроить/скопировать.
- Один инстанс Jenkins на всех, что значительно упрощает администрирование и поддержание в актуальном состоянии.
- При необходимости, можно очень просто добавить ещё ноды, если потребуется.
На этом все, статья «Разграничение прав доступа в Jenkins» завершена.