Если правильно настроить агент, то, при исполнении каких-либо запросов в KubeAPI, они будут имперсонироваться и запрос будет исполняться от Username
gitlab:ci_job:<JOB_ID>, а в Groups будет куча информации по проекту. Например ID проекта (gitlab:project:<PROJECT_ID>) или группы в которых проект состоит (gitlab:group:<GROUP1_ID>, gitlab:group:<GROUP2_ID>). И чтобы Job мог выполнить какие-то запросы в KubeAPI - ему необходимы права.У Gitlab'а не было никаких инструментов, чтобы такие права выдавать, по этому мы костылили как могли:
- Парсили конфиги Gitlab Agent'ов, доставая от туда IDшники заинтегрированных репозиториев
- Ходили в это репозитории и доставали от туда member'ов уровня выше developer
- Подвязывались на системные webhook'и Gitlab'a, чтобы ловить события изменения member'ов проекта или добавления нового проекта в группу, к которой привязан Gitlab Agent.
- Автоматом на всей собранной информации генерировали Tenant'ы и раздавали нужные права в этих tenant'ах как для пользователей (Devops/Dev команды), чтобы у них доступ был, так и для системных учеток, (тот самый
gitlab:project:<PROJECT_ID>) от которых шел деплой.Мы несколько раз переделывали эту схему. Специально интегрировали самопальный DEX, который при авторизации пользователя в Kuberentes собирает в каких группах в Gitlab'e тот состоит, что бы не собирать эти группы при генерации тенантов и разгрузить Gitlab API. Еще что-то... Еще что-то...
Но, похоже, наши боли подходят к концу, т.к. во вчерашнем (20.02) релизе Gitlab'a наконец-то добавили Gitlab-managed Kuberentes resources. Теперь при интеграции Gitlab Agent'a с каким-то репозиторием можно определить какие-то ресурсы, которые будут автоматои созданны для этого репозитория. (Namespace, RoleBinding, Flux Resources). Функционал, который мы внедрили с Dex'ом в нашей схеме все равно остается важным, но все автоматизацию по созданию ресурсов наконец-то, можно будет удалить.
Почитать подробнее про новый функционал можно тут. В общем - УРА
#zvlb_musle #Kubernetes #Gitlab