Kubernetesのクラスター内検証を簡単に：Validating Admission Policies入門

この機能を使い始めるには、主に次の2つのコンポーネントが必要です。

1. ValidatingAdmissionPolicy — failurePolicy、リクエストのマッチ条件、CEL検証式を定義します。つまりポリシー本体です。
2. ValidatingAdmissionPolicyBinding — ポリシーの適用範囲を定義し、マッチしたリソース群にポリシーをバインドします。

本機能はv1.26からアルファ版として提供されていますが、一部の機能はv1.27以降でのみ利用可能です（audit annotation、validation actions）。そのため、以下のマニフェストはすべてv1.27.1で稼働するKubernetesクラスター（アルファ機能とValidatingAdmissionPolicyのfeature gateを有効化済み）でテストしています。

本記事のすべての例は、この目的のために用意したGitHubリポジトリでも参照できます。

最初の例は公式ドキュメントからそのまま引用したものです。本記事のすべての例で使うdemo namespaceを作成しておきましょう。

$ echo 'apiVersion: v1
kind: Namespace
metadata:
  labels:
    environment: demo
  name: demo' | k apply -f-
namespace/demo created

$ k config set-context --current --namespace demo

次に、Deploymentのレプリカ数を5以下に制限するポリシーを作成します。

apiVersion: admissionregistration.k8s.io/v1alpha1
kind: ValidatingAdmissionPolicy
metadata:
 name: "demo-policy.example.com"
spec:
 failurePolicy: Fail
 matchConstraints:
   resourceRules:
     - apiGroups:   ["apps"]
       apiVersions: ["v1"]
       operations:  ["CREATE", "UPDATE"]
       resources:   ["deployments"]
 validations:
   - expression: "object.spec.replicas <= 5"

failurePolicyフィールドには次の値を設定できます。

• Fail：ValidatingAdmissionPolicyの呼び出し時にエラーが発生した場合、admissionが失敗しAPIリクエストは拒否されます。
• Ignore：ValidatingAdmissionPolicyの呼び出し時にエラーが発生しても無視され、APIリクエストはそのまま処理されます。

matchConstraintsフィールドは受信リクエストのマッチに用いられ、上記の設定ではapps/v1 APIのDeploymentに対するCREATEまたはUPDATEリクエストにのみポリシーが適用されます。

最後に、validationsフィールドにはマッチしたAPIリクエストに対して実行されるCEL式を記述します。リクエストが受け入れられるためには、すべての式がtrueと評価される必要があります。

設定を完成させるため、次のbindingを作成します。

apiVersion: admissionregistration.k8s.io/v1alpha1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: "demo-binding-test.example.com"
spec:
  policyName: "demo-policy.example.com"
  validationActions: [Deny]
  matchResources:
    namespaceSelector:
      matchLabels:
        environment: demo

先ほど作成したポリシーを、ラベルenvironment=demoが付与された任意のnamespaceにバインドしています。これにより、ポリシー検証を適用する対象を柔軟に指定できます。

namespaceのマッチングには他にもさまざまなオプションがあります。よりきめ細かなマッチングを行うmatchExpressionsのほか、特定リソースを除外するexcludeResourceRules、特定オブジェクトをマッチさせるobjectSelector（開発者がラベルを省略するだけで監査を回避できてしまうため非推奨）といった設定も可能です。さらに踏み込んだオプションは、後続の例で取り上げます。

これらのマニフェストをクラスターに適用すると、ポリシーに違反する新規Deploymentの作成は想定どおりエラーになります。

$ k create deployment nginx — image=nginx — replicas=10
error: failed to create deployment: deployments.apps "nginx" is forbidden: ValidatingAdmissionPolicy 'demo-policy.example.com' with binding 'demo-binding-test.example.com' denied request: failed expression: object.spec.replicas <= 5

リソースのdiff取得時にも同様に動作します。

$ k create deployment nginx --image=nginx --replicas=10 --dry-run=client -oyaml | k diff -f -
The deployments "nginx" is invalid: : ValidatingAdmissionPolicy 'demo-policy.example.com' with binding 'demo-binding-test.example.com' denied request: failed expression: object.spec.replicas <= 5

複数の検証式を扱う

リソースに対して複数の検証を行いたい場面もあるでしょう。Deploymentsに対する次のような検証式を考えてみます。

