Перейти к основному содержимому
Версия: 3.22.0

Происхождение и целостность Helm

Helm предоставляет инструменты проверки происхождения, которые помогают пользователям чартов подтвердить целостность и происхождение пакета. Используя отраслевые стандарты на основе PKI, GnuPG и проверенных менеджеров пакетов, Helm может генерировать и проверять файлы подписей.

Обзор​

Целостность устанавливается путём сравнения чарта с записью о происхождении. Записи о происхождении хранятся в файлах происхождения, которые размещаются вместе с упакованным чартом. Например, если чарт называется myapp-1.2.3.tgz, его файл происхождения будет называться myapp-1.2.3.tgz.prov.

Файлы происхождения создаются при упаковке (helm package --sign ...) и могут быть проверены несколькими командами, в частности helm install --verify.

Рабочий процесс​

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

Предварительные требования:

  • Действительная пара ключей PGP в бинарном формате (не ASCII-armored)
  • Инструмент командной строки helm
  • Инструменты командной строки GnuPG (опционально)
  • Инструменты командной строки Keybase (опционально)

ПРИМЕЧАНИЕ: Если ваш закрытый ключ PGP защищён парольной фразой, вам будет предложено ввести её для всех команд, поддерживающих опцию --sign.

Создание нового чарта выполняется как обычно:

$ helm create mychart
Creating mychart

Когда чарт готов к упаковке, добавьте флаг --sign к команде helm package. Также укажите имя, под которым известен ключ подписи, и связку ключей, содержащую соответствующий закрытый ключ:

$ helm package --sign --key 'John Smith' --keyring path/to/keyring.secret mychart

Примечание: Значение аргумента --key должно быть подстрокой uid нужного ключа (из вывода gpg --list-keys), например, именем или email. Отпечаток (fingerprint) использовать нельзя.

СОВЕТ: Для пользователей GnuPG секретная связка ключей находится в ~/.gnupg/secring.gpg. Вы можете использовать команду gpg --list-secret-keys для просмотра доступных ключей.

Предупреждение: В GnuPG v2 секретная связка ключей хранится в новом формате kbx в стандартном расположении ~/.gnupg/pubring.kbx. Используйте следующую команду для преобразования связки ключей в устаревший формат gpg:

$ gpg --export >~/.gnupg/pubring.gpg
$ gpg --export-secret-keys >~/.gnupg/secring.gpg

На этом этапе вы должны увидеть файлы mychart-0.1.0.tgz и mychart-0.1.0.tgz.prov. Оба файла следует загрузить в выбранный вами репозиторий чартов.

Вы можете проверить чарт с помощью helm verify:

$ helm verify mychart-0.1.0.tgz

Неудачная проверка выглядит следующим образом:

$ helm verify topchart-0.1.0.tgz
Error: sha256 sum does not match for topchart-0.1.0.tgz: "sha256:1939fbf7c1023d2f6b865d137bbb600e0c42061c3235528b1e8c82f4450c12a7" != "sha256:5a391a90de56778dd3274e47d789a2c84e0e106e1a37ef8cfa51fd60ac9e623a"

Для проверки при установке используйте флаг --verify:

$ helm install --generate-name --verify mychart-0.1.0.tgz

Если связка ключей с открытым ключом, соответствующим подписанному чарту, находится не в стандартном расположении, вам может потребоваться указать путь к ней с помощью --keyring PATH, как в примере с helm package.

При неудачной проверке установка будет прервана ещё до рендеринга чарта.

Использование учётных данных Keybase.io​

Сервис Keybase.io упрощает создание цепочки доверия для криптографической идентичности. Учётные данные Keybase можно использовать для подписи чартов.

Предварительные требования:

  • Настроенная учётная запись Keybase.io
  • Локально установленный GnuPG
  • Локально установленный CLI keybase

Подпись пакетов​

Первый шаг — импорт ваших ключей Keybase в локальную связку ключей GnuPG:

$ keybase pgp export -s | gpg --import

Эта команда преобразует ваш ключ Keybase в формат OpenPGP и импортирует его локально в файл ~/.gnupg/secring.gpg.

Вы можете проверить результат командой gpg --list-secret-keys:

$ gpg --list-secret-keys
/Users/mattbutcher/.gnupg/secring.gpg
-------------------------------------
sec 2048R/1FC18762 2016-07-25
uid technosophos (keybase.io/technosophos) <technosophos@keybase.io>
ssb 2048R/D125E546 2016-07-25

Обратите внимание, что ваш секретный ключ имеет идентификационную строку:

technosophos (keybase.io/technosophos) <technosophos@keybase.io>

Это полное имя вашего ключа.

Теперь вы можете упаковать и подписать чарт командой helm package. Убедитесь, что используете хотя бы часть этой строки имени в аргументе --key:

$ helm package --sign --key technosophos --keyring ~/.gnupg/secring.gpg mychart

В результате команда package создаст файлы .tgz и .tgz.prov.

Проверка пакетов​

Аналогичным образом можно проверить чарт, подписанный ключом Keybase другого пользователя. Допустим, вы хотите проверить пакет, подписанный keybase.io/technosophos. Для этого используйте инструмент keybase:

$ keybase follow technosophos
$ keybase pgp pull

Первая команда начинает отслеживание пользователя technosophos. Затем keybase pgp pull загружает OpenPGP-ключи всех отслеживаемых вами учётных записей и помещает их в вашу связку ключей GnuPG (~/.gnupg/pubring.gpg).

После этого вы можете использовать helm verify или любые команды с флагом --verify:

$ helm verify somechart-1.2.3.tgz

Причины, по которым проверка чарта может не пройти​

