Все, что вам нужно знать о проекте sigstore и его роли в обеспечении доверия и безопасности цепочки поставок программного обеспечения
В последние месяцы возникло много шума в области безопасности цепочки поставок из-за увеличения числа атак, таких как Microsoft Exchange Server, Colonial pipeline или Нарушение SolarWinds. Эти атаки можно было предотвратить с помощью соответствующих инструментов, но найти подходящий инструмент для работы может быть сложно, поскольку в этой области сложно ориентироваться, и большинство из нас, разработчиков, не являются экспертами по безопасности. Однако недавно был анонсирован новый проект, который может решить множество проблем для всех нас. Его имя - sigstore, и в этой статье мы рассмотрим, что он делает, зачем он нам нужен и как он вписывается в структуру существующих инструментов в этой области.
сиг-что?
sigstore - новичок в районе. Это проект под эгидой CNCF, который был «подарен» фонду в марте. Его цель - предоставить услугу для подписания программного обеспечения на благо общества. Это означает, что он должен стать программным эквивалентом подписи Let's Encrypt. Однако sigstore - это не просто инструмент или часть программного обеспечения, это набор проектов, направленных на упрощение подписи программного обеспечения и прозрачность. На данный момент это основные компоненты fulcio, rekor и cosign (подробнее о них чуть позже).
Теперь вы можете спросить «Зачем нам это вообще нужно?» - подпись программного обеспечения - не новая проблема, так что какое-то решение уже должно быть, верно? Да, но подписывать программное обеспечение и поддерживать ключи очень сложно, особенно для людей, не связанных с безопасностью, и UX существующих инструментов, таких как PGP, оставляет желать лучшего. Вот почему нам нужно что-то вроде sigstore - простого в использовании программного обеспечения / набора инструментов для подписи программных артефактов.
Кроме того, есть несколько причин, по которым решение sigstore превосходит такие инструменты, как PGP, которые пытаются решить ту же проблему. В отличие от других инструментов, с sigstore вам не нужно управлять закрытыми ключами. Вам также не нужно разбираться в стандартах безопасности благодаря лучшему UX. sigstore также упрощает управление отзывами, и при этом он по-прежнему предоставляет все необходимые функции подписи программного обеспечения, в том числе целостность, неотказуемость и аутентификацию .
Суть в том, что sigstore стремится сделать подписание артефактов настолько простым, чтобы это можно было делать по умолчанию и прозрачно, и оно повсеместно используется во всех реестрах и хранилищах артефактов.
Альтернативы
Из вышесказанного может показаться, что sigstore - это инструмент, который может все это решить, но если вы начнете гуглить, вы найдете множество отличных инструментов в области безопасности цепочки поставок. Однако большинство этих инструментов не служат одной и той же цели, и они действительно дополняют то, что делает sigstore. Итак, давайте также рассмотрим остальную часть ландшафта, чтобы увидеть, что еще есть:
- Один из многих инструментов, с которыми вы столкнетесь, - это The Update Framework (TUF). Он также является частью CNCF, и его цель - конкретно защитить процесс поиска и загрузки исправлений / обновлений для некоторой конкретной системы (например, YUM, PyPI). Эта система подходит для артефактов, которые предназначены для распространения с использованием системы обновлений.
- Говоря о TUF, имеет смысл также упомянуть Notary, который является реализацией спецификации TUF. В первую очередь он используется в Docker Notary, который предоставляет возможность использовать цифровые подписи для данных, отправляемых и получаемых из удаленных реестров Docker. Вы можете узнать больше о Docker Content Trust здесь или также можете попробовать поиграть с командой
docker trust. Если вы захотите реализовать что-то подобное, то вы можете ознакомиться с полной демонстрацией в этой статье. - Еще один отличный инструмент. Этот инструмент предназначен не только для подписи артефактов, но и для свидетельств о том, как было создано программное обеспечение. По сути, проверка того, что каждая задача в конвейере была выполнена в соответствии с планом, и, следовательно, обеспечение уверенности в том, что конечный продукт не был подделан. Вы можете использовать in-toto как часть Tekton Chains.
- Наконец, я также хочу упомянуть Trillian, который представляет собой журнал с отслеживанием несанкционированного доступа, в котором хранится точная, неизменяемая и поддающаяся проверке история активности. Этот вид журнала можно использовать, например, для добавления в систему проверки несанкционированного доступа, упрощения соблюдения нормативных требований или отслеживания изменений документов. sigstore также включает журнал контроля вскрытия под названием
rekor, о котором мы поговорим позже. - Мы могли бы поговорить о многом другом, но это займет некоторое время. Если вы хотите копнуть глубже, ознакомьтесь с разделами Страница CNCF Landscape и, в частности, Безопасность и соответствие (например, OPA) и Управление ключами (например, SPIFFE и SPIRE).
У всех этих инструментов есть свои плюсы и минусы, и их можно комбинировать и расширять для повышения безопасности. Для получения дополнительных сведений об этом вы можете проверить документ в репозитории сообщества sigstore (см. Раздел Дальнейшая работа).
Компоненты
Прежде чем мы углубимся в компоненты sigstore, нам сначала нужно понять основы процесса подписи. Основные шаги следующие:
- Генерируются недолговечные учетные данные для подписи кода (пара ключей).
- Пользователь аутентифицируется с помощью поставщика OpenID Connect (OIDC), такого как Google или GitHub, чтобы подтвердить право собственности на адрес электронной почты и владение ранее созданными ключами.
- Если аутентификация прошла успешно, пользователь получает сертификат для подписи кода.
- Сертификат для подписи кода публикуется в журнале прозрачности, чтобы его могли проверить другие.
- Пользователь подписывает артефакт (например, образ контейнера), используя сертификат подписи кода и свою пару ключей.
- Подпись артефакта публикуется в журнале прозрачности.
- Кратковременные учетные данные для подписи кода, используемые для создания подписи, уничтожаются.
- Подписанный артефакт может быть опубликован (например, в реестре контейнеров).
Другое объяснение процесса можно также найти на сайте sigstore в разделе «Что такое sigstore? раздел".
Теперь, когда у нас есть лучшее представление о том, как все это работает, давайте рассмотрим все компоненты. Есть несколько вещей, которые применимы ко всем из них, а именно, они могут (и должны) работать в облаке по умолчанию (работает в Kubernetes). Несмотря на то, что в sigstore размещена общественно полезная служба, вы можете взять любой из этих компонентов и разместить их самостоятельно (например, за брандмауэром), и вам также не нужно использовать всю службу, а может быть только один из них, например, просто сервер журнала прозрачности.
Что касается отдельных компонентов, в настоящее время существует 3 основных элемента:
- Cosign - инструмент для подписи контейнеров. В его обязанности входит подписание контейнеров и публикация этой информации в реестрах OCI. В приведенном выше процессе, который соответствует шагам 1, 5, 6 и 7.
- Fulcio - это корневой центр сертификации для сертификатов подписи кода. Его задача - выпускать сертификаты для подписи кода и встраивать идентификатор OIDC в сертификат для подписи кода. Из этого описания мы видим, что он выполняет эти задачи на шагах 2, 3, 4 и 8.
- Рекор - журнал прозрачности. Это неизменяемая бухгалтерская книга, предназначенная только для добавления, которая служит прозрачным источником достоверной информации о том, что и кем было подписано.
Теперь на практике вышеуказанные инструменты и службы будут использоваться для выполнения процесса подписи следующим образом:
cosign генерирует временную пару ключей и запрашивает сертификат подписи кода от fulcio, который затем просит вас войти в систему с помощью выбранного вами поставщика OIDC. Он использует аутентификацию, чтобы подтвердить, что вы являетесь владельцем эфемерного закрытого ключа. cosign затем получит манифест образа контейнера для изображения, которое вы хотите подписать, и сгенерирует подпись, используя ранее сгенерированный ключ. Затем cosign загружает в реестр подпись, сертификат и открытый ключ. Наконец, он отправляет информацию в rekor, который проверяет подпись и добавляет запись в журнал прозрачности. Здесь эта запись включает дайджест артефакта, подпись и открытый ключ. На этом этапе временная пара ключей может быть удалена.
В дополнение к этим программам также необходима служба мониторинга, которая проверяет журнал прозрачности (rekor) на предмет каких-либо аномалий. Примером такой аномалии может быть то, что кто-то украл ваш пароль и использовал вашу личность OpenID для подписи и публикации артефакта, что будет видно из журнала прозрачности.
Наконец, должен быть способ, например, сказать, кто является сопровождающим, которому на самом деле доверяют подписывать артефакты / выпуски какого-либо проекта. Это можно сделать, например, используя Open Policy Agent (OPA) и поддерживая список адресов электронной почты (идентификаторы OpenID) в репозитории проекта и позволяя подписывать артефакты только людям из этого списка.
Заключительные мысли
Подобные методы безопасности сейчас не совсем распространены, а в некоторых случаях им пренебрегают. Таким образом, чем больше людей начнут использовать это, тем больше вероятность, что он станет процессом по умолчанию и хорошей практикой. С учетом сказанного, на момент написания sigstore был очень молодым проектом и еще не готов к производству, но он должен быть к концу лета, так что очень скоро вы сможете найти хорошее применение и помощь этим знаниям. цепочка поставок программного обеспечения станет немного более безопасной.
С учетом всего сказанного, эта статья должна служить руководством по безопасности цепочки поставок и дать вам общее представление о sigstore, а в следующей статье мы подробно рассмотрим фактический процесс подписания с практическими примерами.
Ресурсы
Эта статья изначально была размещена на martinheinz.dev