apiVersion: admissionregistration.k8s.io/v1alpha1
kind: ValidatingAdmissionPolicy
metadata:
  name: "demo-policy.example.com"
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
      - apiGroups:   ["apps"]
        apiVersions: ["v1"]
        operations:  ["CREATE", "UPDATE"]
        resources:   ["deployments"]
  validations:
    # Deployments can't have more than 3 replicas
    - expression: "object.spec.replicas <= 3"
    # Deployment containers must be using images hosted in europe-west1 Artifact Registry in project test-eyal
    - expression: "object.spec.template.spec.containers.all(c, c.image.startsWith('europe-west1-docker.pkg.dev/test-eyal/'))"
    # Deployment cannot use emptyDir volumes
    - expression: "!has(object.spec.template.spec.volumes) || object.spec.template.spec.volumes.all(v, !has(v.emptyDir))"

このポリシーにマッチするDeploymentがクラスターに受け入れられるためには、すべての式がtrueと評価される必要があります。

注意したいのは、検証は順次実行される点です。いずれかの式が失敗した時点で、その失敗がただちにクライアントへ返されます。つまり、リソースが複数の検証式に違反している場合は、拒否される→違反を修正する→再度試す、という反復プロセスになります。

検証メッセージをカスタマイズする

検証失敗時にクライアントへ返すメッセージは、任意の内容にカスタマイズできます。必要に応じてmessageExpressionを使えば、文字列補間も可能です。message expressionからはobject、oldObject、request、paramsにアクセスできます。

先ほどのポリシーを、コメントの代わりにカスタムメッセージを使う形に書き換えてみましょう。

apiVersion: admissionregistration.k8s.io/v1alpha1
kind: ValidatingAdmissionPolicy
metadata:
  name: "demo-policy.example.com"
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
      - apiGroups:   ["apps"]
        apiVersions: ["v1"]
        operations:  ["CREATE", "UPDATE"]
        resources:   ["deployments"]
  validations:
    - expression: "object.spec.replicas <= 3"
      messageExpression: "'Deployments cannot have more than 3 replicas, this one has ' + string(object.spec.replicas)"
    - expression: "object.spec.template.spec.containers.all(c, c.image.startsWith('europe-west1-docker.pkg.dev/test-eyal/'))"
      message: "Deployment containers must be using images hosted in europe-west1 Artifact Registry in project test-eyal"
    - expression: "!has(object.spec.template.spec.volumes) || object.spec.template.spec.volumes.all(v, !has(v.emptyDir))"
      messageExpression: "'Deployment cannot use emptyDir volumes, change the following volume: ' + object.spec.template.spec.volumes.filter(v, has(v.emptyDir)).map(v, v.name)[0]"

注意点として、messageExpressionフィールド内で補間する値はすべてstring型である必要があります。そうでない場合、メッセージの代わりに評価失敗のエラーが返されてしまいます。

カスタムメッセージを設定しない場合、emptyDirボリュームを持つDeploymentは次のように失敗します。

The deployments "nginx" is invalid: : ValidatingAdmissionPolicy ‘demo-policy.example.com’ with binding ‘demo-binding-test.example.com’ denied request: failed expression: !has(object.spec.template.spec.volumes) || object.spec.template.spec.volumes.all(v, !has(v.emptyDir))

これではクライアント側から見て内容を理解しづらいかもしれません。カスタムのmessage expressionを使えば、出力は次のようになります。

The deployments "nginx" is invalid: : ValidatingAdmissionPolicy ‘demo-policy.example.com’ with binding ‘demo-binding-test.example.com’ denied request: Deployment cannot use emptyDir volumes, change the following volumes: test

なお、ここではCELの表現力を示すために通常のmessageではなくmessageExpressionを使っています。できるからといって、必ずしもそうすべきとは限らない点にご注意ください。

• Validating Admission Policies in Kubernetes: Advanced Use Cases
• validating-admission-policy-playground — Validating Admission Policiesの完全な動作例を収録したGitHubリポジトリ
• Kubernetes公式ドキュメントのValidating Admission Policy
• Common Expression Language in Kubernetes
• Kubernetes Enhancement Proposal (KEP)-3488 — CEL for Admission Control
• Cici Huang氏の講演The Path to Self Contained CRDs