В статье вы демонстрируете сценарий публикации чартов в GitLab Package Registry, который мы со своей стороны никак не продвигаем и не развиваем — возможно зря и это хороший индикатор для нас. Для дистрибуции Helm-чартов мы рекомендуем придерживаться нашего концепта бандлов и сохранять чарты в GitLab Container Registry рядом с образами приложения.
Заметил, что вы упоминаете гайд версии 1.1 для настройки GitLab-раннера. В этом нет никакой необходимости, т.к. всю необходимую информацию пользователь может найти на вкладках конфигуратора для произвольного раннера (shell, docker, kubernetes) и сценария с werf.
Спасибо за вашу работу и за то, что делитесь своим опытом с сообществом. 💜 от команды werf.
Долгое время у нас была поддержка только Dockerfile с Buildah, но сейчас можно использовать и Stapel (с несущественными ограничениями).
Немного деталей для прояснения комментария:
Образы, собираемые werf, можно описывать с помощью Dockerfile или нашего собственного синтаксиса — Stapel.
Собирать образы можно опять-таки используя два различных бэкенда — Docker-демон или Buildah (userspace сборка, именно этот вариант должен использоваться в K8s).
На данный момент мы придерживаемся позиции, что при использовании бандлов werf-секреты не должны сохраняться вместе с чартом в container registry, а должны прокидываться при применении бандла в конкретном проекте и окружение.
Таким образом, в текущей интеграции с Argo CD мы никак не решаем вопрос с секретами и пользователь должен это делать самостоятельно как и в случае использования Argo CD без werf: Argo CD is un-opinionated about how secrets are managed (secret management).
Что касается репозитория артефактов, то мы не делаем ничего нового, просто имплементируем TUF-репозиторий. В отличие от Nexus и Artifactory фокус этого решения на безопасности самого репозитория, минимизации ущерба в случае компрометации и защите от большинства угроз. Если интересно, то лучше отдельно почитать на сайте продукта или в нашей недавней статье.
Мы не предоставляем SaaS. Система обновлений может использоваться в любых контурах. Другой вопрос — подходит ли навязываемый системой процесс доставки и использования именно для вашего флоу и ПО.
Что касается тезиса, то система обновления требует использовать клиент не только для обновления, но и для использования артефактов ПО, причём неразрывно.
Чем релиз нового поможет, если все доверие подорвано? И нужно каким-то образом отзывать и удалять скомпрометированные релизы - раз... Я уж не говорю о том, что пользователи могут не хотеть автоапдейт.
Наша система обновлений рассчитана на то, что пользователи полностью доверяют команде разработки и всегда работают с актуальным ПО в рамках выбранного канала обновлений. А так как пользователь не имеет возможности скачать определённую версию, то и вопрос отзыва и удаления скомпрометированных релизов не стоит так остро.
два - каким-то образом убирать скомпрометированные ключи?
Скомпрометированный ключ продолжает использоваться, но уже совместно с новым. Не хочется уходить в дебри TUF, поэтому этот и другие сценарии лучше посмотреть в спецификации фреймворка, которую мы имплементируем в серверной и клиентской части системы.
Система полностью берёт на себя ответственность за ключи шифрования: автоматически создаёт, ротирует и хранит их в Vault. Ни у кого нет к ним доступа, никто не пересекается с ними.
Тогда тем более не понимаю, чем это лучше стандартного релиза на гитхаб + проверки контрольных сумм и подписей
Развивая тему с [физическим] доступом злоумышленника к хосту. Он с тем же успехом может подменить curl, gpg, ... и любой флоу посыпется.
Trdl-клиент верифицирует доверенный репозиторий (вот тут можно почитать от каких атак на систему обновлений защищает TUF), данные в нём, а также гарантирует согласованность и целостность скачанных данных. А примитивная защита trdl-клиента уже на плечах пользователя (в разделе Безопасность этот момент зафиксирован).
Если посмотреть на вопрос глобально, то мы предлагаем готовый процесс от и до.
Кворум позволяет сделать процесс надёжнее, снизив риски от человеческих ошибок, компрометации доверенных GPG-ключей, нарушения регламента и т.д. - команда разработки отвечает за доставку и никто не может обойти это условие (минимум M подписей из N доверенных) при совершении релиза или переключении версий в каналах обновлений. Вопрос скорее культурный, поэтому сам по себе кворум действительно ни от чего не защищает.
Теоретически могли ранее внедрить уязвимость и вчерашний «доверенный» код уже не доверенный
Штатная ситуация. В наш процесс закладывается непрерывность использования артефактов обновлений. Как только проблема обнаруживается выполняется релиз новой версии/откат версии в канале обновлений и все пользователи получают стабильную версию.
Я хотел бы видеть контроль не в моменте доставки артефакта на целевую машину, а в момент его запуска.
Пользователь получает надёжный канал доставки (верификация источника, целостность данных, ...), а защита от угроз, связанных с [физическим] доступом злоумышленника к хосту, это задача в полной мере нерешаемая, если на хосте не соблюдаются базовые методы защиты - злоумышленник может просто подменить trdl-клиент.
На текущий момент у нас есть только такая имплементация trdl-сервера, при которой сервер запускается как плагин Vault.
Мы могли бы предоставить пользователю возможность запускать сервер вне и использовать произвольную KMS, но такая реализация не позволит гарантировать текущую надёжность системы — чёрный ящик с несколькими ручками выглядит убедительнее.
В целом спасибо за вопрос, будем взвешивать риски и при необходимости добавлять новые имплементации.
trdl — это система безопасной и непрерывной доставки, которая заточена под определённый флоу. Это касается как разработки, так и использования ПО пользователями (планируется множество флоу использования).
Команда разработки получает готовый флоу, позволяющий непрерывно выполнять релизы ПО для всех поддерживаемых платформ и переключать их в каналах обновлений, с той периодичностью которая необходима. Никто не имеет доступа к инфраструктуре, а все операции выполняются только по согласию кворума (минимального набора разрешённых GPG-подписей). Ещё один важный момент, что вся конфигурация хранится в Git и нет такой проблемы как локально работает, а на произвольном этапе доставки всё разваливается.
Для пользователей — это в первую очередь безопасность обновлений, которая гарантируется реализацией TUF-репозитория, а также инструмент использования артефактов ПО по каналам обновлений (пользователь оперирует каналами с определённым уровнем совместимости и стабильности), который одинаково работает на всех платформах и предлагает готовые флоу. К примеру, следующим образом можно добавить все исполняемые файлы ПО в PATH и работать с ними в рамках текущей shell-сессии, а обновления запустить в фоне для последующего использования (удобно в CI): `. $(trdl use werf 1.2 stable)`.
Мы по сути ничего не переизобретаем, берём стандарты сферы и склеиваем их — по аналогии с werf (если вам знаком наш инструмент доставки). Аналоги есть, но только для отдельных кусков процесса.
TUF позволяет гарантировать актуальность, согласованность, целостность данных, а самое главное защиту от большинства угроз. Мы имплементируем TUF-репозиторий trdl-сервером и предоставляем trdl-клиент для пользователей, которые работают согласно The Update Framework (TUF).
Vault позволяет построить систему, в которой ни у кого нету доступа до ключей шифрования и нет возможности их каким-либо образом получить (т.е. весь релизный процесс доставки может выполняться исключительно плагином). Мы запускаем наш trdl-сервер как плагин Vault и реализуем весь процесс доставки, используя Git как главный источник правды. Команда разработки ограничена всего двумя методами API и никак не пересекается с инфраструктурой.
Более подробно можно почитать на нашем сайте в разделе Безопасность.
На данный момент мы поддерживаем только Dockerfile с Buildah, и если текущее состояние есть в container registry, то werf не будет его собирать по новой и перетирать тег (тут всё остаётся без изменений).
В ближайшее время мы планируем переключиться на сборку: добавить поддержку нашего синтаксиса (Stapel), а также организовать послойное кэширование для Dockerfile.
P.S. Как и в случае с Docker-демоном работу с кэшом (транзакционность, блокировки, синхронизацию) werf берёт на себя. В случае с Buildah история не меняется.
Можно интегрировать их с помощь git-сабмодулей в одном репозитории или посмотреть в сторону бандлов (oci образ в container registry, который содержит helm-чарт и теги собранных образов). Для выката достаточно этого образа.
У нас запланирована с ним встреча на этот четверг. Вероятнее всего обе стороны дадут комментарии по результатам.
Если в двух словах, то с его стороны это обзор продукта на примитивном примере и без хорошего погружения в werf, а с нашей — плохое позиционирование продукта (особенно вне русскоязычного сообщества).
Грубо говоря, werf делает это из коробки, но поинтереснее:
Вместо сборки и публикации всего образа целиком, werf делает это стадиями (слоями). После сборки слой уходит в container registry и уже может использоваться остальными сборщиками.
werf гарантирует воспроизводимость и неизменность кэша. Сборка одного и того же слоя несколькими сборщиками не приведёт к коллизиям и нарушению воспроизводимости остальных сборок. При публикации первый сборщик загрузит свой слой, а второй сборщик отбросит свой результат и будет использовать актуальный слой для текущей сборки.
Согласно документации под публикацией артефактов подразумевается выкат для внутреннего использования, а под релизом — уже открытие доступа для конечных пользователей.
Честно говоря, нет понимания, что подобное разделение может привнести в классический подход с контурами и как оно укладывается в непрерывную доставку в целом.
У нас во всех проектах при каждом коммите автоматически создаётся CI-пайплайн. В нём собираются образы, выполняются тесты, приложение для отладки и оставшихся проверок выкатывается на различные Kubernetes-контуры, и если всё хорошо — изменения доходят до конечного пользователя.
Условно следующий набор шагов:
werf build # сборка образов
werf run || werf compose up # произвольное количество шагов тестирования компонентов
werf compose --env review-<ID> # выкат на легковесный ревью контур
werf compose --env staging # выкат на production-like контур
werf compose --env production # выкат на production
p.s. количество шагов / пайплайнов, а также зависимости (вручную, автоматически, при изменении определённой ветки ...) произвольны.
Да, определённо придётся перестраивать процессы. Зато в конечном итоге можно унифицировать процессы, и сборка/запуск/выкат тестировщиками/разработчиками локально не будет ничем отличаться от соответствующих шагов в CI-заданиях.
Да, определённо проще — минимум конфигураций и, в базовом случае, всего одна werf-команда. Можно поднять за несколько часов на том же самом GitHub Actions (werf/actions).
В статье вы демонстрируете сценарий публикации чартов в GitLab Package Registry, который мы со своей стороны никак не продвигаем и не развиваем — возможно зря и это хороший индикатор для нас. Для дистрибуции Helm-чартов мы рекомендуем придерживаться нашего концепта бандлов и сохранять чарты в GitLab Container Registry рядом с образами приложения.
Заметил, что вы упоминаете гайд версии 1.1 для настройки GitLab-раннера. В этом нет никакой необходимости, т.к. всю необходимую информацию пользователь может найти на вкладках конфигуратора для произвольного раннера (shell, docker, kubernetes) и сценария с werf.
Спасибо за вашу работу и за то, что делитесь своим опытом с сообществом. 💜 от команды werf.
Долгое время у нас была поддержка только Dockerfile с Buildah, но сейчас можно использовать и Stapel (с несущественными ограничениями).
Немного деталей для прояснения комментария:
Образы, собираемые werf, можно описывать с помощью Dockerfile или нашего собственного синтаксиса — Stapel.
Собирать образы можно опять-таки используя два различных бэкенда — Docker-демон или Buildah (userspace сборка, именно этот вариант должен использоваться в K8s).
На данный момент мы придерживаемся позиции, что при использовании бандлов werf-секреты не должны сохраняться вместе с чартом в container registry, а должны прокидываться при применении бандла в конкретном проекте и окружение.
Таким образом, в текущей интеграции с Argo CD мы никак не решаем вопрос с секретами и пользователь должен это делать самостоятельно как и в случае использования Argo CD без werf: Argo CD is un-opinionated about how secrets are managed (secret management).
Что касается репозитория артефактов, то мы не делаем ничего нового, просто имплементируем TUF-репозиторий. В отличие от Nexus и Artifactory фокус этого решения на безопасности самого репозитория, минимизации ущерба в случае компрометации и защите от большинства угроз. Если интересно, то лучше отдельно почитать на сайте продукта или в нашей недавней статье.
Мы не предоставляем SaaS. Система обновлений может использоваться в любых контурах. Другой вопрос — подходит ли навязываемый системой процесс доставки и использования именно для вашего флоу и ПО.
Что касается тезиса, то система обновления требует использовать клиент не только для обновления, но и для использования артефактов ПО, причём неразрывно.
Наша система обновлений рассчитана на то, что пользователи полностью доверяют команде разработки и всегда работают с актуальным ПО в рамках выбранного канала обновлений. А так как пользователь не имеет возможности скачать определённую версию, то и вопрос отзыва и удаления скомпрометированных релизов не стоит так остро.
Скомпрометированный ключ продолжает использоваться, но уже совместно с новым. Не хочется уходить в дебри TUF, поэтому этот и другие сценарии лучше посмотреть в спецификации фреймворка, которую мы имплементируем в серверной и клиентской части системы.
Система полностью берёт на себя ответственность за ключи шифрования: автоматически создаёт, ротирует и хранит их в Vault. Ни у кого нет к ним доступа, никто не пересекается с ними.
Развивая тему с [физическим] доступом злоумышленника к хосту. Он с тем же успехом может подменить curl, gpg, ... и любой флоу посыпется.
Trdl-клиент верифицирует доверенный репозиторий (вот тут можно почитать от каких атак на систему обновлений защищает TUF), данные в нём, а также гарантирует согласованность и целостность скачанных данных. А примитивная защита trdl-клиента уже на плечах пользователя (в разделе Безопасность этот момент зафиксирован).
Если посмотреть на вопрос глобально, то мы предлагаем готовый процесс от и до.
Кворум позволяет сделать процесс надёжнее, снизив риски от человеческих ошибок, компрометации доверенных GPG-ключей, нарушения регламента и т.д. - команда разработки отвечает за доставку и никто не может обойти это условие (минимум M подписей из N доверенных) при совершении релиза или переключении версий в каналах обновлений. Вопрос скорее культурный, поэтому сам по себе кворум действительно ни от чего не защищает.
Штатная ситуация. В наш процесс закладывается непрерывность использования артефактов обновлений. Как только проблема обнаруживается выполняется релиз новой версии/откат версии в канале обновлений и все пользователи получают стабильную версию.
Пользователь получает надёжный канал доставки (верификация источника, целостность данных, ...), а защита от угроз, связанных с [физическим] доступом злоумышленника к хосту, это задача в полной мере нерешаемая, если на хосте не соблюдаются базовые методы защиты - злоумышленник может просто подменить trdl-клиент.
На текущий момент у нас есть только такая имплементация trdl-сервера, при которой сервер запускается как плагин Vault.
Мы могли бы предоставить пользователю возможность запускать сервер вне и использовать произвольную KMS, но такая реализация не позволит гарантировать текущую надёжность системы — чёрный ящик с несколькими ручками выглядит убедительнее.
В целом спасибо за вопрос, будем взвешивать риски и при необходимости добавлять новые имплементации.
trdl — это система безопасной и непрерывной доставки, которая заточена под определённый флоу. Это касается как разработки, так и использования ПО пользователями (планируется множество флоу использования).
Команда разработки получает готовый флоу, позволяющий непрерывно выполнять релизы ПО для всех поддерживаемых платформ и переключать их в каналах обновлений, с той периодичностью которая необходима. Никто не имеет доступа к инфраструктуре, а все операции выполняются только по согласию кворума (минимального набора разрешённых GPG-подписей). Ещё один важный момент, что вся конфигурация хранится в Git и нет такой проблемы как локально работает, а на произвольном этапе доставки всё разваливается.
Для пользователей — это в первую очередь безопасность обновлений, которая гарантируется реализацией TUF-репозитория, а также инструмент использования артефактов ПО по каналам обновлений (пользователь оперирует каналами с определённым уровнем совместимости и стабильности), который одинаково работает на всех платформах и предлагает готовые флоу. К примеру, следующим образом можно добавить все исполняемые файлы ПО в PATH и работать с ними в рамках текущей shell-сессии, а обновления запустить в фоне для последующего использования (удобно в CI): `. $(trdl use werf 1.2 stable)`.
Мы по сути ничего не переизобретаем, берём стандарты сферы и склеиваем их — по аналогии с werf (если вам знаком наш инструмент доставки). Аналоги есть, но только для отдельных кусков процесса.
TUF позволяет гарантировать актуальность, согласованность, целостность данных, а самое главное защиту от большинства угроз. Мы имплементируем TUF-репозиторий trdl-сервером и предоставляем trdl-клиент для пользователей, которые работают согласно The Update Framework (TUF).
Vault позволяет построить систему, в которой ни у кого нету доступа до ключей шифрования и нет возможности их каким-либо образом получить (т.е. весь релизный процесс доставки может выполняться исключительно плагином). Мы запускаем наш trdl-сервер как плагин Vault и реализуем весь процесс доставки, используя Git как главный источник правды. Команда разработки ограничена всего двумя методами API и никак не пересекается с инфраструктурой.
Более подробно можно почитать на нашем сайте в разделе Безопасность.
На данный момент мы поддерживаем только Dockerfile с Buildah, и если текущее состояние есть в container registry, то werf не будет его собирать по новой и перетирать тег (тут всё остаётся без изменений).
В ближайшее время мы планируем переключиться на сборку: добавить поддержку нашего синтаксиса (Stapel), а также организовать послойное кэширование для Dockerfile.
P.S. Как и в случае с Docker-демоном работу с кэшом (транзакционность, блокировки, синхронизацию) werf берёт на себя. В случае с Buildah история не меняется.
Можно интегрировать их с помощь git-сабмодулей в одном репозитории или посмотреть в сторону бандлов (oci образ в container registry, который содержит helm-чарт и теги собранных образов). Для выката достаточно этого образа.
У нас запланирована с ним встреча на этот четверг. Вероятнее всего обе стороны дадут комментарии по результатам.
Если в двух словах, то с его стороны это обзор продукта на примитивном примере и без хорошего погружения в werf, а с нашей — плохое позиционирование продукта (особенно вне русскоязычного сообщества).
Есть ли быть точнее, то флоу должен выглядеть как-то так:
Грубо говоря, werf делает это из коробки, но поинтереснее:
Вместо сборки и публикации всего образа целиком, werf делает это стадиями (слоями). После сборки слой уходит в container registry и уже может использоваться остальными сборщиками.
werf гарантирует воспроизводимость и неизменность кэша. Сборка одного и того же слоя несколькими сборщиками не приведёт к коллизиям и нарушению воспроизводимости остальных сборок. При публикации первый сборщик загрузит свой слой, а второй сборщик отбросит свой результат и будет использовать актуальный слой для текущей сборки.
Согласно документации под публикацией артефактов подразумевается выкат для внутреннего использования, а под релизом — уже открытие доступа для конечных пользователей.
UPDATE: последние три команды в примере это конечно же
werf converge, а неwerf composeЧестно говоря, нет понимания, что подобное разделение может привнести в классический подход с контурами и как оно укладывается в непрерывную доставку в целом.
У нас во всех проектах при каждом коммите автоматически создаётся CI-пайплайн. В нём собираются образы, выполняются тесты, приложение для отладки и оставшихся проверок выкатывается на различные Kubernetes-контуры, и если всё хорошо — изменения доходят до конечного пользователя.
Условно следующий набор шагов:
p.s. количество шагов / пайплайнов, а также зависимости (вручную, автоматически, при изменении определённой ветки ...) произвольны.
Да, определённо придётся перестраивать процессы. Зато в конечном итоге можно унифицировать процессы, и сборка/запуск/выкат тестировщиками/разработчиками локально не будет ничем отличаться от соответствующих шагов в CI-заданиях.
Да, определённо проще — минимум конфигураций и, в базовом случае, всего одна werf-команда. Можно поднять за несколько часов на том же самом GitHub Actions (werf/actions).
Подкрепляю комментарий расширенной версией диаграммы из статьи.