Problema y contexto
Kubernetes ValidatingAdmissionPolicy evalúa expresiones CEL contra las solicitudes a la API. La definición de una política se vincula con un binding que selecciona recursos y define la acción de cumplimiento. Esto proporciona una vía de validación nativa del clúster, pero una política con un alcance deficiente o no disponible puede rechazar operaciones legítimas de recuperación.
Supongamos que los namespaces de producción están etiquetados, la procedencia de la imagen está disponible como un campo de admisión y los ingenieros de plataforma son los propietarios de la política. El diseño debe distinguir las reglas estrictas de seguridad de las advertencias, admitir ejecuciones de prueba (dry runs) y preservar una vía de emergencia auditada.
Qué evalúan los entrevistadores
Los entrevistadores buscan la separación entre la definición de la política y el binding, un comportamiento de fallo explícito, una coincidencia precisa de recursos y un modelo de exenciones comprobable. Las respuestas sólidas analizan la verificación de tipos de CEL, el despliegue versionado, las métricas de auditoría y lo que ocurre cuando el motor de políticas o los datos referenciados no están disponibles.
Una respuesta ordinaria escribe una sola expresión que rechaza YAML incorrecto. Una respuesta sólida explica el alcance, los niveles de acción, la compatibilidad, la observabilidad y el rollback.
Preguntas para aclarar primero
- ¿Qué grupos de API, versiones, namespaces y operaciones están dentro del alcance?
- ¿La regla trata sobre la identidad de la imagen, la fijación de digest, el acceso al host o todo lo anterior?
- ¿Una infracción debe denegar, advertir o solo auditar durante la fase piloto?
- ¿Qué controladores o namespaces del sistema necesitan exenciones y quién las aprueba?
- ¿Cuál es la vía de recuperación si una política bloquea la solución de un incidente?
Si la regla depende de un estado externo al que CEL no puede acceder de manera confiable, mantén la política local y utiliza un controlador independiente para comprobaciones más complejas. Si las exenciones son amplias, la política puede generar una falsa sensación de confianza.
Una respuesta en 30 segundos
“Definiría reglas CEL pequeñas y tipadas, y las vincularía únicamente a las cargas de trabajo de producción y a las operaciones relevantes. Comenzaría en modo de auditoría o advertencia, mediría las infracciones por propietario y luego aplicaría una regla a la vez. Las exenciones serían limitadas y auditadas, con una vía de emergencia probada. Monitorearía la latencia de admisión, la tasa de rechazo y el éxito de la recuperación, y revertiría el binding si el comportamiento de la política resulta inseguro.”
Diseño paso a paso
- Definir la invariante. Escribe reglas separadas para el registro de imágenes aprobado, los requisitos de digest y los privilegios de host. Evita una sola expresión que sea difícil de probar o explicar.
- Verificar tipos y probar CEL. Valida las expresiones con respecto a los esquemas de los recursos de destino, incluidos los campos faltantes, listas, actualizaciones y operaciones de eliminación. Mantén fixtures en el flujo de trabajo de revisión de políticas.
- Definir el alcance con un binding. Coincide únicamente con los namespaces de producción, los tipos de cargas de trabajo y las operaciones que requieren protección. Los bindings independientes permiten que los equipos adopten reglas de forma autónoma.
- Elegir el modo de cumplimiento. Comienza con auditoría o advertencia, promueve a denegación después de que los propietarios corrijan las infracciones y registra la acción en el historial de cambios.
- Diseñar las exenciones. Exenta solo identidades o namespaces del sistema designados, exige un registro de aprobación o fecha de vencimiento y genera alertas cuando se utilicen las exenciones.
- Revertir de forma segura. Mantén las definiciones de políticas versionadas, deshabilita el binding en lugar de borrar el historial y verifica que los Deployments de emergencia puedan continuar según la vía documentada.
Las alternativas incluyen un webhook de validación para datos externos o mutación más validación para la normalización. Utiliza la política integrada para invariantes locales y deterministas que deban aplicarse cerca del servidor de la API.
Ejemplo de respuesta
“Crearía tres políticas: lista de permitidos de registros, digest obligatorio y hostNetwork prohibido para los Deployments de producción. Cada binding seleccionaría únicamente los namespaces de producción etiquetados. El piloto se ejecuta en modo de auditoría durante una semana; los propietarios reciben informes de infracciones y corregimos los falsos positivos antes de habilitar la denegación. Las identidades de plataforma y de acceso de emergencia (break-glass) son las únicas excepciones, con vencimiento y eventos de auditoría. Alertamos sobre la latencia de admisión y los cambios de recuperación rechazados, y revertimos deshabilitando el binding si un incidente revela una regla no segura.”
Errores comunes
- Error: Hacer coincidir todos los namespaces y operaciones → Por qué falla: los controladores del sistema y las vías de recuperación se bloquean → Solución: delimita el alcance de los bindings de forma precisa.
- Error: Tratar las advertencias como cumplimiento → Por qué falla: los usuarios asumen que la seguridad está garantizada → Solución: comunica el nivel de acción y los criterios de promoción.
- Error: Usar CEL sin tipos en campos faltantes → Por qué falla: las actualizaciones y las versiones anteriores de la API se comportan de manera diferente → Solución: verifica los tipos y prueba los casos de campos ausentes.
- Error: Hacer que las exenciones sean permanentes → Por qué falla: las excepciones se convierten en la política real → Solución: exige vencimiento, propietario y auditoría.
Preguntas de seguimiento y respuestas
¿Qué pasa si una expresión de política tiene un error de sintaxis?
Kubernetes valida la definición de la política y reporta el error en lugar de aceptar una expresión no válida. Aun así, ejecútala a través de fixtures de revisión y mantén el binding en modo de auditoría hasta confirmar su comportamiento.
¿Cómo manejas una regla que necesita una base de datos de vulnerabilidades externa?
No asumas que CEL puede obtener un estado externo arbitrario. Utiliza un controlador o webhook que controle la actualización, el tiempo de espera y la semántica de fallos, mientras mantienes las invariantes locales en la política integrada.
¿Cómo puede recuperarse un ingeniero de guardia cuando una regla de denegación bloquea una solución?
Proporciona una identidad o namespace de emergencia (break-glass) delimitado y auditado con fecha de vencimiento, documenta la aprobación y genera alertas tras su uso. Prueba la vía antes de forzar el cumplimiento.
¿Cuándo eliminarías la política?
Elimina o deshabilita el binding cuando los falsos positivos sigan siendo altos, la latencia de admisión amenace al servidor de la API o la invariante se haya trasladado a un control más robusto. Conserva el historial y las métricas para fundamentar la decisión.