Validación sencilla dentro del cluster: te presentamos las Validating Admission Policies de Kubernetes

Para usar esta función necesitas dos componentes principales:

1. ValidatingAdmissionPolicy: define la política de fallo, las coincidencias de solicitudes y las expresiones de validación CEL. Es decir, la política en sí.
2. ValidatingAdmissionPolicyBinding: define el alcance de la política; la vincula a un conjunto de recursos coincidentes.

Aunque esta función está en Alpha desde la v1.26, algunas características solo aparecen a partir de la v1.27 ( audit annotation, validation actions), así que todos los manifiestos siguientes se probaron en un cluster de Kubernetes con la v1.27.1 (con las funciones alpha y el feature gate ValidatingAdmissionPolicy habilitados).

Todos los ejemplos de este artículo también están disponibles en un repositorio de GitHub creado para este propósito.

El primer ejemplo viene directo de la documentación. Crearemos y usaremos el namespace demo para correr todos los ejemplos:

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

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

A continuación, crearemos una política que impide que los Deployments tengan más de cinco réplicas:

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"

El campo failurePolicy puede tomar los siguientes valores:

• Fail: indica que un error al invocar la ValidatingAdmissionPolicy hace que la admisión falle y la solicitud a la API se rechace.
• Ignore: indica que un error al invocar la ValidatingAdmissionPolicy se ignora y se permite que la solicitud continúe.

El campo matchConstraints sirve para hacer coincidir las solicitudes entrantes y está configurado para que la política solo se aplique a solicitudes para Deployments en la API apps/v1, y únicamente a operaciones CREATE o UPDATE de un Deployment.

Por último, el campo validations contiene las expresiones CEL que se ejecutarán contra las solicitudes coincidentes. Todas las expresiones deben evaluarse como true para que la solicitud sea admitida.

Crearemos el siguiente binding para completar la configuración:

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

Estamos vinculando la política creada antes a cualquier namespace que tenga el label environment=demo; esto resulta útil para definir dónde queremos aplicar la validación.

Hay más opciones para hacer match de namespaces, como matchExpressions para coincidencias más granulares, y otras opciones de configuración: excludeResourceRules para excluir ciertos recursos u objectSelector para hacer match con ciertos objetos (no se recomienda, ya que los desarrolladores podrían omitir un label para evitar la auditoría). Cubriré las opciones más interesantes en ejemplos posteriores.

Una vez aplicados estos manifiestos al cluster, intentar crear un nuevo Deployment que viole la política arrojará un error, como era de esperarse:

$ 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

También funciona al intentar hacer diff del recurso:

$ 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

Múltiples expresiones de validación

A veces vas a querer aplicar varias validaciones a los recursos. Considera las siguientes expresiones de validación para 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:
    # Los Deployments no pueden tener más de 3 réplicas
    - expression: "object.spec.replicas <= 3"
    # Los contenedores del Deployment deben usar imágenes alojadas en el Artifact Registry de europe-west1 en el proyecto test-eyal
    - expression: "object.spec.template.spec.containers.all(c, c.image.startsWith('europe-west1-docker.pkg.dev/test-eyal/'))"
    # El Deployment no puede usar volúmenes emptyDir
    - expression: "!has(object.spec.template.spec.volumes) || object.spec.template.spec.volumes.all(v, !has(v.emptyDir))"

Un Deployment que coincida con esta política deberá tener todas las expresiones evaluadas como true para ser admitido en el cluster.

Algo que conviene tener en cuenta es que las validaciones se ejecutan secuencialmente. Si una expresión falla, devolverá ese fallo al cliente de inmediato; esto significa que, si tu recurso viola más de una expresión de validación, será un proceso iterativo: ser rechazado, corregir la violación y volver a intentar.

Personaliza el mensaje de validación

También se puede entregar un message personalizado que se devuelve al cliente cuando una validación falla. Incluso puedes hacer interpolación si lo necesitas usando un messageExpression. Una expresión de mensaje tiene acceso a object, oldObject, request y params.

Actualicemos nuestra última política con mensajes personalizados en lugar de comentarios:

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

Es importante tener presente que cualquier valor interpolado en el campo messageExpression debe ser de tipo string; de lo contrario, el mensaje devolverá un error por la evaluación fallida.

Sin un mensaje personalizado, un deployment con un volumen emptyDir habría fallado con lo siguiente:

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

Esto puede resultar difícil de entender desde la perspectiva del cliente. Con la expresión de mensaje personalizada obtendríamos lo siguiente:

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

Ten en cuenta que estoy usando un messageExpression en lugar de un message normal en esta validación para mostrar el poder de CEL. ¡Que puedas hacer algo no siempre significa que debas hacerlo!

• Validating Admission Policies en Kubernetes: casos de uso avanzados
• validating-admission-policy-playground: repositorio de GitHub con ejemplos completos y funcionales de Validating Admission Policies
• Validating Admission Policy en la documentación oficial de Kubernetes
• Common Expression Language en Kubernetes
• Kubernetes Enhancement Proposal (KEP)-3488: CEL para Admission Control
• The Path to Self Contained CRDs, charla de Cici Huang