Mühelose In-Cluster-Validierung mit Kubernetes: Validating Admission Policies im Überblick

Für die Nutzung dieses Features braucht es zwei zentrale Komponenten:

1. ValidatingAdmissionPolicy – legt Failure Policy, Request-Matches und CEL-Validierungsausdrücke fest. Also: die eigentliche Policy.
2. ValidatingAdmissionPolicyBinding – definiert den Geltungsbereich der Policy und bindet sie an einen Satz passender Ressourcen.

Auch wenn dieses Feature seit v1.26 in Alpha verfügbar ist, sind einige Funktionen erst ab v1.27 vorhanden (Audit Annotations, Validation Actions). Alle folgenden Manifeste wurden daher auf einem Kubernetes-Cluster mit v1.27.1 getestet (mit aktivierten Alpha-Features und aktiviertem ValidatingAdmissionPolicy Feature Gate).

Sämtliche Beispiele aus diesem Beitrag finden Sie auch in einem dafür angelegten GitHub-Repository.

Das erste Beispiel stammt direkt aus der Dokumentation. Wir erstellen und nutzen den Namespace demo für alle Beispiele in diesem Beitrag:

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

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

Als Nächstes legen wir eine Policy an, die verhindert, dass Deployments mehr als fünf Replicas haben:

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"

Das Feld failurePolicy kann auf folgende Werte gesetzt werden:

• Fail bedeutet, dass ein Fehler beim Aufruf der ValidatingAdmissionPolicy dazu führt, dass die Admission fehlschlägt und die API-Anfrage abgelehnt wird.
• Ignore bedeutet, dass ein Fehler beim Aufruf der ValidatingAdmissionPolicy ignoriert wird und die API-Anfrage weiterläuft.

Über das Feld matchConstraints werden eingehende Anfragen abgeglichen. Es ist hier so konfiguriert, dass die Policy nur auf API-Anfragen für Deployments in der API apps/v1 greift – und nur auf CREATE- oder UPDATE-Anfragen.

Im Feld validations stehen schließlich die eigentlichen CEL-Ausdrücke, die gegen die passenden API-Anfragen ausgeführt werden. Damit eine Anfrage zugelassen wird, müssen alle Ausdrücke zu true ausgewertet werden.

Mit folgendem Binding vervollständigen wir die Konfiguration:

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

Wir binden die zuvor erstellte Policy an jeden Namespace, der das Label environment=demo trägt – damit lässt sich gezielt steuern, wo die Policy-Validierung greifen soll.

Es gibt weitere Optionen für das Matching von Namespaces, etwa matchExpressions für feinere Abgleiche, sowie zusätzliche Konfigurationsmöglichkeiten: excludeResourceRules, um bestimmte Ressourcen auszuschließen, oder objectSelector, um bestimmte Objekte abzugleichen (davon ist eher abzuraten, da Engineers ein Label einfach weglassen können, um dem Auditing zu entgehen). Die spannenderen Optionen behandle ich in späteren Beispielen.

Sobald diese Manifeste auf den Cluster angewendet sind, schlägt der Versuch, ein neues Deployment anzulegen, das gegen die Policy verstößt, erwartungsgemäß fehl:

$ 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

Auch beim Diff der Ressource greift dies:

$ 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

Mehrere Validierungsausdrücke

Manchmal sollen mehrere Validierungen gleichzeitig auf eine Ressource angewendet werden. Sehen Sie sich dazu folgende Validierungsausdrücke für Deployments an:

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 dürfen nicht mehr als 3 Replicas haben
    - expression: "object.spec.replicas <= 3"
    # Deployment-Container müssen Images aus der Artifact Registry in europe-west1 im Projekt test-eyal verwenden
    - expression: "object.spec.template.spec.containers.all(c, c.image.startsWith('europe-west1-docker.pkg.dev/test-eyal/'))"
    # Deployment darf keine emptyDir-Volumes verwenden
    - expression: "!has(object.spec.template.spec.volumes) || object.spec.template.spec.volumes.all(v, !has(v.emptyDir))"

Damit ein Deployment, auf das diese Policy zutrifft, im Cluster zugelassen wird, müssen alle Ausdrücke zu true ausgewertet werden.

Wichtig zu wissen: Die Validierungen werden sequenziell ausgeführt. Schlägt ein Ausdruck fehl, wird dieser Fehler sofort an den Client zurückgegeben – verstößt Ihre Ressource gegen mehr als einen der Validierungsausdrücke, läuft das also auf einen iterativen Prozess hinaus: Ablehnung, Korrektur, neuer Versuch.

Validierungsmeldung anpassen

Es ist zudem möglich, im Fehlerfall eine eigene message an den Client zurückzugeben. Bei Bedarf lässt sich über messageExpression sogar interpolieren. Eine Message-Expression hat Zugriff auf object, oldObject, request und params.

Aktualisieren wir unsere letzte Policy und ersetzen die Kommentare durch eigene Meldungen:

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]"

Wichtig: Alle interpolierten Werte im Feld messageExpression müssen vom Typ string sein – andernfalls liefert die Meldung einen Fehler für die fehlgeschlagene Auswertung zurück.

Ohne eigene Meldung würde ein Deployment mit einem emptyDir-Volume etwa so fehlschlagen:

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))

Aus Client-Sicht ist das nicht unbedingt leicht zu deuten. Mit der eigenen Message-Expression sieht das Ganze so aus:

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

Ich verwende hier bewusst messageExpression statt einer einfachen message, um die Möglichkeiten von CEL zu zeigen. Nur weil man etwas kann, heißt das aber nicht, dass man es immer tun sollte!

• Validating Admission Policies in Kubernetes: Advanced Use Cases
• validating-admission-policy-playground – GitHub-Repository mit vollständigen, lauffähigen Beispielen für Validating Admission Policies
• Validating Admission Policy in der offiziellen Kubernetes-Dokumentation
• Common Expression Language in Kubernetes
• Kubernetes Enhancement Proposal (KEP)-3488 – CEL für Admission Control
• The Path to Self Contained CRDs – Vortrag von Cici Huang