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

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

При работе с многими проектами, не все могут (должны) иметь доступ к другим учаскам кода или проекта. Та это и не нужно, нужно какое-то разграничение, чтобы работники из одной тимы не могли получить доступ к задачам, workspace задач других ребят. Т.е. чтобы каждый в рамках своего проекта мог делать в jenkins чего душа пожелает, но не смог даже глазком взглянуть на исходные коды проекта, на которые ему смотреть не положено.

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

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

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

Установка Jenkins в Unix/Linux

Я описывал данное действие тут:

Установка Jenkins в Unix/Linux

Вот еще полезное чтиво по теме:

Мониторинг места на сервере через Jenkins

Настройка темы для Jenkins

Исправляем ошибку «ERROR: anonymous is missing the Overall/Read permission» в Jenkins

Изменить/Поменять пароль для пользователя Jenkins

Изменить порт для Jenkins в Unix/Linux

Работа с jenkins через консоль (CLI) в Unix/Linux

Переходим к разграничению прав доступа в jenkins.

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

Начнем с создания пользователя. Открываем УРЛ с дженкинсом, переходим в «Настроить Jenkins» -> «Configure Global Security» и выставляем следующее:

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.

Создаем пользователей:

Собственно, юзвери созданы уже. Один логин для каждой тимы разрабов.

Разграничение доступа на уровне ОС будет реализовано посредством нод, каждая из которых будет работать под пользователем ОС, выделенным под конкретную команду.

Для начала, отключаем master: Настроить Jenkins -> Управления Средами сборки -> мастер -> Настроить, где устанавливаем «Количество процессов-исполнителей=0»:

Настройка нод в дженкинс

Нажимаем на сохранить и нажимаем «вернуться к списку» для создания 2-х узлов:

Создание и настройка узла для сборки в дженкинс

В поле «Host key Verification Strategy» можно изменить на «Non verifying Verification Strategy» и тогда не будет проверяться ключ для хоста. В поле «Credentials» — создаем юзера с паролем:

креденшелы для юзера в дженкинс

И потом выбираем его из списка. Таким же образом, создаем узел для 2-й команды….

Я создал узлы созданы и работоспособны:

Созданные узлы в дженкинс

Определим группы задач, выполняемых на каждой из нод. Для этого нам потребуется плагин «Job Restrictions Plugin», после его установки появится возможность определить класс задач, которые будут выполняться на той или иной ноде.

Заходим в редактирование узлами и например, делаем выполнение по регулярному выражению:

Настройка Job Restrictions Plugin для проекта

Небольшой ньюанс, в данном примере, задачи, созданные до конфигурирования нод, будут привязаны к мастер-ноде, чтобы это изменить, нужно в соответствующем каталоге создать новую задачу, тогда происходит волшебство и задачи начинают запускаться на нужных нодах.

Полученный результат, следующий:

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

На этом все, статья «Разграничение прав доступа в Jenkins» завершена.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *