Как настроить деплой в Gitlab CI, чтобы разработчик не получил доступ на хост?

Question

[StopDesign]

Хочу настроить сборку, тестирование и деплой через GitLab.
Условная схема пайплайна выглядит примерно так:


Таск deploy_staging запускается автоматически.
Таск deploy_prod могут запустить только определенные юзеры.

Для хранения и передачи секретов/настроек в пайплайн и на сервер используется Hashicorp Vault.

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

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

В системах, где деплойный конфиг скрыт от разработчика, можно задать какие-то условия, которые разрешают деплой на продакшн при определенных условиях (имя ветки, имя инициатора деплоя). В GitLab все параметры попадают в переменные окружения, их можно вывести в логи, посмотреть, скопировать себе все токены и сертификаты.

Answer 1

[SlavikF]

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

Тогда я решил это тем, что у основного проекта был доступ только к staging, а для прода был форк этого проекта со своим раннером.

Но после этого у Гитлаба добавили несколько фишек, то может теперь и есть и другой вариант.
Сегодня я думаю можно так:
- иметь 2 раннера: один для staging, один для production
- раннер для production поставить разрешение запускать только на `master`
- у разработчика нету привилегий для доступа к `master`.

При этом подразумевается, что staging и production - это разные серверы.