Comments 7
Не страшно давать контейнеру с Werf права cluster-admin на весь кластер?
Может хотя бы ограничить каким-либо namespace?
Вы правы, лучше будет создать на каждый namespace свой GitLab Kubernetes executor. У каждого executor'а свой service account, который имеет доступ только к одному namespace. Соответственно в CI каждого репозитория для запуска джоб использовать соответствующий namespace'у Kubernetes executor. Executor/runner нужно крепить к конкретным репозиториям, не использовать shared runners.
Если в один неймспейс деплоите из нескольких репозиториев и хочется дополнительно обезопаситься, можно создавать по несколько SA на неймспейс и тонко нарезать права каждому SA.
Альтернативно, можно обойтись без создания нескольких Kubernetes executor'ов, пробрасывая $WERF_KUBECONFIG_BASE64 (свой для каждого репозитория, через секретные переменные GitLab) напрямую в werf.
Текущий вариант проще всего, потому и продемонстрирован, но упомянуть о нормальном разграничении прав стоило. Спасибо, документацию тоже доработаем и обновим.
Только с динамическими окружениями (напр. ревью-окружения), которые надо создавать и удалять на лету, вероятно таки потребуется ограниченный кластерный доступ.
Что за верфь без докеров? :)
Насколько я знал buildah не умеет работать с внешними кэшами и соответственно вопрос, werf сохраняет возможность работать со своими внешними кэшами?
На данный момент мы поддерживаем только Dockerfile с Buildah, и если текущее состояние есть в container registry, то werf не будет его собирать по новой и перетирать тег (тут всё остаётся без изменений).
В ближайшее время мы планируем переключиться на сборку: добавить поддержку нашего синтаксиса (Stapel), а также организовать послойное кэширование для Dockerfile.
P.S. Как и в случае с Docker-демоном работу с кэшом (транзакционность, блокировки, синхронизацию) werf берёт на себя. В случае с Buildah история не меняется.
Запуск werf в GitLab CI/CD без Docker-сервера