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

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

Огляд

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

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

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

Цей розділ описує можливий робочий процес ефективного використання даних походження.

Передумови:

Дійсна пара ключів PGP у бінарному (не ASCII-зашифрованому) форматі
Інструмент командного рядка 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), наприклад імʼя або електронна пошта. Відбиток не може бути використаний.

ПОРАДА: Для користувачів GnuPG ваша секретна вʼязка ключів знаходиться в ~/.gnupg/secring.gpg. Ви можете використовувати команду gpg --list-secret-keys, щоб переглянути наявні ключі.

Попередження: у GnuPG версії 2 ваша секретна вʼязка ключів зберігається у новому форматі 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 сума не співпадає для 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
uidtechnosophos (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 репозиторію.