この文書は自動機械翻訳技術を使用して翻訳されています。 正確な翻訳を提供するように努めておりますが、翻訳された内容の完全性、正確性、信頼性については一切保証いたしません。 相違がある場合は、元の英語版 英語 が優先され、正式なテキストとなります。

これは未公開の文書です Admission Controller 1.34-dev.

ポリシーグループ

ポリシーグループ機能は、ユーザーがより単純なポリシーを組み合わせることで複雑なポリシーを作成できるようにします。新しいカスタムリソース定義(CRD)が2つ導入されます:

  • AdmissionPolicyGroup:特定のネームスペースに適用されるアドミッションポリシーのためのものです。

  • ClusterAdmissionPolicyGroup:クラスター全体に適用されるアドミッションポリシーのためのものです。

これらのポリシーグループにより、ユーザーは既存のポリシーを利用でき、カスタムポリシーの作成の必要性が減少し、再利用が促進されます。ポリシーロジックの重複を避けることで、ユーザーは管理を簡素化し、DSLのような構成でカスタムポリシーを作成できます。

ポリシーグループは、論理演算子を使用して複数のポリシーを組み合わせて評価することを可能にします。これにより、複雑なロジックの定義が可能になります。ただし、通常のポリシーは認可時にリソースを変更するための変更ロジックを含むことができますが、ポリシーグループは検証のみを行います。

ポリシーグループの設定は、通常のポリシーの設定に似ています。違いは、expressionmessage、および`policies`フィールドの追加と、コンテキストに応じたルールの宣言が異なる場所にあることです。

これは、次のセクションで異なるフィールドを説明するために使用できる`ClusterAdmissionPolicyGroup`の例です:

`ClusterAdmissionPolicyGroup`は、`latest`タグを持つイメージを使用するPodを拒否します。ただし、イメージは2つの信頼できる当事者によって署名されている必要があります:アリスとボブ。
apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicyGroup # or AdmissionPolicyGroup
metadata:
  name: demo
spec:
  rules:
    - apiGroups: [""]
      apiVersions: ["v1"]
      resources: ["pods"]
      operations:
        - CREATE
        - UPDATE
  policies:
    signed_by_alice:
      module: ghcr.io/kubewarden/policies/verify-image-signatures:v0.3.0
      settings:
        modifyImagesWithDigest: false
        signatures:
          - image: "*"
            pubKeys:
              - |
                -----BEGIN PUBLIC KEY-----
                MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEyg65hiNHt8FXTamzCn34IE3qMGcV
                yQz3gPlhoKq3yqa1GIofcgLjUZtcKlUSVAU2/S5gXqyDnsW6466Jx/ZVlg==
                -----END PUBLIC KEY-----
    signed_by_bob:
      module: ghcr.io/kubewarden/policies/verify-image-signatures:v0.3.0
      settings:
        modifyImagesWithDigest: false
        signatures:
          - image: "*"
            pubKeys:
              - |
                -----BEGIN PUBLIC KEY-----
                MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEswA3Ec4w1ErOpeLPfCdkrh8jvk3X
                urm8ZrXi4S3an70k8bf1OlGnI/aHCcGleewHbBk1iByySMwr8BabchXGSg==
                -----END PUBLIC KEY-----
    reject_latest:
      module: registry://ghcr.io/kubewarden/policies/trusted-repos:v0.2.0
      settings:
        tags:
          reject:
            - latest
  expression: "reject_latest() || (signed_by_alice() && signed_by_bob())"
  message: "the image is using the latest tag or is not signed by Alice and Bob"

メイン設定フィールド

このセクションでは、ポリシーグループの主要な設定項目を扱います。

`policies`属性

ポリシーフィールドは、通常のポリシーのマップです。SUSE Security Admission Controllerはポリシーグループによってポリシーを呼び出し、評価中のリソースを受け入れるか拒否するかを判断します。これらのポリシーの定義は、通常のAdmission Controllerポリシーの簡略版であり、modulesettings、および`contextAwareResources`属性のみを含みます。これらの要素は、ポリシーグループ内でポリシーが機能するために必要です。

ユニークな名前は、グループポリシーの各ポリシーを識別します。例えば、次のスニペットは三つのポリシーを定義しています:signed_by_alicesigned_by_bob`および`reject_latest_tag

policies:
  signed_by_alice:
    module: ghcr.io/kubewarden/policies/verify-image-signatures:v0.2.8
    settings: {} # settings for the policy
  signed_by_bob:
    module: ghcr.io/kubewarden/policies/verify-image-signatures:v0.2.8
    settings: {} # settings for the policy
  reject_latest_tag:
    module: ghcr.io/kubewarden/policies/trusted-repos-policy:v0.2.0
    settings: {} # settings for the policy

ポリシーグループには、異なる設定で同じポリシーを複数回含めることができます。

`expression`属性

`expression`属性には、論理演算子で結合されたポリシー識別子から成る文が含まれています。

`expression`文の評価は、ブール値に評価されなければなりません。

ポリシーの表現は、`.spec.policies`マップで指定された識別子にちなんで名付けられた関数として行われます。ポリシーの評価によって生成された結果は、ユーザーが提供した論理演算子を使用して再評価されます。

これらはサポートされている演算子です:

  • &&:`AND`操作を実行するために使用されます。

  • ||:`OR`操作を実行するために使用されます。

  • !:`NOT`操作を実行するために使用されます。

