Как «озадачить» всех инженеров и не перемудрить с правами доступа. Опыт Cloud4Y

Наша компания постепенно расширяется, у нас работает всё больше инженеров. А когда их много, надо как-то распределять права и доступы. Почему это важно? Попробую объяснить на примере.

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

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

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

Так как мы являемся корпоративным облачным провайдером, работающим в том числе и с чувствительной информацией, то обязаны соответствовать большому количеству жестких требований со стороны ФСБ, ФСТЭК и других организаций. Поэтому вопрос доступов и прав чётко регламентирован. Доступы к системам со скриптами у нас имеют самые надёжные технические специалисты. Но не лишать же из-за этого возможности работать со скриптами всех остальных! Тем более что такая необходимость иногда возникает.

Этот вопрос мы решили простым и логичным путём: перевели все скрипты в Gitlab, и через include добавляем логин и пароль из файла, который лежит в каталоге с доступом только по root. Скрипты запускает cron с правами суперпользователя. У обычного пользователя есть доступ только на чтение скрипта, он не может выполнять и редактировать его.

Схема выглядит примерно так:

1. Скрипт переделываем на include учётных данных из файла.

2. Папку со скриптом пушим в Gitlab (чтобы не копировать ручками в GItLab).

3. Далее, используя стандартные средства CI\CD, деплоим наши изменения куда надо.

Теперь, если пользователю нужно отредактировать скрипт, он действует следующим образом:

1. Делает клон репозитория с dev ветки (оно у нас смотрит на тест) в свою тестовую среду или в дополнительную ветку.

2. Производит отладку с использованием своих учетных данных.

3. Выполняет тестирование, убеждаясь в корректной работе скрипта.

4. Далее вливает изменения из своей ветки в основную dev. Если всё хорошо и всё работает как надо, отправляется merge-request для master ветки.

5. А дальше code-review, и, в случае успеха, заливка в master ветку, деплой на сервер.

При следующем запуске по крону исполняться будет уже изменённый скрипт. В результате мы получаем версионность скрипта и автоматический деплой, что не только стильно/модно/молодёжно, но и банально удобно. Да, по сути мы внедрили CI/CD для более разумного подхода к работе со скриптами.

Немного кода

Если вам интересно, как это реализовано на практике, то ниже — небольшая инструкция. Рассчитываем, что читатель более-менее понимает, о чём идёт речь.

Ставим клиент git на сервер (в нашем случае это CentOS):

yum -y install https://packages.endpoint.com/rhel/7/os/x86_64/endpoint-repo-1.7-1.x86_64.rpm
yum install git 

В gitlab создаём пользователя gitlab_scripts, добавляем ssh-ключ пользователя, который будет заливать в git (root). Создаём репозиторий в git и делаем в него push папки с текущим скриптом от пользователя root:

git init
remote add origin ssh://git@gl.mysite.ru/gitlab_scripts/test.git
git add .
git commit -m "Initial commit"
git push -u origin master 

Ставим на сервер GitLabRunner

curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh" | sudo bash
export GITLAB_RUNNER_DISABLE_SKEL=true; sudo -E yum install gitlab-runner 

В GitLab переходим во вкладу Admin Area — Runner, и оттуда копируем token shared runner’a (либо можно создать отдельный runner и добавлять его на каждый проект).

Регистрируем раннер, выполняем:

gitlab-runner register

Вводим token и адрес сервера, добавляем понятное имя, тег и выбираем excecutor (в нашем случае shell). Командой gitlab-runner list проверяем, что runner добавился.

Генерируем ключ ssh для пользователя, из-под которого работает gitlab-runner, чтобы он мог делать pull с репозитория на сервер без ввода пароля.

Добавляем группу gitlab-runner владельцем папки:

 chown -R :gitlab-runner test2

Добавляем права:

 chmod 775 -R test2

Создаем пайплайн:

.gitlab-ci.yml
build:
     script:
        -  rsync -avh --delete --exclude=.git ./ /test2/

Заливаем в git:

git add .
git commit -m "add ci"
git push -u origin master

Вот и всё. По такой схеме будет работать автоматический деплой на сервер при любом коммите в репозиторий. Есть идеи, как можно было сделать это иначе? Давайте обсудим.