Pull to refresh

Comments 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 на что-то менее политизированное?

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

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

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

Объясните на пальцах, чем это отличается от репозитория nexus или artifactory или это просто еще один репозитарий для хранения бинарей? Мне в статье не хватило сравнительной таблицы.

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

спс, посмотрю на сайте повнимательнее

Sign up to leave a comment.