評価の優先順位を定義するために、丸括弧`( )`を使用できます。

例えば、次の式が与えられた場合:

reject_latest() || (signed_by_alice() && signed_by_bob())

ポリシーは、`latest`タグを使用しているイメージを持つワークロードを拒否します。ただし、アリスとボブの両方がイメージに署名している場合を除きます。

`message`属性と応答形式

`message`フィールドは、`expression`の評価が拒否に至った場合に返されるメッセージを指定します。応答には、メッセージと個々のポリシー評価の結果が含まれます。

グループに属するポリシーの評価は、必要な場合にのみ行われます。

例えば、次の式が与えられた場合:

reject_latest() || (signed_by_alice() && signed_by_bob())

`reject_latest`ポリシーが`true`を返すとき、`signed_by_bob`および`signed_by_alice`ポリシーは評価されません。

同様に、`signed_by_alice`および`reject_latest`ポリシーが`false`を返す場合、`signed_by_bob`ポリシーは評価されません。

これにより、グループ内のポリシーの不必要な評価を回避し、認可リクエストに迅速に応答することができます。

システムは、グループポリシーが拒否を行う際に、AdmissionResponse .status.details.causes の一部としてすべての評価詳細を送信します。

拒否された認可リクエストの詳細を取得するには、kubectl の冗長性レベルを上げる必要があります。

kubectl -v4 apply -f signed-pod.yml
I0919 18:29:40.251332    4330 helpers.go:246] server response object: [{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {},
  "status": "Failure",
  "message": "error when creating \"signed-pod.yml\": admission webhook \"clusterwide-demo.kubewarden.admission\" denied the request: the image is using the latest tag or is not signed by Alice and Bob",
  "details": {
    "causes": [
      {
        "message": "Resource signed is not accepted: verification of image testing.registry.svc.lan/busybox:latest failed: Host error: Callback evaluation failure: Image verification failed: missing signatures\nThe following constraints were not satisfied:\nkind: pubKey\nowner: null\nkey: |\n  -----BEGIN PUBLIC KEY-----\n  MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEswA3Ec4w1ErOpeLPfCdkrh8jvk3X\n  urm8ZrXi4S3an70k8bf1OlGnI/aHCcGleewHbBk1iByySMwr8BabchXGSg==\n  -----END PUBLIC KEY-----\nannotations: null\n",
        "field": "spec.policies.signed_by_bob"
      },
      {
        "message": "not allowed, reported errors: tags not allowed: latest",
        "field": "spec.policies.reject_latest"
      }
    ]
  },
  "code": 400
}]
Error from server: error when creating "signed-pod.yml": admission webhook "clusterwide-demo.kubewarden.admission" denied the request: the image is using the latest tag or is not signed by Alice and Bob

完全な認可応答は、デバッグモードで実行しているポリシーサーバーのログに記録されています。さらに、評価詳細は常にポリシーサーバーによって発信されるOpenTelemetryトレースの一部です。

コンテキスト対応ポリシー

ポリシーグループと通常のポリシーのもう一つの違いは、コンテキスト対応リソースルールの定義場所です。グループ内の各ポリシーは、評価中にポリシーがアクセスできるリソースを指定するためのオプションの contextAwareResources フィールドを受け入れます。通常のポリシーと同様に、ClusterAdmissionPolicyGroup を定義することでのみコンテキスト対応機能を使用できます。これはセキュリティ上の理由からであり、特権のないユーザーのみが AdmissionPolicyGroup リソースをデプロイできます。詳細については、コンテキスト対応ポリシー のドキュメントを参照してください。

コンテキスト対応ポリシーを利用するポリシーグループの例です。
apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicyGroup # or AdmissionPolicyGroup
metadata:
  name: demo-ctx-aware
spec:
  rules:
    - apiGroups:
        - ""
      apiVersions:
        - v1
      resources:
        - services
      operations:
        - CREATE
        - UPDATE
  policies:
    unique_service_selector:
      module: registry://ghcr.io/kubewarden/policies/unique-service-selector-policy:v0.1.0
      contextAwareResources:
        - apiVersion: v1
          kind: Service
      settings:
        app.kubernetes.io/name: MyApp
    owned_by_foo_team:
      module: registry://ghcr.io/kubewarden/policies/safe-annotations:v0.2.9
      settings:
        mandatory_annotations:
          - owner
        constrained_annotations:
          owner: "foo-team"
  expression: "unique_service_selector() || (!unique_service_selector() && owned_by_foo_team())"
  message: "the service selector is not unique or the service is not owned by the foo team"

前の例では、unique_service_selector ポリシーが Service リソースにアクセスできます。しかし、owned_by_foo_team はKubernetesリソースにアクセスできません。

設定の検証

ポリシーサーバーが起動すると、ポリシーグループと通常のポリシーの設定が検証されます。ただし、ポリシーグループは、式が有効でありブール値に評価されることを確認するための追加の検証ステップを受けます。

監査スキャナー

AdmissionPolicyおよびClusterAdmissionPolicy CRDと同様に、backgroundAudit フィールドは、監査チェック 中にポリシーグループを含めるかどうかを示します。

ポリシーサーバー

policies.yml 設定ファイルを拡張して、通常のポリシーと並んでポリシーグループを含めることができます。通常のポリシーと同様に、モジュールのダウンロードは一度だけ行われます。ポリシーグループと通常のポリシーの両方で同じポリシーモジュールを使用します。