trdl (сокр. от “true delivery”, «истинная доставка») обеспечивает безопасный канал доставки обновлений от Git-репозитория до хоста пользователя. В состав trdl входят три ключевых компонента, которые помогают защищать систему обновления от потенциальных атак: HashiCorp Vault, TUF-репозиторий и Git.
Расскажем, как работает решение, от каких минусов существующих систем обновления избавлено и как начать им пользоваться.
Особенности trdl
Vault, TUF и Git — основа безопасности. trdl предотвращает потенциальные атаки на систему обновления и минимизирует ущерб от них. Это реализовано с помощью трех компонентов, которые работают в связке:
HashiCorp Vault — платформа для запуска trdl-сервера. Обеспечивает безопасное управление ключами шифрования.
Репозиторий на основе TUF (The Update Framework), из которого скачиваются обновления. Защищает от несанкционированного доступа к ПО, от компрометации и потери ключей. Отвечает за актуальность, согласованность и целостность данных. (Подробнее о TUF — в нашем обзоре.)
Git — хранит код, конфигурацию, а также GPG-подписи коммитов для верификации операций.
Вместо версий софта — каналы обновлений. Пользователь выбирает канал обновления с нужным уровнем совместимости и стабильности: alpha, beta, early access, stable, rock solid. Через эти каналы разработчики распространяют новые версии ПО — так часто, как им требуется.
GPG-кворум. Каждый коммит в Git подписывается «M из N» количеством разработчиков с помощью GPG-подписей. Кворум используется и для релиза новых версий ПО (тегов), и для публикации каналов обновления.
Универсальность. trdl — кроссплатформенная утилита, которая одинаково хорошо работает во всех популярных shell-оболочках на macOS, Windows и Linux.
Простота. Команде разработки не требуются дополнительные знания и инструменты — Git выступает в качестве главного «источника правды». Конфигурация сборки, каналы обновлений и GPG-подписи для верификации операций хранятся в Git. Пользователям же достаточно установить trdl-клиент, чтобы обновлять и использовать ПО.
Непрерывные обновления. Обновлять и использовать ПО можно безостановочно. Команда trdl use учитывает специфику запуска в CI-системе: обновление запускается в фоне, а пользователь работает с существующей версией ПО до завершения shell-сессии (скоро появятся и другие сценарии и команды).
Зачем нам свой «менеджер пакетов»
Мы разрабатываем продукты, которые нужно непрерывно и безопасно обновлять. Однако у существующих методов и систем обновления есть критичные для production недостатки.
Ограниченность алгоритмов защиты. HTTPS, SSL, TLS защищают только соединение, но не содержимое того, что скачивается из репозитория. PGP-алгоритм уязвим перед многими современными атаками на сам процесс обновления. GPG-подписи не защищают, например, от взлома ноутбука. Для действительно надежной защиты процесса обновления нужно выстроить систему «приемки кода» и подписи собранных файлов, которая должна быть защищена от человеческих ошибок. Существующие средства и алгоритмы эффективны сами по себе, но их недостаточно для выстраивания полноценной системы обновления.
Ограниченность непрерывной доставки. Непрерывная доставка с помощью CI/CD-систем хорошо подходит для SaaS-продуктов, но не для доставки целевых файлов на хосты пользователей.
Ограниченность пакетных менеджеров. Большинство пакетных менеджеров не универсальны. Для каждой платформы нужен свой менеджер. Уровень их автоматизации при этом стремится к нулю: пользователь сам должен добавлять источник для скачивания пакетов, искать пакет, устанавливать его, обновлять, удалять.
Поэтому мы решили разработать собственную систему обновления, которая была бы избавлена от перечисленных минусов.
Как работает trdl (на простом примере)
Структурно trdl представляет собой клиент-серверное приложение. trdl-сервер отвечает за безопасное наполнение и организацию TUF-репозитория, trdl-клиент — за надежную и непрерывную доставку обновлений, а также за использование ПО. Под обновлением подразумевается произвольный набор файлов для всех поддерживаемых платформ: бинарные файлы, shell-скрипты, Ansible-плейбуки и так далее.
Процесс обновления включает три основных этапа:
Релиз новой версии ПО.
Публикация каналов обновлений (переключение новой версии в канале/каналах обновлений).
Скачивание релиза через канал обновлений.
Рассмотрим подробно первые два этапа.
Релиз новой версии ПО
В начале разработчик создает Git-тег с новой версией ПО (на картинке ниже — v1.0.1) и подписывает его своей GPG-подписью. Когда кворум проекта «дает добро», тег поступает в trdl-сервер. Если Git-тег содержит минимальный набор разрешённых GPG-подписей, инициируется сборка. Результат сборки вместе с метаданными загружаются в TUF-репозиторий. Но при этом клиент продолжает работать со старой версией ПО — v1.0.0.
Здесь:
GPG-1-3 — подписи, которые создаются командой разработки.
vault-plugin-secrets-trdl — плагин Vault, который проверяет наличие обязательных Git-подписей и инициирует сборку.
Artifact — результат сборки (бинарные файлы, скрипты или пакеты).
Release channel — канал обновления.
trdl-клиент — программа-клиент, которая установлена на сервер (VM) или ноутбук пользователя.
Публикация каналов обновлений
Разработчик изменяет конфигурацию каналов обновлений в Git и делает коммит со своей GPG-подписью. После одобрения кворумом коммит поступает в плагин Vault. Плагин проверяет, содержит ли коммит минимальный набор разрешённых GPG-подписей; если да — подписывает обновленный список каналов и связанных с ними релизов. Обновленные каналы вместе с метаданными загружаются в TUF-репозиторий. Пользователи начинают получать обновления в соответствии с новой конфигурацией каналов обновлений.
Готовность trdl к production
Мы уже используем trdl для непрерывной доставки нашего CI/CD-инструмента werf на CI-раннеры и пользовательские хосты. У команды разработки werf появился удобный и безопасный процесс доставки, а у пользователей — простой клиент для надежной работы с актуальными версиями утилиты.
Как пользоваться trdl
В разделе «Быстрый старт» рассказано, как установить и настроить ключевые элементы системы. Есть базовые сценарии для администратора, разработчика и пользователя.
В «Справочнике» — команды trdl-клиента, API trdl-сервера, а также конфигурация сборки и каналов обновления с примерами.
Подробно о том, как устроена система защиты trdl, от чего она защищает, а от чего — нет, объясняется в разделе «Безопасность».
P.S.
trdl — Open Source-проект, который активно развивается. Мы приглашаем поучаствовать в его развитии всех заинтересованных пользователей. Присылайте свои предложения, замечания, PR’ы.
И, конечно, мы будем признательны за звездочки на GitHub ;)
P.P.S.
Читайте также в нашем блоге:
Комментарии (17)
vitaly_il1
29.04.2022 16:09+4Как всегда когда слышу про новый инструмент, мне было бы очень интересно увидеть обзор существующих вещей и сравнение, в чем новый от них отличается.
Статьи типа - "мы придумали СуперПуперСистему, инсталлируй, нажми на кнопки А,Б,С и будет тебе счастье" у меня энтузиазма не вызывают.
identw
29.04.2022 18:16+3А есть аналоги? Я если честно подобных не знаю. Всякие dnf/yum/apt/brew/etc аналогом считать не могу, так как они заточены для конкретных ОС и дистрибутивов
aigrychev Автор
29.04.2022 18:31+4Мы по сути ничего не переизобретаем, берём стандарты сферы и склеиваем их — по аналогии с werf (если вам знаком наш инструмент доставки). Аналоги есть, но только для отдельных кусков процесса.
TUF позволяет гарантировать актуальность, согласованность, целостность данных, а самое главное защиту от большинства угроз. Мы имплементируем TUF-репозиторий trdl-сервером и предоставляем trdl-клиент для пользователей, которые работают согласно The Update Framework (TUF).
Vault позволяет построить систему, в которой ни у кого нету доступа до ключей шифрования и нет возможности их каким-либо образом получить (т.е. весь релизный процесс доставки может выполняться исключительно плагином). Мы запускаем наш trdl-сервер как плагин Vault и реализуем весь процесс доставки, используя Git как главный источник правды. Команда разработки ограничена всего двумя методами API и никак не пересекается с инфраструктурой.
Более подробно можно почитать на нашем сайте в разделе Безопасность.
slonopotamus
29.04.2022 20:46+3Это всё хорошо и замечательно, только вот HashiCorp начиная с марта блокирует загрузку их продуктов в РФ. Не думали поменять Vault на что-то менее политизированное?
burnashev
30.04.2022 17:30+2Их продукты доступны на GitHub
А для провайдеров терраформ есть зеркало: https://registry.tfpla.net/
aigrychev Автор
30.04.2022 17:57+2На текущий момент у нас есть только такая имплементация trdl-сервера, при которой сервер запускается как плагин Vault.
Мы могли бы предоставить пользователю возможность запускать сервер вне и использовать произвольную KMS, но такая реализация не позволит гарантировать текущую надёжность системы — чёрный ящик с несколькими ручками выглядит убедительнее.
В целом спасибо за вопрос, будем взвешивать риски и при необходимости добавлять новые имплементации.
MMgo
пытаюсь понять - кому\зачем оно надо.
TRDL нужен для доставки апдейтов клиентам, что живут вне твоего доверенного контура
То-есть клиенту, которому ты даешь какой-то свой софт, и канал для обновлений
Правильно?
aigrychev Автор
trdl — это система безопасной и непрерывной доставки, которая заточена под определённый флоу. Это касается как разработки, так и использования ПО пользователями (планируется множество флоу использования).
Команда разработки получает готовый флоу, позволяющий непрерывно выполнять релизы ПО для всех поддерживаемых платформ и переключать их в каналах обновлений, с той периодичностью которая необходима. Никто не имеет доступа к инфраструктуре, а все операции выполняются только по согласию кворума (минимального набора разрешённых GPG-подписей). Ещё один важный момент, что вся конфигурация хранится в Git и нет такой проблемы как локально работает, а на произвольном этапе доставки всё разваливается.
Для пользователей — это в первую очередь безопасность обновлений, которая гарантируется реализацией TUF-репозитория, а также инструмент использования артефактов ПО по каналам обновлений (пользователь оперирует каналами с определённым уровнем совместимости и стабильности), который одинаково работает на всех платформах и предлагает готовые флоу. К примеру, следующим образом можно добавить все исполняемые файлы ПО в PATH и работать с ними в рамках текущей shell-сессии, а обновления запустить в фоне для последующего использования (удобно в CI): `. $(trdl use werf 1.2 stable)`.
gecube
Честно - пока похоже на маркетинг, простите. Дело действительно нужное. Проблема существует. Посмотрим, как инструмент поведёт себя на практике.
Но хотелось бы сразу понять - кворум не защищает. Теоретически могли ранее внедрить уязвимость и вчерашний «доверенный» код уже не доверенный. Как планируете в этом случае отзывать подписи и релиз? Как клиенты поймут, что релиз косячный? И, пожалуйста, не говорите, что так не бывает. Каждый день - наверное, нет, но сколько уже было скандалов, когда какие-нибудь приватные ключи утекали и в результате хакеры могли те же вредоносы под видом драйверов публиковать так, что пользователь не замечает.
Ещё непонятно - как это поможет на целевой машине. Я хотел бы видеть контроль не в моменте доставки артефакта на целевую машину, а в момент его запуска. То есть на уровне того же докера, например, или в момент установки yum/apt (rpm/deb) пакетов. Как это реализовано?
gecube
Касательно названия - мне лично игра с буквами понравилась ) TLDR или trdl )))
aigrychev Автор
Кворум позволяет сделать процесс надёжнее, снизив риски от человеческих ошибок, компрометации доверенных GPG-ключей, нарушения регламента и т.д. - команда разработки отвечает за доставку и никто не может обойти это условие (минимум M подписей из N доверенных) при совершении релиза или переключении версий в каналах обновлений. Вопрос скорее культурный, поэтому сам по себе кворум действительно ни от чего не защищает.
Штатная ситуация. В наш процесс закладывается непрерывность использования артефактов обновлений. Как только проблема обнаруживается выполняется релиз новой версии/откат версии в канале обновлений и все пользователи получают стабильную версию.
Пользователь получает надёжный канал доставки (верификация источника, целостность данных, ...), а защита от угроз, связанных с [физическим] доступом злоумышленника к хосту, это задача в полной мере нерешаемая, если на хосте не соблюдаются базовые методы защиты - злоумышленник может просто подменить trdl-клиент.
gecube
Да даже внутри контура есть вопросики. Вся эта история про «доверенный контур» - булшит и не работает в XXI веке. Нет доверенного контура. Везде должен быть zero trust. А с разрабами ещё веселее, когда их 20+ команд… кто задеплоил? Когда? Что?
MMgo
ZeroTrust - всецело поддерживаю.
Но я наверное пока проблематики не вижу.
В моем понимании - библиотеки ставятся только из внутрених зеркал.
Добавление библиотеки в внутреннее зеркало - история с апрувами, и сканами уязвимостей. Установка зависимостей на шаге CI\CD с изоляцией от внешней сети и только из внутренних зеркал.
Минимальное вмешательство человека в процессы релиза и деплоя
gecube
это не решает проблему полностью
я именно такой регламент не так давно писал. Очевидно, почему так надо делать. Но это не закрывает вопрос внутреннего нарушителя ;-).
да, согласен