Как стать автором
Обновить
51
Карма
8.7
Рейтинг
Алексей Игрычев @aigrychev

Разработчик

GitLab + K8s + Werf

Долгое время у нас была поддержка только Dockerfile с Buildah, но сейчас можно использовать и Stapel (с несущественными ограничениями).

Немного деталей для прояснения комментария:

  • Образы, собираемые werf, можно описывать с помощью Dockerfile или нашего собственного синтаксиса — Stapel.

  • Собирать образы можно опять-таки используя два различных бэкенда — Docker-демон или Buildah (userspace сборка, именно этот вариант должен использоваться в K8s).

Новые возможности werf: CI/CD на основе werf и Argo CD

На данный момент мы придерживаемся позиции, что при использовании бандлов werf-секреты не должны сохраняться вместе с чартом в container registry, а должны прокидываться при применении бандла в конкретном проекте и окружение.

Таким образом, в текущей интеграции с Argo CD мы никак не решаем вопрос с секретами и пользователь должен это делать самостоятельно как и в случае использования Argo CD без werf: Argo CD is un-opinionated about how secrets are managed (secret management).

Представляем trdl — Open Source-решение для безопасной и непрерывной доставки обновлений

Что касается репозитория артефактов, то мы не делаем ничего нового, просто имплементируем TUF-репозиторий. В отличие от Nexus и Artifactory фокус этого решения на безопасности самого репозитория, минимизации ущерба в случае компрометации и защите от большинства угроз. Если интересно, то лучше отдельно почитать на сайте продукта или в нашей недавней статье.

Представляем trdl — Open Source-решение для безопасной и непрерывной доставки обновлений

Мы не предоставляем SaaS. Система обновлений может использоваться в любых контурах. Другой вопрос — подходит ли навязываемый системой процесс доставки и использования именно для вашего флоу и ПО.

Что касается тезиса, то система обновления требует использовать клиент не только для обновления, но и для использования артефактов ПО, причём неразрывно.

Представляем trdl — Open Source-решение для безопасной и непрерывной доставки обновлений

Чем релиз нового поможет, если все доверие подорвано? И нужно каким-то образом отзывать и удалять скомпрометированные релизы - раз... Я уж не говорю о том, что пользователи могут не хотеть автоапдейт.

Наша система обновлений рассчитана на то, что пользователи полностью доверяют команде разработки и всегда работают с актуальным ПО в рамках выбранного канала обновлений. А так как пользователь не имеет возможности скачать определённую версию, то и вопрос отзыва и удаления скомпрометированных релизов не стоит так остро.

два - каким-то образом убирать скомпрометированные ключи?

Скомпрометированный ключ продолжает использоваться, но уже совместно с новым. Не хочется уходить в дебри TUF, поэтому этот и другие сценарии лучше посмотреть в спецификации фреймворка, которую мы имплементируем в серверной и клиентской части системы.

Система полностью берёт на себя ответственность за ключи шифрования: автоматически создаёт, ротирует и хранит их в Vault. Ни у кого нет к ним доступа, никто не пересекается с ними.

Тогда тем более не понимаю, чем это лучше стандартного релиза на гитхаб + проверки контрольных сумм и подписей

Развивая тему с [физическим] доступом злоумышленника к хосту. Он с тем же успехом может подменить curl, gpg, ... и любой флоу посыпется.

Trdl-клиент верифицирует доверенный репозиторий (вот тут можно почитать от каких атак на систему обновлений защищает TUF), данные в нём, а также гарантирует согласованность и целостность скачанных данных. А примитивная защита trdl-клиента уже на плечах пользователя (в разделе Безопасность этот момент зафиксирован).

Если посмотреть на вопрос глобально, то мы предлагаем готовый процесс от и до.

Представляем trdl — Open Source-решение для безопасной и непрерывной доставки обновлений

Но хотелось бы сразу понять - кворум не защищает

