6.2. イメージソースのデプロイの制御
重要な点として、対象とするイメージが実際にデプロイされていることや、そのイメージが信頼されるソースからのものであること、またそれらが変更されていないことを確認できる必要があります。これは、暗号による署名を使用して実行できます。OpenShift Container Platform では、クラスター管理者がデプロイメント環境とセキュリティー要件を反映した (広義または狭義のものを含む) セキュリティーポリシーを適用できます。このポリシーは、以下の 2 つのパラメーターで定義されます。
- 1 つ以上のレジストリー (オプションのプロジェクト namespace を使用)
- 信頼タイプ (accept、reject、またはパブリックキーが必要)
これらのポリシーパラメーターにより、レジストリーまたはレジストリーの一部および個別のイメージもホワイトリスト化 (accept) またはブラックリスト化 (reject) するか、または信頼されたパブリックキーを使用して信頼関係を定義し、ソースが暗号を使って検証されていることを確認できます。このポリシールールはノードに適用されます。ポリシーは、すべてのノード全体に均一に適用されるか、または異なるノードのワークロード (例: ビルド、ゾーン、または環境) ごとにターゲットが設定される場合があります。
イメージ署名ポリシーファイルの例
{
"default": [{"type": "reject"}],
"transports": {
"docker": {
"access.redhat.com": [
{
"type": "signedBy",
"keyType": "GPGKeys",
"keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release"
}
]
},
"atomic": {
"172.30.1.1:5000/openshift": [
{
"type": "signedBy",
"keyType": "GPGKeys",
"keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release"
}
],
"172.30.1.1:5000/production": [
{
"type": "signedBy",
"keyType": "GPGKeys",
"keyPath": "/etc/pki/example.com/pubkey"
}
],
"172.30.1.1:5000": [{"type": "insecureAcceptAnything"}]
}
}
}
ポリシーは /etc/containers/policy.json としてノードに保存できます。この例では、以下のルールを実施しています。
-
Red Hat レジストリー (
access.redhat.com) からのイメージは Red Hat パブリックキーで署名される必要がある。 - openshift namespace 内の OpenShift Container レジストリーからのイメージは Red Hat パブリックキーで署名される必要がある。
-
production namespace 内の OpenShift Container レジストリーからのイメージは
example.comのパブリックキーで署名される必要がある。 -
グローバルの
default定義で指定されていないその他すべてのレジストリーは拒否される。
ホストの設定に関する詳細な説明については、イメージ署名サポートの有効化 を参照してください。署名トランスポート に関する詳細は、以下のセクションを参照してください。イメージ署名ポリシーに関する詳細は、署名検証ポリシーファイル形式 のソースコードについてのドキュメントを参照してください。
6.2.1. 署名トランスポート
署名トランスポートは、バイナリーの署名 Blob を保存および取得する方法です。署名トランスポートには、2 つのタイプあります。
-
atomic: OpenShift Container Platform API で管理される。 -
docker: ローカルファイルとして提供されるか、または Web サーバーによって提供される。
OpenShift Container Platform API は、atomic トランスポートタイプを使用する署名を管理します。このタイプの署名を使用するイメージは OpenShift Container レジストリーに保存する必要があります。docker/distribution extensions API はイメージ署名のエンドポイントを自動検出するため、追加の設定は不要になります。
docker トランスポートタイプを使用する署名は、ローカルファイルまたは Web サーバーによって提供されます。これらの署名には柔軟性があります。任意のコンテナーイメージレジストリーからイメージを提供でき、バイナリー署名の送信に個別のサーバーを使用することができます。 署名アクセスプロトコル (Signature access protocol) に応じて各イメージの署名に直接アクセスでき、サーバーディレクトリーのルートにはそのファイル構造が表示されません。
ただし、docker トランスポートタイプの場合には追加の設定が必要です。任意に名前が付けられた YAML ファイルをホストシステムのディレクトリー (/etc/containers/registries.d) にデフォルトとして配置し、ノードを署名サーバーの URI で設定する必要があります。YAML 設定ファイルには、レジストリー URI および署名サーバー URI が含まれます。 署名サーバー URI は、sigstore とも呼ばれます。
Registries.d ファイルの例
docker:
access.redhat.com:
sigstore: https://access.redhat.com/webassets/docker/content/sigstore
この例では、Red Hat レジストリー (access.redhat.com) は、docker タイプのトランスポートの署名を提供する署名サーバーです。Red Hat レジストリーの URI は、sigstore パラメーターで定義されます。このファイルに /etc/containers/registries.d/redhat.com.yaml という名前を付け、Ansible を使用してこのファイルをクラスター内の各ノード上に自動的に配置することができます。ポリシーと registries.d ファイルはコンテナーのランタイムで動的に読み込まれるため、サービスを再起動する必要はありません。
詳細については、レジストリー設定ディレクトリー (Registries Configuration Directory) または 署名アクセスプロトコル (Signature access protocol) のソースコードについてのドキュメントを参照してください。
参考文献
OpenShift Container Platform クラスター管理ガイド
Red Hat ナレッジベース
ソースコードのリファレンス
