Комментарии 24
пытаюсь понять - кому\зачем оно надо.
TRDL нужен для доставки апдейтов клиентам, что живут вне твоего доверенного контура
То-есть клиенту, которому ты даешь какой-то свой софт, и канал для обновлений
Правильно?
trdl — это система безопасной и непрерывной доставки, которая заточена под определённый флоу. Это касается как разработки, так и использования ПО пользователями (планируется множество флоу использования).
Команда разработки получает готовый флоу, позволяющий непрерывно выполнять релизы ПО для всех поддерживаемых платформ и переключать их в каналах обновлений, с той периодичностью которая необходима. Никто не имеет доступа к инфраструктуре, а все операции выполняются только по согласию кворума (минимального набора разрешённых GPG-подписей). Ещё один важный момент, что вся конфигурация хранится в Git и нет такой проблемы как локально работает, а на произвольном этапе доставки всё разваливается.
Для пользователей — это в первую очередь безопасность обновлений, которая гарантируется реализацией TUF-репозитория, а также инструмент использования артефактов ПО по каналам обновлений (пользователь оперирует каналами с определённым уровнем совместимости и стабильности), который одинаково работает на всех платформах и предлагает готовые флоу. К примеру, следующим образом можно добавить все исполняемые файлы ПО в PATH и работать с ними в рамках текущей shell-сессии, а обновления запустить в фоне для последующего использования (удобно в CI): `. $(trdl use werf 1.2 stable)`.
Честно - пока похоже на маркетинг, простите. Дело действительно нужное. Проблема существует. Посмотрим, как инструмент поведёт себя на практике.
Но хотелось бы сразу понять - кворум не защищает. Теоретически могли ранее внедрить уязвимость и вчерашний «доверенный» код уже не доверенный. Как планируете в этом случае отзывать подписи и релиз? Как клиенты поймут, что релиз косячный? И, пожалуйста, не говорите, что так не бывает. Каждый день - наверное, нет, но сколько уже было скандалов, когда какие-нибудь приватные ключи утекали и в результате хакеры могли те же вредоносы под видом драйверов публиковать так, что пользователь не замечает.
Ещё непонятно - как это поможет на целевой машине. Я хотел бы видеть контроль не в моменте доставки артефакта на целевую машину, а в момент его запуска. То есть на уровне того же докера, например, или в момент установки yum/apt (rpm/deb) пакетов. Как это реализовано?
Касательно названия - мне лично игра с буквами понравилась ) TLDR или trdl )))
Но хотелось бы сразу понять - кворум не защищает
Кворум позволяет сделать процесс надёжнее, снизив риски от человеческих ошибок, компрометации доверенных GPG-ключей, нарушения регламента и т.д. - команда разработки отвечает за доставку и никто не может обойти это условие (минимум M подписей из N доверенных) при совершении релиза или переключении версий в каналах обновлений. Вопрос скорее культурный, поэтому сам по себе кворум действительно ни от чего не защищает.
Теоретически могли ранее внедрить уязвимость и вчерашний «доверенный» код уже не доверенный
Штатная ситуация. В наш процесс закладывается непрерывность использования артефактов обновлений. Как только проблема обнаруживается выполняется релиз новой версии/откат версии в канале обновлений и все пользователи получают стабильную версию.
Я хотел бы видеть контроль не в моменте доставки артефакта на целевую машину, а в момент его запуска.
Пользователь получает надёжный канал доставки (верификация источника, целостность данных, ...), а защита от угроз, связанных с [физическим] доступом злоумышленника к хосту, это задача в полной мере нерешаемая, если на хосте не соблюдаются базовые методы защиты - злоумышленник может просто подменить trdl-клиент.
Как только проблема обнаруживается выполняется релиз новой версии/откат версии в канале обновлений и все пользователи получают стабильную версию.
Чем релиз нового поможет, если все доверие подорвано? И нужно каким-то образом отзывать и удалять скомпрометированные релизы - раз, и два - каким-то образом убирать скомпрометированные ключи?
Я уж не говорю о том, что пользователи могут не хотеть автоапдейт.
если на хосте не соблюдаются базовые методы защиты - злоумышленник может просто подменить trdl-клиент.
Тогда тем более не понимаю, чем это лучше стандартного релиза на гитхаб + проверки контрольных сумм и подписей
Чем релиз нового поможет, если все доверие подорвано? И нужно каким-то образом отзывать и удалять скомпрометированные релизы - раз... Я уж не говорю о том, что пользователи могут не хотеть автоапдейт.
Наша система обновлений рассчитана на то, что пользователи полностью доверяют команде разработки и всегда работают с актуальным ПО в рамках выбранного канала обновлений. А так как пользователь не имеет возможности скачать определённую версию, то и вопрос отзыва и удаления скомпрометированных релизов не стоит так остро.
два - каким-то образом убирать скомпрометированные ключи?
Скомпрометированный ключ продолжает использоваться, но уже совместно с новым. Не хочется уходить в дебри TUF, поэтому этот и другие сценарии лучше посмотреть в спецификации фреймворка, которую мы имплементируем в серверной и клиентской части системы.
Система полностью берёт на себя ответственность за ключи шифрования: автоматически создаёт, ротирует и хранит их в Vault. Ни у кого нет к ним доступа, никто не пересекается с ними.
Тогда тем более не понимаю, чем это лучше стандартного релиза на гитхаб + проверки контрольных сумм и подписей
Развивая тему с [физическим] доступом злоумышленника к хосту. Он с тем же успехом может подменить curl, gpg, ... и любой флоу посыпется.
Trdl-клиент верифицирует доверенный репозиторий (вот тут можно почитать от каких атак на систему обновлений защищает TUF), данные в нём, а также гарантирует согласованность и целостность скачанных данных. А примитивная защита trdl-клиента уже на плечах пользователя (в разделе Безопасность этот момент зафиксирован).
Если посмотреть на вопрос глобально, то мы предлагаем готовый процесс от и до.
А так как пользователь не имеет возможности скачать определённую версию,
Все, после этого можно не продолжать. Если Вы предоставляете SaaS - ваше право, но я понял, что речь про коробочный продукт в периметре заказчика, а раз так, то этот тезис не работает вовсе.
Мы не предоставляем SaaS. Система обновлений может использоваться в любых контурах. Другой вопрос — подходит ли навязываемый системой процесс доставки и использования именно для вашего флоу и ПО.
Что касается тезиса, то система обновления требует использовать клиент не только для обновления, но и для использования артефактов ПО, причём неразрывно.
TRDL нужен для доставки апдейтов клиентам, что живут вне твоего доверенного контура
Да даже внутри контура есть вопросики. Вся эта история про «доверенный контур» - булшит и не работает в XXI веке. Нет доверенного контура. Везде должен быть zero trust. А с разрабами ещё веселее, когда их 20+ команд… кто задеплоил? Когда? Что?
ZeroTrust - всецело поддерживаю.
Но я наверное пока проблематики не вижу.
В моем понимании - библиотеки ставятся только из внутрених зеркал.
Добавление библиотеки в внутреннее зеркало - история с апрувами, и сканами уязвимостей. Установка зависимостей на шаге CI\CD с изоляцией от внешней сети и только из внутренних зеркал.
Минимальное вмешательство человека в процессы релиза и деплоя
В моем понимании - библиотеки ставятся только из внутрених зеркал
это не решает проблему полностью
Установка зависимостей на шаге CI\CD с изоляцией от внешней сети и только из внутренних зеркал.
я именно такой регламент не так давно писал. Очевидно, почему так надо делать. Но это не закрывает вопрос внутреннего нарушителя ;-).
Минимальное вмешательство человека в процессы релиза и деплоя
да, согласен
Как всегда когда слышу про новый инструмент, мне было бы очень интересно увидеть обзор существующих вещей и сравнение, в чем новый от них отличается.
Статьи типа - "мы придумали СуперПуперСистему, инсталлируй, нажми на кнопки А,Б,С и будет тебе счастье" у меня энтузиазма не вызывают.
А есть аналоги? Я если честно подобных не знаю. Всякие dnf/yum/apt/brew/etc аналогом считать не могу, так как они заточены для конкретных ОС и дистрибутивов
Мы по сути ничего не переизобретаем, берём стандарты сферы и склеиваем их — по аналогии с werf (если вам знаком наш инструмент доставки). Аналоги есть, но только для отдельных кусков процесса.
TUF позволяет гарантировать актуальность, согласованность, целостность данных, а самое главное защиту от большинства угроз. Мы имплементируем TUF-репозиторий trdl-сервером и предоставляем trdl-клиент для пользователей, которые работают согласно The Update Framework (TUF).
Vault позволяет построить систему, в которой ни у кого нету доступа до ключей шифрования и нет возможности их каким-либо образом получить (т.е. весь релизный процесс доставки может выполняться исключительно плагином). Мы запускаем наш trdl-сервер как плагин Vault и реализуем весь процесс доставки, используя Git как главный источник правды. Команда разработки ограничена всего двумя методами API и никак не пересекается с инфраструктурой.
Более подробно можно почитать на нашем сайте в разделе Безопасность.
Это всё хорошо и замечательно, только вот HashiCorp начиная с марта блокирует загрузку их продуктов в РФ. Не думали поменять Vault на что-то менее политизированное?
Их продукты доступны на GitHub
А для провайдеров терраформ есть зеркало: https://registry.tfpla.net/
На текущий момент у нас есть только такая имплементация trdl-сервера, при которой сервер запускается как плагин Vault.
Мы могли бы предоставить пользователю возможность запускать сервер вне и использовать произвольную KMS, но такая реализация не позволит гарантировать текущую надёжность системы — чёрный ящик с несколькими ручками выглядит убедительнее.
В целом спасибо за вопрос, будем взвешивать риски и при необходимости добавлять новые имплементации.
tldr)
Объясните на пальцах, чем это отличается от репозитория nexus или artifactory или это просто еще один репозитарий для хранения бинарей? Мне в статье не хватило сравнительной таблицы.
Что касается репозитория артефактов, то мы не делаем ничего нового, просто имплементируем TUF-репозиторий. В отличие от Nexus и Artifactory фокус этого решения на безопасности самого репозитория, минимизации ущерба в случае компрометации и защите от большинства угроз. Если интересно, то лучше отдельно почитать на сайте продукта или в нашей недавней статье.
Представляем trdl — Open Source-решение для безопасной и непрерывной доставки обновлений