第9章 イメージポリシー
9.1. 概要
インポートするイメージや、タグ付けしたり、クラスターで実行したりするイメージを制御することができます。この目的のために使用できる 2 つの機能があります。
インポート用に許可されるレジストリーは、イメージの起点 (origin) を特定の外部レジストリーのセットに制限できるイメージポリシー設定です。このルールセットはイメージストリームにインポートされるか、またはタグ付けされるすべてのイメージに適用されます。したがって、ルールセットと一致しないレジストリーを参照するイメージは拒否されます。
ImagePolicy 受付プラグイン を使用すると、クラスターでの実行を許可するイメージを指定できます。これは現時点ではベータ機能と見なされています。この機能により、以下を制御することができます。
- イメージソース: イメージのプルに使用できるレジストリーについての指定。
- イメージの解決: イメージが再タグ付けによって変更されないよう Pod のイミュータブルなダイジェストでの実行を強制する。
- コンテナーイメージラベルの制限: イメージのラベルを制限するか、または要求する。
- イメージアノテーションの制限: 統合コンテナーレジストリーでのイメージのアノテーションを制限するか、または要求する。
9.2. インポート用に許可されるレジストリーの設定
以下の例に示されるように、imagePolicyConfig:allowedRegistriesForImport セクション以下にある master-config.yaml にインポート用に許可されるレジスターを設定できます。この設定がない場合は、すべてのイメージが許可されます。
例9.1 インポート用に許可されるレジストリーの設定例
imagePolicyConfig:
allowedRegistriesForImport:
-
domainName: registry.access.redhat.com 1
-
domainName: *.mydomain.com
insecure: true 2
-
domainName: local.registry.corp:5000 3各ルールは以下の属性で構成されています。
-
domainName: ホスト名であり、オプションでその最後は:<port>サフィックスになり、ここで特殊なワイルドカード文字 (?、*) が認識されます。ワイルドカード文字は:区切り文字の前後の両方に置くことができます。ワイルドカードは区切り文字の前または後の部分に適用されます。 -
insecure::<port>の部分がdomainNameにない場合、一致するポートを判別するために使用されるブール値です。true の場合、domainNameはインポート時に非セキュアなフラグが使用されている限り、サフィックスが:80のポートが設定されているか、またはポートが未指定のレジストリーに一致します。false の場合、サフィックスが:443のポートか、またはポートが未指定のレジストリーが一致します。
ルールが同じドメインのセキュアなポートと非セキュアなポートの両方に一致する場合、ルールは 2 回一覧表示されるはずです (1 回は insecure=true が設定され、もう 1 回は insecure=false が設定されます)。
修飾されていないイメージ参照は、ルールの評価前に docker.io に対して修飾されます。これらをホワイトリストに追加するには、domainName: docker.io を使用します。
domainName: * ルールは任意のレジストリーのホスト名に一致しますが、ポートは依然として 443 に制限された状態になります。任意のポートで機能する任意のレジストリーに一致させるには、domainName: *:* を使用します。
インポート用に許可されるレジストリーの設定例で設定されるルールに基づいて、以下が実行されます。
-
oc tag --insecure reg.mydomain.com/app:v1 app:v1は、mydomain.comルールの処理によってホワイトリストに追加されます。 -
oc import-image --from reg1.mydomain.com:80/foo foo:latestもホワイトリストに追加されます。 -
oc tag local.registry.corp/bar bar:latestは、ポートが 3 番目のルールの5000に一致しないために拒否されます。
拒否されたイメージのインポートにより、以下のテキストのようなエラーメッセージが生成されます。
The ImageStream "bar" is invalid: * spec.tags[latest].from.name: Forbidden: registry "local.registry.corp" not allowed by whitelist: "local.registry.corp:5000", "*.mydomain.com:80", "registry.access.redhat.com:443" * status.tags[latest].items[0].dockerImageReference: Forbidden: registry "local.registry.corp" not allowed by whitelist: "local.registry.corp:5000", "*.mydomain.com:80", "registry.access.redhat.com:443"
9.3. ImagePolicy 受付プラグインの設定
この機能を有効にするには、master-config.yaml でプラグインを設定します。
例9.2 アノテーション付きのサンプルファイル
admissionConfig:
pluginConfig:
openshift.io/ImagePolicy:
configuration:
kind: ImagePolicyConfig
apiVersion: v1
resolveImages: AttemptRewrite 1
executionRules: 2
- name: execution-denied
# Reject all images that have the annotation images.openshift.io/deny-execution set to true.
# This annotation may be set by infrastructure that wishes to flag particular images as dangerous
onResources: 3
- resource: pods
- resource: builds
reject: true 4
matchImageAnnotations: 5
- key: images.openshift.io/deny-execution
value: "true"
skipOnResolutionFailure: true 6
- name: allow-images-from-internal-registry
# allows images from the internal registry and tries to resolve them
onResources:
- resource: pods
- resource: builds
matchIntegratedRegistry: true
- name: allow-images-from-dockerhub
onResources:
- resource: pods
- resource: builds
matchRegistries:
- docker.io
resolutionRules: 7
- targetResource:
resource: pods
localNames: true
- targetResource: 8
group: batch
resource: jobs
localNames: true 9- 1
- イミュータブルなイメージダイジェストを使用してイメージを解決し、Pod でイメージのプル仕様を更新します。
- 2
- 着信リソースに対して評価するルールの配列です。reject==true ルールのみがある場合、デフォルトは allow all になります。accept ルールがある場合のデフォルトは deny all になります。
- 3
- ルールを実施するリソースを示します。何も指定されていない場合、デフォルトは pods になります。
- 4
- このルールが一致する場合、Pod は拒否されることを示します。
- 5
- イメージオブジェクトのメタデータで一致するアノテーションの一覧。
- 6
- イメージを解決できない場合に Pod を失敗させません。
- 7
- Kubernetes リソースでのイメージストリームの使用を許可するルールの配列。デフォルト設定は、pods、replicationcontrollers、replicasets、statefulsets、daemonsets、deployments および jobs がイメージフィールドで同じプロジェクトイメージストリームのタグ参照を使用することを許可します。
- 8
- このルールが適用されるグループおよびリソースを特定します。リソースが
*の場合、このルールはそのグループのすべてのリソースに適用されます。 - 9
LocalNamesは、単一のセグメント名 (例:ruby:2.4) が、リソースまたはターゲットイメージストリームでlocal name resolutionが有効にされている場合にのみ namespace のローカルイメージストリームとして解釈されるようにします。
デフォルトのレジストリープレフィックス (docker.io または registry.access.redhat.com など) を使用してプルされるインフラストラクチャーイメージを使用する場合、レジストリープレフィックスがないイメージは matchRegistries 値には一致しません。インフラストラクチャーイメージにイメージポリシーに一致するレジストリープレフィックスを持たせるには、master-config.yaml ファイルに imageConfig.format 値を設定します。
9.4. ImagePolicy 受付プラグインのテスト
openshift/image-policy-checkを使用して設定をテストします。たとえば、上記の情報を使用して、以下のようにテストします。
oc import-image openshift/image-policy-check:latest --confirm
この YAML を使用して Pod を作成します。Pod が作成されるはずです。
apiVersion: v1 kind: Pod metadata: generateName: test-pod spec: containers: - image: docker.io/openshift/image-policy-check:latest name: first別のレジストリーを参照する別の Pod を作成します。Pod は拒否されます。
apiVersion: v1 kind: Pod metadata: generateName: test-pod spec: containers: - image: different-registry/openshift/image-policy-check:latest name: firstインポートされたイメージを使用して内部レジストリーを参照する Pod を作成します。Pod は作成され、イメージ仕様を確認すると、タグの位置にダイジェストが表示されます。
apiVersion: v1 kind: Pod metadata: generateName: test-pod spec: containers: - image: <internal registry IP>:5000/<namespace>/image-policy-check:latest name: firstインポートされたイメージを使用して内部レジストリーを参照する Pod を作成します。Pod は作成され、イメージ仕様を確認すると、タグが変更されていないことを確認できます。
apiVersion: v1 kind: Pod metadata: generateName: test-pod spec: containers: - image: <internal registry IP>:5000/<namespace>/image-policy-check:v1 name: firstoc get istag/image-policy-check:latestからダイジェストを取得し、これをoc annotate images/<digest> images.openshift.io/deny-execution=trueに使用します。以下は例になります。$ oc annotate images/sha256:09ce3d8b5b63595ffca6636c7daefb1a615a7c0e3f8ea68e5db044a9340d6ba8 images.openshift.io/deny-execution=true
この Pod を再作成します。Pod は拒否されます。
apiVersion: v1 kind: Pod metadata: generateName: test-pod spec: containers: - image: <internal registry IP>:5000/<namespace>/image-policy-check:latest name: first

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.