А в чем профит?

Можно чаще менять, чем ключт

Риск использования токенов ниже, т.к. на каждый чих можно по токену

Ну, и хттпс, а не ссш

Это что предполагается в composer.json пилить урлы в которые подставлять токены из окружения? Выглядит гораздо большим костылем чем монтирование ssh ключа при сборке зависимостей чесгря

Я бы не был столь категоричным

К тому же ссш - это почти всегда доступ на запись. Токен - как сделаешь

Ок, то есть некий мейнтейнер должен для каждой своей репы нагенерить токен, и раздавать их каждому разработчику кому понадобится залить себе это в проект?
И если зависимостей типа 10 то от каждой свой токен?
Это типа лучше решение чем через функционал гитлаба попроситься в мемберы нужного проекта? При условии настроеных protected branches которые не дадут записать куда не надо?

Я без наездов просто интересно. :)

Токены надо автоматизировать. Никакой ручной истории

Я правильно понимаю, что группа превратилась в место, где задают вопросы про swarm и docker-compose?

Да и ссш может быть отключен

Отключен где?

На гитлабе

А ходить по паролю - не комильфо, он может быть совпадающим с паролем ад

Мы не про облако, если что

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

Мы такое решали в условиях gitlab+composer приватный так: При сборке образа используется ключ который прописан в репозиториях как deploy key readonly. (Соотвественно очевидно без записи)
А для разрабов монтируется в окружения composer личный ключ. (Винды не было не скажу за нее).
Права доступа к репозиториям рулятся группами+protected бранчи с запретом пушей мерджей от кого не надо..

Вполне шевелилось.

Да selfhosted гитлаб понятное дело.

В ci/cd сейчас ключ приходит из env гитлаба. А разработчикам стоит все таки монтировать их ключи, правильно понял?

Т.к. в composer.json мне кажется не стоит хардкодить один ключ для всех