Вот типичные причины неудачной проверки:

  • Файл .prov отсутствует или повреждён. Это указывает на ошибку конфигурации или на то, что исходный сопровождающий не создал файл происхождения.
  • Ключ, использованный для подписи файла, отсутствует в вашей связке ключей. Это означает, что подписавшая сторона не входит в число тех, кому вы уже выразили доверие.
  • Проверка файла .prov не прошла. Это указывает на проблему либо с чартом, либо с данными о происхождении.
  • Хеши файлов в файле происхождения не совпадают с хешем файла архива. Это указывает на то, что архив был изменён.

При неудачной проверке есть основания не доверять пакету.

Файл происхождения​

Файл происхождения содержит YAML-файл чарта плюс несколько элементов проверочной информации. Файлы происхождения предназначены для автоматической генерации.

Добавляются следующие данные о происхождении:

  • Файл чарта (Chart.yaml) включается для того, чтобы люди и инструменты могли легко просмотреть содержимое чарта.
  • Подпись (SHA256, как в Docker) пакета чарта (файла .tgz) включается для проверки целостности пакета.
  • Всё тело подписывается с использованием алгоритма OpenPGP (см. Keybase.io как современный способ упростить криптографическую подпись и проверку).

Комбинация этих элементов даёт пользователям следующие гарантии:

  • Сам пакет не был изменён (контрольная сумма пакета .tgz).
  • Сторона, выпустившая этот пакет, известна (через подпись GnuPG/PGP).

Формат файла выглядит примерно так:

Hash: SHA512

apiVersion: v2
appVersion: "1.16.0"
description: Sample chart
name: mychart
type: application
version: 0.1.0

...
files:
mychart-0.1.0.tgz: sha256:d31d2f08b885ec696c37c7f7ef106709aaf5e8575b6d3dc5d52112ed29a9cb92
-----BEGIN PGP SIGNATURE-----

wsBcBAEBCgAQBQJdy0ReCRCEO7+YH8GHYgAAfhUIADx3pHHLLINv0MFkiEYpX/Kd
nvHFBNps7hXqSocsg0a9Fi1LRAc3OpVh3knjPfHNGOy8+xOdhbqpdnB+5ty8YopI
mYMWp6cP/Mwpkt7/gP1ecWFMevicbaFH5AmJCBihBaKJE4R1IX49/wTIaLKiWkv2
cR64bmZruQPSW83UTNULtdD7kuTZXeAdTMjAK0NECsCz9/eK5AFggP4CDf7r2zNi
hZsNrzloIlBZlGGns6mUOTO42J/+JojnOLIhI3Psd0HBD2bTlsm/rSfty4yZUs7D
qtgooNdohoyGSzR5oapd7fEvauRQswJxOA0m0V+u9/eyLR0+JcYB8Udi1prnWf8=
=aHfz
-----END PGP SIGNATURE-----

Обратите внимание, что YAML-секция содержит два документа (разделённых ...\n). Первый файл — содержимое Chart.yaml. Второй — контрольные суммы: соответствие имён файлов и SHA-256 дайджестов содержимого этих файлов на момент упаковки.

Блок подписи — это стандартная PGP-подпись, обеспечивающая защиту от изменений.

Репозитории чартов​

Репозитории чартов служат централизованным хранилищем чартов Helm.

Репозитории чартов должны обеспечивать возможность получения файлов происхождения по HTTP через определённый запрос и делать их доступными по тому же URI-пути, что и чарт.

Например, если базовый URL пакета — https://example.com/charts/mychart-1.2.3.tgz, то файл происхождения, если он существует, ДОЛЖЕН быть доступен по адресу https://example.com/charts/mychart-1.2.3.tgz.prov.

С точки зрения конечного пользователя, команда helm install --verify myrepo/mychart-1.2.3 должна приводить к загрузке как чарта, так и файла происхождения без дополнительной настройки или действий со стороны пользователя.

Подписи в реестрах на базе OCI​

При публикации чартов в реестре на базе OCI можно использовать плагин helm-sigstore для публикации данных о происхождении в sigstore. Как описано в документации, процесс создания данных о происхождении и подписи ключом GPG остаётся стандартным, но команда helm sigstore upload позволяет опубликовать данные о происхождении в неизменяемый журнал прозрачности.

Установление авторитета и подлинности​

При работе с системами цепочки доверия важно иметь возможность установить авторитет подписывающей стороны. Иными словами, описанная выше система основана на том, что вы доверяете лицу, подписавшему чарт. А это, в свою очередь, означает, что вам нужно доверять открытому ключу подписывающей стороны.

Одним из проектных решений Helm стало то, что проект Helm не будет включать себя в цепочку доверия как обязательную сторону. Мы не хотим быть «центром сертификации» для всех подписывающих чарты. Вместо этого мы настоятельно поддерживаем децентрализованную модель, что является одной из причин выбора OpenPGP в качестве базовой технологии. Поэтому, когда речь идёт об установлении авторитета, мы оставили этот шаг практически неопределённым в Helm 2 (это решение сохранено и в Helm 3).

Тем не менее у нас есть рекомендации для тех, кто заинтересован в использовании системы происхождения:

  • Платформа Keybase предоставляет публичный централизованный репозиторий информации о доверии.
    • Вы можете использовать Keybase для хранения своих ключей или получения открытых ключей других пользователей.
    • Keybase также предоставляет отличную документацию.
    • Хотя мы не тестировали это, функция «безопасного веб-сайта» Keybase может использоваться для размещения чартов Helm.
    • Основная идея заключается в том, что официальный «рецензент чартов» подписывает чарты своим ключом, а полученный файл происхождения загружается в репозиторий чартов.
    • Ведётся работа над идеей включения списка допустимых ключей подписи в файл index.yaml репозитория.