12.4. イメージポリシー CR の作成
クラスター管理者またはアプリケーション開発者は、ImagePolicy
カスタムリソース (CR) を使用して、特定の namespace に対して sigstore 署名検証ポリシーを設定できます。MCO は、さまざまな namespace の ImagePolicy
インスタンスを監視し、クラスター内のすべてのノード上の /etc/crio/policies/<namespace>.json
および /etc/containers/registries.d/sigstore-registries.yaml
ファイルを更新します。
イメージポリシー内のスコープ指定されたイメージまたはリポジトリーが、クラスターイメージポリシー内のスコープイメージまたはリポジトリーのいずれかの下にネストされている場合、クラスターイメージポリシーのポリシーのみが適用されます。ただし、イメージポリシーオブジェクトはエラーメッセージとともに作成されます。たとえば、イメージポリシーで example.com/global/image
が指定され、クラスターイメージポリシーで example.com/global
が指定されている場合、namespace はクラスターイメージポリシーからポリシーを継承します。
次の例は、ImagePolicy
オブジェクトの設定方法に関する一般的なガイドラインを示しています。パラメーターの詳細は、「クラスターおよびイメージポリシーのパラメーターについて」を参照してください。
前提条件
- 署名操作用に、sigstore でサポートされている公開鍵基盤 (PKI) がある、または Cosign 公開鍵と秘密鍵のペア を提供する。
- イメージに署名するための署名プロセスがある。
- Cosign 署名を使用している場合は、Cosign 署名をサポートするレジストリーにアクセスできる。
OpenShift Container Platform リリースイメージリポジトリー (
quay.io/openshift-release-dev/ocp-release
およびquay.io/openshift-release-dev/ocp-v4.0-art-dev
) 用にレジストリーミラーが設定されている場合は、テクノロジープレビュー機能セットを有効にする前に、OpenShift Container Platform リリースイメージの sigstore 署名をミラーレジストリーにミラーリングした。そうしていない場合、リリースリポジトリーの署名検証を強制するデフォルトのOpenShift
クラスターイメージポリシーによって、CVO Pod を新しいノードに移動する Cluster Version Operator 機能がブロックされ、機能セットの変更から生じるノードの更新が妨げられます。oc image mirror
コマンドを使用して署名をミラーリングできます。以下に例を示します。$ oc image mirror quay.io/openshift-release-dev/ocp-release:sha256-1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef.sig \ mirror.com/image/repo:sha256-1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef.sig
cluster
という名前のFeatureGate
CR を編集して、クラスターに必要なテクノロジープレビュー機能を有効にした。$ oc edit featuregate cluster
FeatureGate
CR の例apiVersion: config.openshift.io/v1 kind: FeatureGate metadata: name: cluster spec: featureSet: TechPreviewNoUpgrade 1
- 1
- 必要な
SigstoreImageVerification
機能を有効にします。
警告クラスターで
TechPreviewNoUpgrade
機能セットを有効にすると、元に戻すことができず、マイナーバージョンの更新が妨げられます。この機能セットを使用すると、該当するテクノロジープレビュー機能をテストクラスターで有効にして、完全にテストすることができます。実稼働クラスターではこの機能セットを有効にしないでください。変更を保存すると、新規マシン設定が作成され、マシン設定プールが更新され、変更が適用されている間に各ノードのスケジューリングが無効になります。
手順
次の例のようなイメージポリシーオブジェクトを作成します。これらのパラメーターの詳細は、「クラスターおよびイメージポリシーのパラメーターについて」を参照してください。
公開鍵ポリシーと
MatchRepository
一致ポリシーを含むイメージポリシーオブジェクトの例apiVersion: config.openshift.io/v1alpha1 kind: ImagePolicy 1 metadata: name: p0 namespace: mynamespace 2 spec: scopes: 3 - example.io/crio/signed policy: 4 rootOfTrust: 5 policyType: PublicKey 6 publicKey: keyData: a2V5RGF0YQ== 7 rekorKeyData: cmVrb3JLZXlEYXRh 8 signedIdentity: matchPolicy: MatchRepository 9
- 1
ImagePolicy
オブジェクトを作成します。- 2
- イメージポリシーが適用される namespace を指定します。
- 3
- このポリシーに割り当てられるリポジトリーまたはイメージのリストを定義します。
- 4
- イメージの検証方法を定義するパラメーターを指定します。
- 5
- ポリシーの Root of Trust を定義します。
- 6
- Root of Trust を定義するポリシータイプ (公開鍵または Fulcio 証明書) を指定します。ここでは、Rekor 検証を使用する公開鍵です。
- 7
- 公開鍵ポリシーの場合、base64 でエンコードされた公開鍵を PEM 形式で指定します。最大長は 8192 文字です。
- 8
- オプション: base64 でエンコードされた Rekor 公開鍵を PEM 形式で指定します。最大長は 8192 文字です。
- 9
- オプション: 署名と実際のイメージアイデンティティーのアイデンティティーを検証するためのプロセスとして、次のいずれかを指定します。
-
MatchRepoDigestOrExact
。 -
MatchRepository
。 -
ExactRepository
。exactRepository
パラメーターを指定する必要があります。 -
RemapIdentity
。prefix
およびsignedPrefix
パラメーターを指定する必要があります。
-
Fulcio 証明書ポリシーと
ExactRepository
一致ポリシーを含むイメージポリシーオブジェクトの例apiVersion: config.openshift.io/v1alpha1 kind: ImagePolicy 1 metadata: name: p1 namespace: mynamespace 2 spec: scopes: 3 - example.io/crio/signed policy: 4 rootOfTrust: 5 policyType: FulcioCAWithRekor 6 fulcioCAWithRekor: 7 fulcioCAData: a2V5RGF0YQ== fulcioSubject: oidcIssuer: "https://expected.OIDC.issuer/" signedEmail: "expected-signing-user@example.com" rekorKeyData: cmVrb3JLZXlEYXRh 8 signedIdentity: matchPolicy: ExactRepository 9 exactRepository: repository: quay.io/crio/signed 10
- 1
ImagePolicy
オブジェクトを作成します。- 2
- イメージポリシーが適用される namespace を指定します。
- 3
- このポリシーに割り当てられるリポジトリーまたはイメージのリストを定義します。
- 4
- イメージの検証方法を定義するパラメーターを指定します。
- 5
- ポリシーの Root of Trust を定義します。
- 6
- Root of Trust を定義するポリシータイプ (公開鍵または Fulcio 証明書) を指定します。ここでは、必要な Rekor 検証を含む Fulcio 証明書を示します。
- 7
- Fulcio 証明書ポリシーの場合、次のパラメーターが必要です。
-
fulcioCAData
: base64 でエンコードされた Fulcio 証明書を PEM 形式で指定します。最大長は 8192 文字です。 -
fulcioSubject
: OIDC 発行者と Fulcio 認証設定のメールを指定します。
-
- 8
- base64 でエンコードされた Rekor 公開鍵を PEM 形式で指定します。このパラメーターは、
policyType
がFulcioCAWithRekor
の場合に必要です。最大長は 8192 文字です。 - 9
- オプション: 署名と実際のイメージアイデンティティーのアイデンティティーを検証するためのプロセスとして、次のいずれかを指定します。
-
MatchRepoDigestOrExact
。 -
MatchRepository
。 -
ExactRepository
。exactRepository
パラメーターを指定する必要があります。 -
RemapIdentity
。prefix
およびsignedPrefix
パラメーターを指定する必要があります。
-
- 10
exactRepository
一致ポリシーの場合、イメージアイデンティティーと署名を含むリポジトリーを指定します。
イメージポリシーオブジェクトを作成します。
$ oc create -f <file_name>.yaml
Machine Config Operator (MCO) は、クラスター内のマシン設定プール (MCP) を更新します。
検証
クラスター内のノードが更新されたら、イメージポリシーが設定されていることを確認できます。
次のコマンドを実行して、ノードのデバッグ Pod を起動します。
$ oc debug node/<node_name>
次のコマンドを実行して、デバッグシェル内のルートディレクトリーとして
/host
を設定します。sh-5.1# chroot /host/
次のコマンドを実行して、
<namespace>.json
ファイルを調べます。sh-5.1# cat /etc/crio/policies/<namespace>.json
新しいイメージポリシーを示す公開鍵を含むイメージポリシーオブジェクトの出力例
# ... "transports": { # ... "docker": { "example.io/crio/signed": [ { "type": "sigstoreSigned", "keyData": "a2V5RGF0YQ==", "rekorPublicKeyData": "cmVrb3JLZXlEYXRh", "signedIdentity": { "type": "matchRepository", "dockerRepository": "example.org/crio/signed" } # ...
新しいイメージポリシーを示す Fulcio 証明書を含むイメージポリシーオブジェクトの出力例
# ... "transports": { # ... "docker": { "example.io/crio/signed": [ { "type": "sigstoreSigned", "fulcio": { "caData": "a2V5RGF0YQ==", "oidcIssuer": "https://expected.OIDC.issuer/", "subjectEmail": "expected-signing-user@example.com" }, "rekorPublicKeyData": "cmVrb3JLZXlEYXRh", "signedIdentity": { "type": "exactRepository", "dockerRepository": "quay.io/crio/signed" } } ], # ...
次のコマンドを実行して、
sigstore-registries.yaml
ファイルを調べます。sh-5.1# cat /etc/containers/registries.d/sigstore-registries.yaml
スコープ指定されたレジストリーが追加されたことを示す出力例
docker: example.io/crio/signed: use-sigstore-attachments: true 1 quay.io/openshift-release-dev/ocp-release: use-sigstore-attachments: true
- 1
true
の場合、sigstore 署名をイメージと併せて読み取ることを指定しています。
次のコマンドを実行して、crio ログで sigstore 署名検証を確認します。
sh-5.1# journalctl -u crio | grep -A 100 "Pulling image: example.io/crio"
タイムスタンプを削除した出力例
# ... msg="IsRunningImageAllowed for image docker:example.io/crio/signed:latest" file="signature/policy_eval.go:274" 1 msg="Using transport \"docker\" specific policy section \"example.io/crio/signed\"" file="signature/policy_eval.go:150" 2 msg="Reading /var/lib/containers/sigstore/crio/signed@sha256=18b42e8ea347780f35d979a829affa178593a8e31d90644466396e1187a07f3a/signature-1" file="docker/docker_image_src.go:545" msg="Looking for Sigstore attachments in quay.io/crio/signed:sha256-18b42e8ea347780f35d979a829affa178593a8e31d90644466396e1187a07f3a.sig" file="docker/docker_client.go:1138" msg="GET https://quay.io/v2/crio/signed/manifests/sha256-18b42e8ea347780f35d979a829affa178593a8e31d90644466396e1187a07f3a.sig" file="docker/docker_client.go:617" msg="Content-Type from manifest GET is \"application/vnd.oci.image.manifest.v1+json\"" file="docker/docker_client.go:989" msg="Found a Sigstore attachment manifest with 1 layers" file="docker/docker_image_src.go:639" msg="Fetching Sigstore attachment 1/1: sha256:8276724a208087e73ae5d9d6e8f872f67808c08b0acdfdc73019278807197c45" file="docker/docker_image_src.go:644" # ...