Кворум позволяет сделать процесс надёжнее, снизив риски от человеческих ошибок, компрометации доверенных GPG-ключей, нарушения регламента и т.д. - команда разработки отвечает за доставку и никто не может обойти это условие (минимум M подписей из N доверенных) при совершении релиза или переключении версий в каналах обновлений. Вопрос скорее культурный, поэтому сам по себе кворум действительно ни от чего не защищает.

Теоретически могли ранее внедрить уязвимость и вчерашний «доверенный» код уже не доверенный

Штатная ситуация. В наш процесс закладывается непрерывность использования артефактов обновлений. Как только проблема обнаруживается выполняется релиз новой версии/откат версии в канале обновлений и все пользователи получают стабильную версию.

Я хотел бы видеть контроль не в моменте доставки артефакта на целевую машину, а в момент его запуска.

Пользователь получает надёжный канал доставки (верификация источника, целостность данных, ...), а защита от угроз, связанных с [физическим] доступом злоумышленника к хосту, это задача в полной мере нерешаемая, если на хосте не соблюдаются базовые методы защиты - злоумышленник может просто подменить trdl-клиент.

Представляем trdl — Open Source-решение для безопасной и непрерывной доставки обновлений

На текущий момент у нас есть только такая имплементация trdl-сервера, при которой сервер запускается как плагин Vault.

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

В целом спасибо за вопрос, будем взвешивать риски и при необходимости добавлять новые имплементации.

Представляем trdl — Open Source-решение для безопасной и непрерывной доставки обновлений

trdl — это система безопасной и непрерывной доставки, которая заточена под определённый флоу. Это касается как разработки, так и использования ПО пользователями (планируется множество флоу использования).

Команда разработки получает готовый флоу, позволяющий непрерывно выполнять релизы ПО для всех поддерживаемых платформ и переключать их в каналах обновлений, с той периодичностью которая необходима. Никто не имеет доступа к инфраструктуре, а все операции выполняются только по согласию кворума (минимального набора разрешённых GPG-подписей). Ещё один важный момент, что вся конфигурация хранится в Git и нет такой проблемы как локально работает, а на произвольном этапе доставки всё разваливается.

Для пользователей — это в первую очередь безопасность обновлений, которая гарантируется реализацией TUF-репозитория, а также инструмент использования артефактов ПО по каналам обновлений (пользователь оперирует каналами с определённым уровнем совместимости и стабильности), который одинаково работает на всех платформах и предлагает готовые флоу. К примеру, следующим образом можно добавить все исполняемые файлы ПО в PATH и работать с ними в рамках текущей shell-сессии, а обновления запустить в фоне для последующего использования (удобно в CI): `. $(trdl use werf 1.2 stable)`.

Представляем trdl — Open Source-решение для безопасной и непрерывной доставки обновлений

Мы по сути ничего не переизобретаем, берём стандарты сферы и склеиваем их — по аналогии с werf (если вам знаком наш инструмент доставки). Аналоги есть, но только для отдельных кусков процесса.

TUF позволяет гарантировать актуальность, согласованность, целостность данных, а самое главное защиту от большинства угроз. Мы имплементируем TUF-репозиторий trdl-сервером и предоставляем trdl-клиент для пользователей, которые работают согласно The Update Framework (TUF).

Vault позволяет построить систему, в которой ни у кого нету доступа до ключей шифрования и нет возможности их каким-либо образом получить (т.е. весь релизный процесс доставки может выполняться исключительно плагином). Мы запускаем наш trdl-сервер как плагин Vault и реализуем весь процесс доставки, используя Git как главный источник правды. Команда разработки ограничена всего двумя методами API и никак не пересекается с инфраструктурой.

Более подробно можно почитать на нашем сайте в разделе Безопасность.

Запуск werf в GitLab CI/CD без Docker-сервера

На данный момент мы поддерживаем только Dockerfile с Buildah, и если текущее состояние есть в container registry, то werf не будет его собирать по новой и перетирать тег (тут всё остаётся без изменений).

В ближайшее время мы планируем переключиться на сборку: добавить поддержку нашего синтаксиса (Stapel), а также организовать послойное кэширование для Dockerfile.

