ホーム
製品
OpenShift Container Platform
4.20
Nodes
12.4. イメージポリシー CR の作成

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) の鍵、Bring Your Own Public Key Infrastructure (BYOPKI) 証明書、または Cosign の公開鍵と秘密鍵のペアを用意する。
イメージに署名するための署名プロセスがある。
Cosign 署名を使用している場合は、Cosign 署名をサポートするレジストリーにアクセスできる。
BYOPKI 証明書を信頼のルートとして使用している場合は、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/v1
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
信頼のルートを定義するポリシータイプ (公開鍵、BYOPKI 証明書、または Fulcio 証明書) を指定します。ここでは、Rekor 検証を使用する公開鍵です。
7
公開鍵ポリシーの場合、base64 でエンコードされた公開鍵を PEM 形式で指定します。最大長は 8192 文字です。
8
オプション: base64 でエンコードされた Rekor 公開鍵を PEM 形式で指定します。最大長は 8192 文字です。
9
オプション: 署名と実際のイメージアイデンティティーのアイデンティティーを検証するためのプロセスとして、次のいずれかを指定します。
MatchRepoDigestOrExact。
MatchRepository。
ExactRepository。exactRepository パラメーターを指定する必要があります。
RemapIdentity。prefix および signedPrefix パラメーターを指定する必要があります。
BYOPKI ポリシーおよび MatchRepository 一致ポリシーのイメージポリシーオブジェクトの例
```
apiVersion: config.openshift.io/v1alpha1
kind: ImagePolicy 
```
1
```
metadata:
  name: pki-policy
  namespace: mynamespace 
```
2
```
spec:
  scopes:
  - example.io 
```
3
```
  policy: 
```
4
```
    rootOfTrust: 
```
5
```
      policyType: PKI 
```
6
```
      pki: 
```
7
```
        caRootsData: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk....RVJUSUZJQ0FURS0tLS0t
        caIntermediatesData: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURkVENDQ....0QT09Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0=
        pkiCertificateSubject: 
```
8
```
          email: email@example.com
          hostname: myhost.example.com
    signedIdentity:
      matchPolicy: MatchRepository 
```
9
1
ImagePolicy オブジェクトを作成します。
2
イメージポリシーが適用される namespace を指定します。
3
このポリシーに割り当てられるリポジトリーまたはイメージのリストを定義します。
4
イメージの検証方法を定義するパラメーターを指定します。
5
ポリシーの Root of Trust を定義します。
6
信頼のルートを定義するポリシータイプ (公開鍵、BYOPKI 証明書、または Fulcio 証明書) を指定します。ここでは BYOPKI 証明書です。
7
BYOPKI 証明書の場合は、caRootsData を指定します。このパラメーターは、base64 でエンコードされた PEM 形式の CA ルート証明書を指定します。最大長は 8192 文字です。必要に応じて、caIntermediatesData で、base64 でエンコードされた PEM 形式の中間 CA ルート証明書を指定します。最大長は 8192 文字です。
8
ホスト名とメールアドレスを使用してユーザーのアイデンティティーを認証するためのサブジェクト代替名 (SAN) を指定します。
email。証明書の生成時に指定したメールアドレスを指定します。
hostname。証明書の生成時に指定したホスト名を指定します。
9
BYOPKI 証明書の場合、署名内のアイデンティティーと実際のイメージアイデンティティーを検証するために、MatchRepository を指定します。デフォルトの署名アイデンティティーは matchRepoDigestOrExact です。これは、ダイジェストの指定を必要とします。この場合の署名は、ダイジェスト付きイメージのために作成されたものではありません。
Fulcio 証明書ポリシーと ExactRepository 一致ポリシーを含むイメージポリシーオブジェクトの例
```
apiVersion: config.openshift.io/v1
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
信頼のルートを定義するポリシータイプ (公開鍵、BYOPKI 証明書、または 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"
     }
# ...

新しいイメージポリシーを示す BYOPKI 証明書のイメージポリシーオブジェクトの出力例

# ...
 "transports": {
# ...
    "docker": {
      "docker.io": [
        {
          "type": "sigstoreSigned",
          "pki": {
            "caRootsData": "LS0t...LS0t",
            "caIntermediatesData": "LS0t...LS0t"
            "subjectEmail": "email@example.com",
            "subjectHostname": "myhost.example.com"
          },
          "signedIdentity": {
            "type": "matchRepository"
          }
        }
      ],

新しいイメージポリシーを示す 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"


msg="Using transport \"docker\" specific policy section \"example.io/crio/signed\"" file="signature/policy_eval.go:150"


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"
# ...

1: IsRunningImageAllowed 行は、設定された sigstore 検証ポリシーがイメージを許可していることを示しています。
2: Using transport \"docker\" specific policy section \"example.io/crio/signed\"" file="signature/policy_eval.go:150 行は、イメージポリシーが適用されたことを示しています。

12.4. イメージポリシー CR の作成

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links