Consigna y contexto
Un equipo de plataforma debe inyectar el contexto de seguridad y las etiquetas de observabilidad predeterminados cuando se crean Pods, sin mantener un webhook de mutación externo. Utilizando Kubernetes MutatingAdmissionPolicy, diseñe la política, el binding, el manejo de conflictos, la auditoría y el plan de rollback.
Kubernetes v1.36 marca a MutatingAdmissionPolicy como estable. Utiliza CEL dentro del servidor de la API para describir la coincidencia y las mutaciones, y puede modificar un objeto entrante con ApplyConfiguration o JSONPatch. La definición de la política y el binding están separados. La entrevista evalúa si puede incorporar la mutación declarativa en una cadena de admisión auditable y reversible en lugar de limitarse a reescribir el manifiesto de un webhook.
Qué evalúa el entrevistador
El entrevistador busca un límite claro entre política y binding; una elección deliberada entre ApplyConfiguration y JSONPatch; mutaciones idempotentes con propiedad de campos explícita; manejo de failurePolicy, alcance, ordenamiento, conflictos, autoprotección, actualizaciones y rollback; y evidencia a partir de eventos de auditoría y métricas.
Preguntas de clarificación
Objetos de destino y valores predeterminados
Pregunte si solo los Pods o también los Deployments y Jobs están dentro del alcance, qué campos son valores predeterminados obligatorios, qué valores del usuario pueden prevalecer y cómo las cuentas de servicio, los namespaces y los selectores de etiquetas restringen el cambio.
Límite de versión y tiempo de ejecución
Confirme que el clúster sea v1.36, que admissionregistration.k8s.io/v1 esté habilitado, si los webhooks existentes permanecen en la cadena y si la política debe reutilizarse en varios clústeres.
Riesgo y rollback
Identifique los campos de seguridad protegidos, los modos de falla aceptables, la retención de auditoría, las ventanas de cambio y el efecto de deshabilitar la política en los objetos existentes y en las nuevas solicitudes.
Respuesta de 30 segundos
“Definiría la coincidencia y las mutaciones idempotentes en una política y luego usaría un binding para delimitar el alcance de los namespaces, recursos y parámetros. ApplyConfiguration maneja valores predeterminados estructurados simples; JSONPatch se reserva para operaciones precisas sobre arreglos. Las no coincidencias se omiten, mientras que los errores de mutación siguen failurePolicy. Evitaría la autocoincidencia, restringiría RBAC y realizaría el despliegue mediante dry runs, bindings reducidos y métricas de auditoría. El rollback elimina el binding y restaura una política versionada; no reescribe silenciosamente los objetos existentes.”
Solución paso a paso
Paso 1: Separar política y binding
La política almacena reglas, variables, condiciones de coincidencia y expresiones de mutación. El binding selecciona recursos y namespaces y puede proporcionar parámetros. Por lo tanto, una política se puede reutilizar con diferentes bindings para inquilinos o entornos durante un despliegue por fases.
Paso 2: Elegir una representación de mutación
ApplyConfiguration expresa valores predeterminados estructurados cercanos al modelo de objetos. JSONPatch maneja la inserción o eliminación de rutas exactas, pero los índices de arreglos y el escape de JSON Pointer deben ser correctos. No los mezcle en una estrategia de sobrescritura implícita; cada campo necesita una regla de propiedad y precedencia.
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingAdmissionPolicy
metadata:
name: pod-default-observability
spec:
matchConstraints:
resourceRules:
- apiGroups: [""]
apiVersions: ["v1"]
operations: ["CREATE"]
resources: ["pods"]
mutations:
- applyConfiguration:
expression: >-
Object{metadata: Object{labels: {"observability.example.com/enabled": "true"}}}
---
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingAdmissionPolicyBinding
metadata:
name: pod-default-observability-binding
spec:
policyName: pod-default-observability
matchResources:
namespaceSelector:
matchLabels:
platform.example.com/enabled: "true"Paso 3: Hacer que las mutaciones sean idempotentes y no destructivas
Escriba valores predeterminados solo cuando los campos estén ausentes, preservando los valores explícitos del usuario. Para listas, defina una fusión basada en claves o el reemplazo de toda la lista; los reintentos, la admisión repetida y las actualizaciones no deben anexar duplicados. Verifique si la evaluación del objeto mutado puede activar la misma regla nuevamente, creando un bucle autoamplificado.
Paso 4: Limitar la coincidencia y proteger la política
Reduzca el alcance con apiGroups, resources, operations, namespaceSelector y objectSelector. Una MutatingAdmissionPolicy no puede coincidir consigo misma ni con su binding, evitando que una política cambie su propia configuración a un estado irrecuperable. Utilice listas de permitidos explícitas para campos de alto riesgo, de modo que los parámetros CEL proporcionados por el usuario no puedan expandir la autoridad de escritura.
Paso 5: Definir errores y ordenamiento
Distinga entre una no coincidencia, un resultado de expresión vacío, un error de mutación y una falla temporal del servidor de la API. Elija Fail o Ignore mediante failurePolicy y acompáñelo con alertas. No dependa de un ordenamiento oculto entre mutadores; separe la propiedad de los campos o centralice una decisión cuando las políticas vayan a escribir en el mismo campo.
Paso 6: Migrar y versionar webhooks
Compare el resultado del webhook anterior con la nueva política en una fase de sombra o solo de auditoría, luego vincule la política a un conjunto reducido de namespaces. Registre la versión de la política, el UID de la solicitud, un resumen del objeto original y el motivo de la mutación. Elimine el webhook gradualmente después de comprender los conflictos, manteniendo manifiestos versionados para comparación y rollback.
Paso 7: Revertir y observar
Para un rollback de emergencia, pause o elimine el binding para que las nuevas solicitudes dejen de modificarse y luego restaure la versión anterior de la política. Los objetos existentes no se desmutan al eliminar un binding; la limpieza necesita un controlador o proceso por lotes independiente y aprobado. Monitoree la latencia de admisión, la tasa de rechazo, el recuento de mutaciones, los errores de expresión y la tasa de aciertos por namespace.
Respuesta modelo
Trataría la política como una regla versionada y el binding como el límite de despliegue y permisos. Delimitaría su alcance a Pod CREATE en namespaces seleccionados y aplicaría valores predeterminados idempotentes solo a las etiquetas y campos de seguridad faltantes; usaría JSONPatch probado para rutas de arreglos exactas. Definiría failurePolicy, listas de permitidos de campos, RBAC y autoprotección antes del despliegue. Compararía los resultados antiguos y nuevos, vincularía un conjunto reducido de namespaces y expandiría utilizando métricas de auditoría, latencia y errores. El rollback elimina el binding y restaura la política anterior; los objetos existentes no se revierten automáticamente, por lo que la limpieza es un proceso auditado independiente.
Errores comunes
- Error: Reemplazar todo el objeto. → Por qué falla: Se borra la configuración explícita del usuario y aparecen conflictos de propiedad. → Solución: Escriba solo los campos faltantes y defina reglas de fusión de listas.
- Error: Asumir que eliminar un binding restaura los objetos antiguos. → Por qué falla: La admisión afecta a las solicitudes; no proporciona mutación inversa. → Solución: Utilice un proceso de limpieza auditado independiente y especifique el comportamiento para los objetos existentes.
- Error: Depender de un orden fijo entre políticas. → Por qué falla: Los cambios en el orden de admisión pueden modificar el resultado. → Solución: Separe la propiedad de los campos o centralice la decisión.
- Error: Reemplazar el webhook de producción inmediatamente. → Por qué falla: Las diferencias en las expresiones pueden manifestarse durante los picos de carga. → Solución: Pruebe primero en modo sombra, despliegue por namespace y conserve manifiestos versionados.
Preguntas de seguimiento y respuestas
¿Cómo elige entre ApplyConfiguration y JSONPatch?
Utilice ApplyConfiguration para valores predeterminados estructurados y una intención más clara. Utilice JSONPatch para inserción precisa, eliminación o rutas con caracteres de escape. Pruebe la ejecución repetida y los conflictos de arreglos con cualquiera de las dos formas.
¿Debería failurePolicy ser siempre Fail?
Las líneas base de seguridad y los campos de cumplimiento normativo suelen favorecer Fail. Las etiquetas de observabilidad no críticas pueden usar Ignore con alertas explícitas y compensación. Vincule la decisión al impacto, los objetivos de disponibilidad y la evidencia de auditoría.
¿Cómo prueba que una política no corromperá los objetos?
Construya una matriz con dry runs del servidor, instantáneas de entrada fijas, admisión repetida, etiquetas de namespace, campos de usuario preestablecidos, listas vacías y errores de expresión; luego compare los resultados del webhook anterior y de la nueva política.
¿Por qué no escribir un controlador en su lugar?
La admisión bloquea o modifica una solicitud antes de la persistencia, lo cual es adecuado para valores predeterminados y restricciones de entrada. Los controladores concilian de forma asíncrona y reparan objetos existentes. Pueden complementarse entre sí, pero un controlador no reemplaza una política de seguridad de entrada.