Helmの来歴と完全性

Helmには、チャートユーザーがパッケージの完全性と出所を検証するのに役立つ来歴ツールがあります。PKI、GnuPG、および定評のあるパッケージマネージャーに基づいた業界標準のツールを使用することで、Helmは署名ファイルを生成および検証できます。

概要

完全性は、チャートを来歴レコードと比較することで確立されます。来歴レコードは、パッケージ化されたチャートとともに保存される来歴ファイルに保存されます。たとえば、チャートの名前がmyapp-1.2.3.tgzの場合、その来歴ファイルはmyapp-1.2.3.tgz.provになります。

来歴ファイルはパッケージング時 (helm package --sign ...) に生成され、複数のコマンド、特にhelm install --verifyでチェックできます。

ワークフロー

このセクションでは、来歴データを効果的に使用するための潜在的なワークフローについて説明します。

前提条件

バイナリ（ASCII装甲ではない）形式の有効なPGPキーペア
helm コマンドラインツール
GnuPG コマンドラインツール (オプション)
Keybase コマンドラインツール (オプション)

注: PGP秘密鍵にパスフレーズがある場合は、--signオプションをサポートするすべてのコマンドでそのパスフレーズを入力するように求められます。

新しいチャートの作成は以前と同じです

$ helm create mychart
Creating mychart

パッケージ化の準備ができたら、helm packageに--signフラグを追加します。また、署名キーが認識される名前と、対応する秘密鍵を含むキーリングを指定します

$ 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 v2は、デフォルトの場所~/.gnupg/pubring.kbxに新しい形式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

署名付きチャートに関連付けられた公開キーを含むキーリングがデフォルトの場所ではない場合は、helm packageの例のように、--keyring PATHでキーリングを指す必要がある場合があります。

検証に失敗した場合、チャートがレンダリングされる前にインストールは中止されます。

Keybase.ioの資格情報を使用する

Keybase.ioサービスを使用すると、暗号化されたIDの信頼チェーンを簡単に確立できます。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) は、人間とツールの両方がチャートの内容を簡単に表示できるように含まれています。
チャートパッケージ (.tgzファイル) の署名 (Dockerと同じSHA256) が含まれており、チャートパッケージの完全性を検証するために使用できます。
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セクションには、2つのドキュメント (...\nで区切られています) が含まれていることに注意してください。最初のファイルはChart.yamlの内容です。2番目は、チェックサム、つまりパッケージング時のファイルの内容の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の「セキュアWebサイト」機能は、Helmチャートを配信するために使用できる可能性があります。
- 基本的な考え方としては、公式の「チャートレビュー担当者」が自身のキーでチャートに署名し、その結果生成される来歴ファイルをチャートリポジトリにアップロードするというものです。
- 有効な署名キーのリストをリポジトリのindex.yamlファイルに含めるというアイデアに関する作業も進められています。