Перейти до основного вмісту
Версія: 4.3.1

Підтвердження походження та цілісності в Helm

попередження

Цю сторінку ще не було оновлено для Helm 4. Деякі відомості можуть бути неточними або не стосуватися Helm 4. Докладнішу інформацію про нові функції, вдосконалення та істотні зміни в Helm 4 див. в Огляді Helm 4.

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), наприклад імʼя або електронна пошта. Відбиток (fingerprint) не може бути використаний.

порада

Для користувачів GnuPG, отримуйте перелік своїх секретних ключів за допомогою gpg --list-secret-keys. GnuPG 2.1+ більше не зберігає їх у ~/.gnupg/secring.gpg; див. примітку нижче.

попередження

Починаючи з GnuPG v2.1, відкриті ключі зберігаються у файлі звʼязки ключів (~/.gnupg/pubring.kbx), а не в застарілому ~/.gnupg/pubring.gpg. Для перевірки Helm (починаючи з версії 4.3.0) читає файли звʼязок ключів безпосередньо, а також відкриті звʼязки ключів у форматі ASCII-armored (gpg --export --armor) і застарілі бінарні звʼязки ключів, тож перетворення не потрібне. Підписання чарту працює інакше: Helm і далі потребує приватний ключ, експортований у файл звʼязки ключів (бінарний або ASCII-armored). Якщо ваш секретний ключ є лише в сучасному сховищі ключів GnuPG, спершу експортуйте його:

$ 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
  • Встановлений локально keybase CLI

Підписання пакунків​

Першим кроком є імпорт ваших ключів 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. Другий — це контрольні суми, map імен файлів та 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 репозиторію.