Entrevista de diseño de sistemas: ¿Cómo migrar de forma segura la seguridad de Pods de Kubernetes a enforce?

Planteamiento y alcance

El equipo de plataforma debe migrar los namespaces al nivel restricted de los Kubernetes Pod Security Standards. Las cargas de trabajo provienen de servicios de producción, infraestructura compartida y trabajos de compilación temporales. Diseñe el descubrimiento, la remediación, las excepciones, la transición y el rollback.

Qué evalúa el entrevistador

• Comprensión de los diferentes efectos secundarios de enforce, audit y warn.
• Integración de namespaces, cargas de trabajo y excepciones en un único límite de gobernanza.
• Uso de observaciones para impulsar la remediación en lugar de rechazar todo inmediatamente.
• Consideración de versiones de políticas fijadas, registros de auditoría y rollback de emergencia.

Preguntas aclaratorias

1. ¿Qué versiones de Kubernetes, límites de inquilinos y herramientas de lanzamiento se utilizan?
2. ¿El objetivo es baseline o restricted, y pueden los namespaces utilizar niveles diferentes?
3. ¿Qué cargas de trabajo requieren privilegios, hostPath o redes de host?
4. ¿El rollback significa reducir temporalmente una política o desviar el tráfico a un clúster antiguo?

Una respuesta de 30 segundos

Comience por namespace con audit y warn para recopilar infracciones y brindar retroalimentación accionable a quienes envían las solicitudes; no active primero enforce a nivel global. Remedie en orden de riesgo y de negocio con versiones de políticas fijadas. Cada excepción necesita un responsable, un motivo, una fecha de vencimiento y un control compensatorio. Tras un piloto pequeño, habilite enforce namespace por namespace y monitoree las tasas de rechazo y de éxito de los lanzamientos. El rollback de emergencia reduce únicamente la política del namespace afectado mientras conserva el registro de auditoría.

Diseño paso a paso

1. Establecer una línea base de activos y políticas

Haga un inventario de namespaces, plantillas de Pods, controladores y fuentes de lanzamiento. Agrupe producción, infraestructura compartida, desarrollo y trabajos temporales. Elija un nivel y una versión objetivo para cada grupo, y registre las excepciones; un namespace sin etiquetar es una brecha de seguridad, no un valor predeterminado seguro.

2. Observar antes de bloquear

Habilite audit para registrar infracciones y el mismo nivel en warn para retroalimentación al cliente. Agregue eventos por regla, equipo e imagen en una cola de remediación. Esto expone el riesgo sin interrumpir el tráfico actual.

metadata:
  labels:
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

3. Remediar cargas de trabajo

Elimine privilegios innecesarios, hostNetwork, hostPID, hostPath y sistemas de archivos raíz con permisos de escritura. Agregue restricciones de non-root, seccomp y capabilities. Integre verificaciones de políticas en CI para que una plantilla falle indicando un campo específico antes de que el clúster la rechace.

4. Gobernar excepciones

Otorgue excepciones únicamente en un namespace gobernable o en un punto de entrada controlado. Registre el impacto, el responsable, la fecha de vencimiento y los controles compensatorios. Una exención de admisión no es una lista de permitidos permanente; las renovaciones requieren revisión, y los namespaces del sistema no deben quedar exentos incondicionalmente.

5. Transición escalonada a enforce

Habilite enforce primero para namespaces de bajo riesgo. Compare las tasas de rechazo, fallos de lanzamiento, reinicios y quejas de inquilinos antes de expandir. Fije las versiones de las políticas; ensaye las actualizaciones en warn y audit para que un cambio de latest no genere una ola sorpresiva de rechazos.

6. Rollback y verificación

Los controladores de lanzamiento deben pausar y restaurar plantillas antiguas. Si un servicio crítico se bloquea, reduzca temporalmente solo la política de ese namespace mientras conserva audit y los eventos. Pruebe nuevos Pods, plantillas de Deployment, actualizaciones progresivas, Jobs, vencimiento de excepciones y actualizaciones de versiones de políticas.

Respuesta modelo de alta calidad

Haría un inventario de namespaces y cargas de trabajo, fijaría versiones de políticas y luego recopilaría infracciones con audit junto con warn en el mismo nivel. CI verifica los contextos de seguridad tempranamente, mientras que las excepciones cuentan con responsables y fechas de vencimiento. Los namespaces de bajo riesgo pasan a enforce primero; solo expando después de que la tasa de rechazo, el éxito de los lanzamientos y los errores de negocio se mantengan en niveles aceptables. Las actualizaciones de políticas se ensayan con warn/audit. Si un servicio se bloquea, hago rollback solo de la política de su namespace, preservo el registro de auditoría y soluciono la causa raíz en lugar de debilitar el clúster de forma permanente.

Errores comunes

• Habilitar enforce de forma global de inmediato → muchos lanzamientos fallan a la vez → use audit/warn y etapas.
• Tratar los namespaces sin etiquetar como seguros → la cobertura de políticas tiene puntos ciegos → etiquételos e inventaríelos.
• Crear exenciones permanentes → el riesgo permanece oculto → exija fecha de vencimiento y revisión.
• Descubrir infracciones solo en el clúster → la retroalimentación llega demasiado tarde → traslade las verificaciones a CI y a la revisión de plantillas.
• Utilizar latest sin ensayar → un cambio de versión provoca rechazos sorpresivos → fije y observe previamente.

Preguntas de seguimiento y respuestas

¿Por qué habilitar tanto warn como audit si ninguno de los dos bloquea?

warn ofrece retroalimentación inmediata al cliente que envía la solicitud; audit registra las infracciones para la medición de la plataforma. Respaldan flujos de trabajo diferentes y no se reemplazan mutuamente.

¿Debe el alcance de una excepción limitarse a un Pod o a un namespace?

Prefiera un límite de namespace gobernable con un punto de entrada controlado. Las concesiones por Pod son fáciles de copiar y eludir; todas las excepciones requieren un responsable, fecha de vencimiento y control compensatorio.

¿Cómo demuestra que la disponibilidad no disminuyó?

Compare rechazos, éxito de lanzamientos, reinicios, SLOs y errores de inquilinos antes y después de cada etapa. Reproduzca actualizaciones progresivas y Jobs de corta duración, así como servicios de larga ejecución.