Комментарии 4
Интересно, давно искал подобный механизм, мы на своих проектах использовали самописный сборщик, который хранил приватный ключ, чтобы избежать его утечки из репозитория. Есть подобный механизм деплоя для gitlab?
В тексте написано: вместо использования статических паролей или ключей CI-платформа (GitHub Actions или GitLab CI)...
Если я правильно понимаю, то работает с GitHub и GitLab, хотя, могу и ошибаться.
Привет! Да, GitLab CI поддерживается: там стандартный OIDC через id_tokens. В репозитории есть готовый include-шаблон gitlab/deploy.yml (job .cd-deploy, достаточно сделать extends), а клиент deploy.sh сам подхватывает токен из CD_ID_TOKEN.
На сервере проект добавляется с флагом --gitlab, а для self-hosted GitLab с --issuer https://gitlab.example.com. Проверка токена та же, что и для GitHub, но правила строятся по GitLab-claims: project_path, ref и ref_protected. Поэтому ветка, с которой идёт деплой, должна быть защищённой.
Честно уточню по практике: каждый день я гоняю cd на проектах с GitHub Actions. Ветка GitLab покрыта unit-тестами на правила claims, но на реальном инстансе GitLab я её ещё не прогонял, так что боевого опыта именно там пока нет.
Репозиторий: https://github.com/Dmitry-Fedotov-Dev/cd. Если попробуете на GitLab и упрётесь в нюансы с claims или конфигом, пишите в Issues, поправлю.
Пока не до конца понял, почему нельзя было использовать готовые механизмы. Хоть поставить gitlab-runner на VPS, и пусть он там деплоит. Работает без SSH-ключей и без рута.
Надо запретить разработчикам доступ к произвольному запуску команд? Делаете custom executor. И ни девелопер, ни даже овнер проекта не смогут на проде запустить ничего лишнего.
Ну и дополнительно:
1. Собирать проекты на проде я бы не стал. Во-первых, любой, даже самый докер-ограниченный чрут со всеми сигруппами и сброшенными capabilities, может положить систему. Во вторых, из чрутов иногда вырываются. И лучше, если это всё случается не на проде. В третьих, если сам прод сломают, то сразу попадают в ваш там же находящийся дев-контур со всеми исходниками и возможностью подкинуть чего-нибудь интересного в сборку.
2. Пуш на прод мне видится не самой классной идеей. Это всегда лишняя плоскость атаки. А в вашем случае с демонком от рута, да ещё и слушающим http, плоскость атаки выглядит весьма широкой. Всё это конечно чуть-чуть заизолировано в systemd и т.д., но даже без учета фактического рута конструкция выглядит очень хрупкой с точки зрения долговременной поддержки.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Деплой на VPS по push без SSH-ключей в CI: архитектура cd, механика OIDC и границы применимости