Validation in-cluster simplifiée avec Kubernetes : les Validating Admission Policies

L'utilisation de cette fonctionnalité repose sur deux composants principaux :

1. ValidatingAdmissionPolicy — définit la failure policy, les correspondances de requêtes et les expressions de validation CEL. Autrement dit : la policy.
2. ValidatingAdmissionPolicyBinding — définit la portée de la policy ; il associe la policy à un ensemble de ressources correspondantes.

Bien que cette fonctionnalité soit en Alpha depuis la v1.26, certaines capacités ne sont disponibles qu'à partir de la v1.27 ( audit annotation, validation actions) ; tous les manifests qui suivent ont donc été testés sur un cluster Kubernetes en v1.27.1 (avec les fonctionnalités alpha et le feature gate ValidatingAdmissionPolicy activés).

Tous les exemples de cet article sont également disponibles dans un dépôt GitHub créé à cet effet.

Le premier exemple est tiré directement de la documentation. Nous allons créer et utiliser le namespace demo pour exécuter tous les exemples de cet article :

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

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

Créons ensuite une policy qui empêche les Deployments de dépasser cinq replicas :

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"

Le champ failurePolicy peut prendre les valeurs suivantes :

• Fail signifie qu'une erreur lors de l'appel à la ValidatingAdmissionPolicy entraîne l'échec de l'admission et le rejet de la requête API.
• Ignore signifie qu'une erreur lors de l'appel à la ValidatingAdmissionPolicy est ignorée et que la requête API peut se poursuivre.

Le champ matchConstraints sert à faire correspondre les requêtes entrantes ; il est configuré ici pour que la policy ne s'applique qu'aux requêtes API portant sur des Deployments dans l'API apps/v1, et uniquement aux requêtes CREATE ou UPDATE d'un Deployment.

Enfin, le champ validations contient les expressions CEL qui seront évaluées sur les requêtes API correspondantes. Toutes les expressions doivent renvoyer true pour que la requête soit admise.

Nous allons créer le binding suivant pour finaliser la configuration :

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

Nous associons la policy créée précédemment à tout namespace portant le label environment=demo — pratique pour configurer l'endroit où la validation doit s'appliquer.

D'autres options existent pour cibler des namespaces, comme matchExpressions pour un matching plus granulaire, ainsi que d'autres options de configuration : excludeResourceRules pour exclure certaines ressources, objectSelector pour cibler certains objets (déconseillé, puisque les développeurs peuvent omettre un label pour échapper à l'audit). Je couvrirai les options les plus intéressantes dans des exemples ultérieurs.

Une fois ces manifests appliqués au cluster, toute tentative de création d'un nouveau Deployment qui enfreint la policy renverra une erreur, comme prévu :

$ 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

C'est aussi le cas lorsqu'on tente un diff de la ressource :

$ 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

Plusieurs expressions de validation

Il arrive que vous souhaitiez effectuer plusieurs validations sur les ressources. Considérez les expressions de validation suivantes pour des 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:
    # Les Deployments ne peuvent pas avoir plus de 3 replicas
    - expression: "object.spec.replicas <= 3"
    # Les containers du Deployment doivent utiliser des images hébergées dans l'Artifact Registry europe-west1 du projet test-eyal
    - expression: "object.spec.template.spec.containers.all(c, c.image.startsWith('europe-west1-docker.pkg.dev/test-eyal/'))"
    # Le Deployment ne peut pas utiliser de volumes emptyDir
    - expression: "!has(object.spec.template.spec.volumes) || object.spec.template.spec.volumes.all(v, !has(v.emptyDir))"

Un Deployment ciblé par cette policy devra voir toutes les expressions évaluées à true pour être admis dans le cluster.

À noter : les validations sont exécutées séquentiellement. Si une expression échoue, l'échec est immédiatement renvoyé au client — autrement dit, si votre ressource enfreint plusieurs expressions de validation, vous devrez procéder par itérations : refus, correction, nouvelle tentative.

Personnaliser le message de validation

Il est également possible de fournir un message personnalisé renvoyé au client en cas d'échec de validation. Vous pouvez même faire de l'interpolation au besoin, à l'aide d'un messageExpression. Une expression de message a accès à object, oldObject, request et params.

Mettons à jour notre dernière policy avec des messages personnalisés plutôt que des commentaires :

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

À noter : toute valeur interpolée dans le champ messageExpression doit être de type string, faute de quoi le message renverra une erreur d'évaluation à la place.

Sans message personnalisé, un deployment avec un volume emptyDir aurait échoué de la manière suivante :

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

Difficile à interpréter du point de vue du client. Avec une expression de message personnalisée, on obtiendrait plutôt :

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

J'utilise ici un messageExpression plutôt qu'un simple message pour cette validation, afin d'illustrer la puissance du CEL. Ce n'est pas parce que vous pouvez faire quelque chose que vous devez le faire !

• Validating Admission Policies in Kubernetes: Advanced Use Cases
• validating-admission-policy-playground — dépôt GitHub réunissant des exemples complets et fonctionnels pour les Validating Admission Policies
• Validating Admission Policy dans la documentation officielle de Kubernetes
• Common Expression Language in Kubernetes
• Kubernetes Enhancement Proposal (KEP)-3488 — CEL pour l'Admission Control
• The Path to Self Contained CRDs, conférence de Cici Huang