P.S. Как и в случае с Docker-демоном работу с кэшом (транзакционность, блокировки, синхронизацию) werf берёт на себя. В случае с Buildah история не меняется.

Локальная разработка в Kubernetes с помощью werf 1.2 и minikube

Можно интегрировать их с помощь git-сабмодулей в одном репозитории или посмотреть в сторону бандлов (oci образ в container registry, который содержит helm-чарт и теги собранных образов). Для выката достаточно этого образа.

Локальная разработка в Kubernetes с помощью werf 1.2 и minikube

У нас запланирована с ним встреча на этот четверг. Вероятнее всего обе стороны дадут комментарии по результатам.

Если в двух словах, то с его стороны это обзор продукта на примитивном примере и без хорошего погружения в werf, а с нашей — плохое позиционирование продукта (особенно вне русскоязычного сообщества).

Локальная разработка в Kubernetes с помощью werf 1.2 и minikube

Есть ли быть точнее, то флоу должен выглядеть как-то так:

docker build \
            --cache-from $CACHE_IMAGE:latest \
            --tag $CACHE_IMAGE:latest \
            --build-arg BUILDKIT_INLINE_CACHE=1 \
            "."
docker push $CACHE_IMAGE:latest

Грубо говоря, werf делает это из коробки, но поинтереснее:

  • Вместо сборки и публикации всего образа целиком, werf делает это стадиями (слоями). После сборки слой уходит в container registry и уже может использоваться остальными сборщиками.

  • werf гарантирует воспроизводимость и неизменность кэша. Сборка одного и того же слоя несколькими сборщиками не приведёт к коллизиям и нарушению воспроизводимости остальных сборок. При публикации первый сборщик загрузит свой слой, а второй сборщик отбросит свой результат и будет использовать актуальный слой для текущей сборки.

werf v1.2 — стабильный релиз Open Source-утилиты для доставки приложений в Kubernetes

Согласно документации под публикацией артефактов подразумевается выкат для внутреннего использования, а под релизом — уже открытие доступа для конечных пользователей.

werf v1.2 — стабильный релиз Open Source-утилиты для доставки приложений в Kubernetes

UPDATE: последние три команды в примере это конечно же werf converge, а не werf compose

werf v1.2 — стабильный релиз Open Source-утилиты для доставки приложений в Kubernetes

Честно говоря, нет понимания, что подобное разделение может привнести в классический подход с контурами и как оно укладывается в непрерывную доставку в целом.

У нас во всех проектах при каждом коммите автоматически создаётся 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. количество шагов / пайплайнов, а также зависимости (вручную, автоматически, при изменении определённой ветки ...) произвольны.

werf vs Docker. Чем лучше собирать образы

Да, определённо придётся перестраивать процессы. Зато в конечном итоге можно унифицировать процессы, и сборка/запуск/выкат тестировщиками/разработчиками локально не будет ничем отличаться от соответствующих шагов в CI-заданиях.

werf vs. Helm: корректно ли их вообще сравнивать?

Да, определённо проще — минимум конфигураций и, в базовом случае, всего одна werf-команда. Можно поднять за несколько часов на том же самом GitHub Actions (werf/actions).

werf vs Docker. Чем лучше собирать образы

Подкрепляю комментарий расширенной версией диаграммы из статьи.


werf vs Docker. Чем лучше собирать образы

Docker много чего не умеет из того, что умеет werf. Не в силу того, что werf лучше, а просто потому что эти инструменты о разном. Docker — это фундаментальное решение, которое выполняет конкретные задачи по управлению образами и контейнерами на хосте (в большинстве своём низкоуровневые операции). werf, в свою очередь, про жизненный цикл приложения в Kubernetes, который обеспечивается слаженной работой множества компонентов.


Надеюсь у вас будет время попробовать werf и дать обратную связь в наших telegram-каналах и на GitHub.

Информация

В рейтинге
509-й
Работает в
Зарегистрирован
Активность