Resumen

  • Una ValidatingAdmissionPolicyBinding conecta política, alcance, parámetros opcionales y acciones declaradas; no es el comprobante de una decisión sobre una solicitud.
  • Kubernetes separa la coincidencia de recursos, la resolución de parámetros, la evaluación de expresiones, el manejo de fallos y la respuesta del servidor.
  • La evidencia útil mantiene un registro de configuración junto a otro, distinto, para el resultado de cada solicitud relevante.

Una política enlazada puede parecer una respuesta terminada. El lector observa un nombre de política, reglas de alcance y acciones como Deny, Warn o Audit; de ahí resulta fácil concluir que el control ya se aplicó. Sin embargo, la vinculación describe una disposición para la admisión futura. No nombra una solicitud, no conserva la identidad que la presentó y no prueba que la API haya rechazado, advertido, auditado o persistido un objeto.

La referencia de Kubernetes es clara sobre el primer salto. Una ValidatingAdmissionPolicyBinding vincula una política con recursos parametrizados. Sus matchResources se intersectan con los matchConstraints de la política. Para que la vinculación pueda seleccionar una solicitud, esta debe corresponder antes con la política. Esa relación explica una posible ruta de evaluación, no documenta que una carga, un objeto o una persona determinada recorrieran la ruta. Puede no haber existido una solicitud pertinente; la solicitud puede haber quedado fuera del cruce; otro controlador puede haber fijado el desenlace.

Tampoco los parámetros deben convertirse en una conclusión automática. Una vinculación puede referirse a un recurso de parámetros, y la documentación diferencia el recurso disponible del que falta. Si falta la referencia, la vinculación puede quedar mal configurada y entra en juego la política de fallos. La existencia de ese campo o de esa política no dice, por sí sola, que una solicitud se permitió o se denegó. Política, vinculación, parámetro y modo de fallo son hechos de configuración diferentes que conviene conservar con sus propias fechas y versiones.

La distinción entre error y validación falsa evita otro atajo. Kubernetes reserva failurePolicy para errores de análisis, tipado, ejecución o configuración. El tratamiento de una validación que resulta falsa procede de las validationActions definidas en la vinculación. Deny implica que el fallo de validación da lugar a una solicitud denegada; Warn comunica una advertencia al cliente; Audit incorpora información al evento de auditoría. No son tres sinónimos de “protegido”. Son acciones diferentes que sólo adquieren significado operativo cuando se relacionan con una solicitud y una evaluación concretas.

La ubicación de la admisión también limita lo que se puede inferir. Kubernetes indica que los controladores de admisión intervienen después de autenticación y autorización, antes de persistir el recurso. Hay fases mutantes y validantes, y un rechazo en cualquiera de ellas rechaza la solicitud. La vinculación no revela si la autorización anterior fue concedida, si una mutación modificó el objeto, si otra validación rechazó la operación o si el objeto terminó almacenado. Las lecturas eluden la capa de admisión por completo. Un inventario de vinculaciones, por tanto, no equivale a un historial de acceso ni de cambios.

La anotación de auditoría muestra qué forma toma una evidencia más estrecha. Para un fallo de validación, Kubernetes documenta una anotación asociada a la solicitud que identifica política, vinculación, índice de expresión y acciones. Es una base para afirmar algo sobre aquella solicitud. No autoriza a extrapolar al resto de solicitudes, a otro periodo o a una carga distinta. Su fuerza proviene precisamente de su límite.

Una práctica útil separa dos recibos. El de configuración contiene identidad y versión de política y vinculación, alcance, referencia de parámetros, acciones declaradas y momento de observación. El de resultado contiene identidad y tiempo de solicitud, condiciones que coincidieron o excluyeron, estado del parámetro, evaluación, acción, respuesta y evidencia de persistencia o rechazo. Este diseño no impone un formato de Kubernetes. Impide, en cambio, que la palabra “enforcement” esconda pasos que nadie ha demostrado.

Fuentes

  1. Referencia API Kubernetes — ValidatingAdmissionPolicyBinding
  2. Referencia API Kubernetes — ValidatingAdmissionPolicy
  3. Tutorial Kubernetes — Políticas de admisión
  4. Documentación Kubernetes — Controladores de admisión
  5. Documentación Kubernetes — Anotaciones de auditoría