Validazione in-cluster su Kubernetes senza complicazioni: ecco le Validating Admission Policies

Per utilizzare questa funzionalità servono due componenti principali:

1. ValidatingAdmissionPolicy: definisce la failure policy, le richieste corrispondenti e le espressioni di validazione CEL. In altre parole, la policy stessa.
2. ValidatingAdmissionPolicyBinding: definisce l'ambito della policy, associandola a un insieme di risorse corrispondenti.

Anche se questa funzionalità è in Alpha dalla v1.26, alcune caratteristiche sono disponibili solo a partire dalla v1.27 ( audit annotation, validation actions): tutti i manifest che seguono sono stati testati su un cluster Kubernetes in versione v1.27.1 (con le funzionalità alpha e il feature gate ValidatingAdmissionPolicy abilitati).

Tutti gli esempi presenti in questo articolo sono disponibili anche in un repository GitHub creato per l'occasione.

Il primo esempio è preso direttamente dalla documentazione. Creeremo e useremo il namespace demo per eseguire tutti gli esempi:

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

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

Successivamente, creeremo una policy che impedisce ai Deployment di avere più di cinque repliche:

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"

Il campo failurePolicy può assumere i seguenti valori:

• Fail: un errore nella chiamata della ValidatingAdmissionPolicy causa il fallimento dell'admission e il rifiuto della richiesta API.
• Ignore: un errore nella chiamata della ValidatingAdmissionPolicy viene ignorato e la richiesta API può proseguire.

Il campo matchConstraints serve a intercettare le richieste in arrivo ed è configurato in modo che la policy si applichi solo alle richieste API per i Deployment nell'API apps/v1 e solo alle operazioni di tipo CREATE o UPDATE su un Deployment.

Infine, il campo validations contiene le espressioni CEL effettive che verranno eseguite sulle richieste API corrispondenti. Tutte le espressioni devono essere valutate true affinché la richiesta venga ammessa.

Per completare la configurazione, creiamo il seguente 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

Stiamo associando la policy creata in precedenza a qualsiasi namespace con la label environment=demo: un'opzione utile per stabilire dove vogliamo applicare la validazione.

Esistono altre opzioni per il matching dei namespace, come matchExpressions per criteri più granulari, oltre ad altre opzioni di configurazione: excludeResourceRules per escludere determinate risorse, objectSelector per intercettare oggetti specifici (sconsigliato, perché gli sviluppatori potrebbero omettere una label per evitare l'audit). Tratterò le opzioni più interessanti negli esempi successivi.

Una volta applicati questi manifest al cluster, il tentativo di creare un nuovo Deployment che viola la policy genererà un errore, come previsto:

$ 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

Lo stesso vale quando si prova a fare il diff della risorsa:

$ 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

Espressioni di validazione multiple

A volte può essere necessario eseguire più validazioni sulle risorse; consideriamo le seguenti espressioni di validazione per i 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))"

Un Deployment intercettato da questa policy dovrà soddisfare tutte le espressioni (valutate a true) per essere ammesso nel cluster.

Da notare che le validazioni vengono eseguite in sequenza. Se un'espressione fallisce, l'errore viene restituito immediatamente al client: ciò significa che, se la risorsa viola più di un'espressione di validazione, sarà necessario un processo iterativo fatto di rifiuto, correzione della violazione e nuovo tentativo.

Personalizzare il messaggio di validazione

È anche possibile fornire un message personalizzato da restituire al client in caso di validazione fallita. Se serve, si può addirittura eseguire l'interpolazione tramite un messageExpression. Una message expression ha accesso a object, oldObject, request e params.

Aggiorniamo l'ultima policy con messaggi personalizzati al posto dei commenti:

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

Attenzione: qualsiasi valore interpolato nel campo messageExpression deve essere di tipo string, altrimenti il messaggio restituirà un errore di valutazione fallita.

Senza un messaggio personalizzato, un deployment con un volume emptyDir avrebbe fallito con il seguente errore:

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

Dal punto di vista del client, un messaggio del genere può risultare poco comprensibile. Con la message expression personalizzata, otterremmo invece:

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

Sto usando una messageExpression al posto di un normale message solo per mostrare la potenza del CEL. Il fatto che qualcosa si possa fare non significa che si debba sempre farlo!

• Validating Admission Policies in Kubernetes: Advanced Use Cases
• Repository GitHub validating-admission-policy-playground con esempi completi e funzionanti per le Validating Admission Policies
• Validating Admission Policy nella documentazione ufficiale di Kubernetes
• Common Expression Language in Kubernetes
• Kubernetes Enhancement Proposal (KEP)-3488 CEL for Admission Control
• Talk The Path to Self Contained CRDs di Cici Huang