Planteamiento y alcance
Esta es una pregunta de diseño de sistemas para ingenieros de seguridad de plataformas. Kubernetes v1.36 introduce el control de admisión basado en manifiestos como una funcionalidad alfa. Las políticas se cargan desde un directorio local en el servidor de la API antes de atender solicitudes, por lo que el diseño debe funcionar antes de que etcd esté disponible y debe incluir una ruta de recuperación basada en archivos.
Qué evalúa el entrevistador
- La separación entre una política de arranque y las políticas gestionadas por la API.
- La validación atómica, la reversión (rollback) y el comportamiento de fallo rápido (fail-fast) en el inicio.
- La protección de la configuración de políticas y webhooks contra la eliminación privilegiada.
- La distribución de la configuración y la detección de desfases entre instancias del servidor de la API.
- Los mecanismos de escape para operadores, la auditabilidad y las pruebas de modos de fallo.
¿Qué recursos están protegidos?
Aclare si la línea base protege únicamente los objetos ValidatingAdmissionPolicy o también bindings, webhooks y configuraciones mutables. Las reglas de coincidencia y el radio de impacto cambian según esa respuesta.
¿Cuál es la autoridad de recuperación?
Si la API no está disponible o la política bloquea su propia reparación, la ruta autoritativa debe ser el host del servidor de la API o su canalización de configuración inmutable. Defina quién puede modificar esa ruta y cómo se revisan los cambios.
¿Cuántos servidores de la API se ejecutan?
Cada instancia lee sus propios archivos. Una flota necesita artefactos direccionados por contenido, secuenciación de despliegues y una métrica de hash de configuración; un solo servidor puede utilizar un observador local más simple, pero aún requiere un reemplazo atómico.
Marco de respuesta de 30 segundos
“Instalaría una política de manifiesto pequeña y revisada antes de habilitar cualquier política gestionada por la API. Esta deniega actualizaciones o eliminaciones para los recursos marcados como protegidos, y su nombre utiliza el sufijo reservado .static.k8s.io. Cada servidor de la API recibe el mismo directorio versionado y expone su hash de configuración. Los cambios de archivo se validan y se intercambian atómicamente; las actualizaciones no válidas conservan la última versión válida, mientras que un inicio no válido falla rápidamente. Los operadores se recuperan a través de la ruta de configuración del host, nunca a través de la API bloqueada.”
Diseño paso a paso
Arrancar el límite de confianza
Habilite ManifestBasedAdmissionControlConfig en cada servidor de la API y configure staticManifestsDir a través del archivo de configuración de admisión existente. Almacene los manifiestos en un artefacto de solo lectura y con verificación de integridad. Exija que el nombre de cada objeto estático termine en .static.k8s.io para que las métricas y los registros de auditoría distingan los objetos respaldados por archivos de los objetos de la API.
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: ValidatingAdmissionPolicy
configuration:
staticManifestsDir: /etc/kubernetes/admission/staticEscribir la regla de protección
La política de arranque coincide con operaciones UPDATE y DELETE en políticas de admisión, bindings y configuraciones de webhooks. Deniega cambios únicamente cuando el objeto antiguo tiene una etiqueta de protección como platform.example.com/protected=true. Esto mantiene la posibilidad de experimentación ordinaria al tiempo que protege la línea base.
Hacer que las actualizaciones sean transaccionales
El servidor de la API valida un conjunto de archivos modificados y lo intercambia de forma atómica. Si la validación falla en tiempo de ejecución, retenga la configuración válida anterior y registre el error. Al iniciar, falle antes de atender solicitudes si algún manifiesto no es válido; iniciar silenciosamente sin la línea base crearía exactamente la brecha de arranque que la funcionalidad busca cerrar.
Operar una flota de múltiples servidores
Genere el mismo paquete direccionado por contenido para cada servidor de la API y realice el despliegue instancia por instancia. Compare la etiqueta de hash de configuración y las métricas de decisiones de admisión. Una discrepancia de hash es un desfase, no una diferencia de versiones inofensiva; detenga el despliegue y restaure el paquete conocido antes de cambiar la semántica de las políticas.
Preservar un mecanismo de escape
La política estática no debe depender de un Service, paramKind u otro objeto de la API. Esas referencias no están disponibles antes de que exista el estado del clúster. Mantenga una ruta auditada a nivel de host para reemplazar los archivos y pruebe que una política malformada o demasiado amplia pueda revertirse sin una llamada a la API.
Respuesta de muestra de alta calidad
“Trataría el directorio estático como una raíz de confianza, distribuiría un paquete firmado y versionado a cada servidor de la API y utilizaría una política estática para denegar modificaciones a los recursos de admisión etiquetados. Los nombres que terminan en .static.k8s.io hacen visible la procedencia. Las ediciones en tiempo de ejecución se validan y se intercambian atómicamente; el inicio rechaza cualquier paquete no válido. Cada servidor exporta un hash de configuración, por lo que el despliegue se detiene ante cualquier desfase. La recuperación es un cambio auditado en el host, no una solicitud a la API, y las pruebas canary cubren el arranque, los intentos de eliminación, las actualizaciones malformadas, los reinicios del servidor y los paquetes mixtos.”
Errores comunes
- Proteger políticas con otra política de la API → La API no puede proteger su propia configuración → ancle la protección en archivos estáticos.
- Permitir que una sola edición incorrecta reemplace el conjunto activo → Un error de sintaxis puede eliminar toda la protección → valide el conjunto completo y retenga la última versión válida.
- Iniciar con manifiestos no válidos → El servidor se ejecuta sin la línea base prevista → falle rápidamente antes de atender solicitudes.
- Asumir que los servidores de la API comparten archivos → Una instancia puede aplicar una política diferente → distribuya paquetes y compare hashes.
- Eliminar todos los mecanismos de escape para operadores → Un error en la política se convierte en una interrupción del servicio → mantenga una ruta de recuperación en el host privilegiada y auditada.
Rúbrica de evaluación y autoevaluación
Evalúe la seguridad del arranque, la coincidencia de políticas, las actualizaciones atómicas, la consistencia de la flota, la recuperación y las pruebas. Una respuesta sólida expone por qué la configuración estática puede proteger los recursos gestionados por la API sin caer en admisión circular, y dónde el diseño proporciona deliberadamente a los operadores un canal de recuperación ajeno a la API.
Preguntas de seguimiento y extensiones
¿Qué ocurre si un servidor de la API se reinicia durante el despliegue?
Mantenga disponible el paquete anterior, condicione la disponibilidad (readiness) a la carga exitosa de la admisión estática y compare el hash reportado antes de reincorporar el servidor al tráfico.
¿Pueden las políticas estáticas hacer referencia a un webhook de Service?
No. La funcionalidad es autónoma antes de que exista el estado del clúster; utilice un webhook basado únicamente en URL o una política CEL sin dependencia de recursos de la API, y documente el compromiso de disponibilidad.
¿Cómo se prueba una política que bloquea su propia eliminación?
Cree un objeto de prueba protegido, intente actualizarlo y eliminarlo a través de la API, verifique la denegación y los registros de auditoría, luego reemplace el paquete estático mediante la ruta de recuperación y confirme que el objeto pasa a ser manejable.
¿Cuál es el invariante del despliegue?
Cada servidor de la API en servicio debe aplicar el mismo hash de paquete aprobado, y al menos una ruta de recuperación auditada debe permanecer disponible incluso cuando la API rechace los cambios de configuración.