Разграничение прав доступа в Jenkins

В свое время перерыл много интернета, но подходящего решения найти не удалось. Решил поделиться рецептом решения.

Задача: Организовать доступ к jenkins участникам разных команд разработки, таким образом, чтобы участники одной команды не имели доступа ни к задачам, ни к workspace задач других команд. Т.е. чтобы каждый в рамках своего проекта мог делать в jenkins чего душа пожелает, но не смог даже глазком взглянуть на исходные коды проекта, на которые ему смотреть не положено.

Решение было не то, чтобы нагуглено, но навеяно тщетными поисками подходящего способа.

Далее предполагается, что jenkins будет работать в окружении Linux, в Windows не проверялось.

Необходимо было решить две проблемы:

1. В стандартной поставке отсутствуют средства для группировки задач, и, соответственно, нельзя раздать права группе пользователей на группу задач.
2. Даже если решить первую проблему, останется вторая — пользователи могут иметь доступ к workspace задач на уровне операционной системы. Например, без особых затруднений можно выполнить bash-script, в котором заархивировать весь домашний каталог jenkins и отправить себе же почтой.

Итак, описание решения.

1. Ставим jenkins. У меня Fedora, так что:
   
   • dnf install jenkins
   • sudo service jenkins start
   • после чего наблюдаем на localhost:8080
   
   
2. Создание пользователей Jenkins
   
   • Идем в раздел настроек Jenkins «Configure Global Security», где выставляем нужные галочки:
     
     
   • Пока выдадим анонимному пользователю все права
   • После сохранения настроек, в шапке появляется ссылка «Зарегистрироваться», регистрируем администратора Jenkins и нужных пользователей (участников команд разработки)
   • Окончательно настраиваем глобальные права пользователей, а именно: администратору даем полный доступ, обычным пользователям — только на чтение, а анонимному пользователю запрещаем всё:
     
     
   
   
3. Устанавливаем плагин (Управление плагинами) «CloudBees Folders Plugin». Плагин позволяет создавать каталоги — группы задач, произвольной вложенности. На каталоги можно выдавать права конкретным пользователям. Далее:
   
   • Под администратором создаем задачу типа «Folder», по одной задаче типа «Folder» на команду разработки, например:
     
     
     
     
   • Настраиваем права доступа к каждому из каталогов верхнего уровня: заходим в каталог и выбираем «Configure»→«Enable project-based security».
     
     
     
   • Итак, на глобальном уровне мы запретили пользователям создавать и просматривать задачи, соответственно, никто, кроме администратора, не может создавать задачи верхнего уровня, но внутри каталогов пользователи, у которых есть соответствующие права, ничем не ограничены. Проверяем видимость каталогов, заходим под одним из пользователей:
     
     
     
     Видим, что доступен только один проект, на который выданы права. Внутри каталога, можно делать всё, например, создавать новые задачи:
     
     
     
     Полдела сделано.
     
   
   
4. Далее нам понадобятся пользователи ОС, создадим их (не буду приводить тут примеров, гугл всегда подскажет). Сейчас рассматриваем вариант установки, когда Jenkins работает на той же машине, где и будут производиться сборки. Нашим пользователям ОС нужен будет доступ по ssh, должен работать sshd. Итак, пользователи созданы: jenkins1 и jenkins2, соответственно для каждой команды разработчиков.
   
5. Разграничение доступа на уровне ОС будет реализовано посредством нод, каждая из которых будет работать под пользователем ОС, выделенным под конкретную команду. Настраиваем ноды.
   
   • Сначала отключим master: Настроить Jenkins → Управления Средами сборки → мастер → Настроить, где устанавливаем «Количество процессов-исполнителей=0».
     
     
     
   • Создаем два новых узла (ноды), под каждый проект.
     
     
     
   • Тут нам важно указать количество воркеров, корень удаленной ФС, хост и учетные данные (Credentials) пользователя ОС, с которыми будет устанавливаться ssh сеанс, их мы создаем в системной области, чтобы обычным пользователям они были недоступны.
     
     
     
   • Итак, ноды созданы и работоспособны:
     
     
     
   
   
6. Определим группы задач, выполняемых на каждой из нод. Для этого нам потребуется плагин «Job Restrictions Plugin», после его установки появится возможность определить класс задач, которые будут выполняться на той или иной ноде, например, по регулярному выражению:
   
   
   
   Небольшой ньюанс, в данном примере, задачи, созданные до конфигурирования нод, будут привязаны к мастер-ноде, чтобы это изменить, нужно в соответствующем каталоге создать новую задачу, тогда происходит волшебство и задачи начинают запускаться на нужных нодах.
   

Итого, имеем:

1. Разделение доступа между командами на уровне ОС.
2. Разделение доступа между командами на уровне Jenkins.
3. Возможность дать доступ пользователям к рабочим каталогам соответствующих пользователей ОС, чтобы они самостоятельно могли что-либо установить/настроить/скопировать.
4. Один инстанс Jenkins на всех, что значительно упрощает администрирование и поддержание в актуальном состоянии.
5. При необходимости, можно очень просто добавить ещё ноды, если потребуется. Решение будет уже обкатано.

Надеюсь, этот рецепт будет полезен, спасибо за внимание!