Entrevista de diseño de sistemas: ¿Cómo migrarías los Pods de Kubernetes a User Namespaces?

Prompt y contexto aplicable

Un clúster de Kubernetes contiene imágenes heredadas que aún se ejecutan como UID 0 dentro del contenedor. Seguridad desea utilizar user namespaces para reducir el impacto en el host de un escape de contenedor, mientras que el negocio está preocupado por la propiedad de los volúmenes, hostPath, agentes de monitoreo, capacidades privilegiadas y nodos más antiguos. Diseña el plan de migración, validación, canary, observabilidad y rollback.

Esta es una pregunta de diseño de sistemas. La señal evaluada consiste en mapear el aislamiento con la identidad, el almacenamiento, la programación (scheduling), las políticas y las operaciones, en lugar de limitarse a escribir hostUsers: false.

Qué evalúa el entrevistador

• Explicar la diferencia entre el root del contenedor y el UID del host, incluido el alcance de las capacidades.
• Encontrar los límites entre volúmenes, namespaces del host, runtimes CRI/OCI y Pod Security.
• Diseñar verificaciones de compatibilidad y una migración por etapas sin romper las cargas de trabajo existentes.
• Definir el beneficio de seguridad, el costo de rendimiento, los SLO, las métricas y las condiciones de rollback.
• Manejar contraejemplos de aplicación, depuración, monitoreo y respaldo después de la migración.

Kubernetes documenta los user namespaces como estables y habilitados por defecto en v1.36; un Pod opta por utilizarlos con spec.hostUsers: false. El material para SDE II de Amazon evalúa el diseño de sistemas a través de la confiabilidad, la eficiencia, la optimización y la escalabilidad. Esta pregunta agrega el requisito de cuantificar el beneficio de seguridad y el riesgo operativo en conjunto.

Preguntas de aclaración

1. ¿El clúster es únicamente Linux y las versiones de kubelet, CRI, runtime OCI y kernel cumplen con el requisito?
2. ¿Las cargas de trabajo utilizan hostNetwork, hostPID, hostIPC, hostPath, dispositivos, contenedores privilegiados o agentes de monitoreo que necesitan UID del host?
3. ¿Qué volúmenes se comparten entre Pods y los UID/GID de los archivos existentes están dentro del rango mapeable?
4. ¿La aplicación realmente necesita root del host o solo semántica de root dentro de su contenedor?
5. ¿El objetivo es la contención de escapes, el cumplimiento de Pod Security o una capacidad específica con namespace como la administración de red local al contenedor?
6. ¿Se puede realizar un despliegue canary por namespace, pool de nodos o carga de trabajo mientras se conserva una plantilla con hostUsers=true para el rollback?

Marco de respuesta de 30 segundos

Construye una matriz de elegibilidad para Linux, kernel, runtime CRI/OCI, namespaces del host, volúmenes y capacidades privilegiadas. Establece hostUsers: false solo para Pods elegibles. Verifica que la semántica de UID de la aplicación se mantenga estable mientras el host ve un UID mapeado y sin privilegios. Prueba el acceso a archivos, el monitoreo, la red y la depuración, y luego realiza despliegues canary por carga de trabajo. Monitorea la latencia de inicio, errores de permisos, OOM, controles de escape y SLO del negocio; regresa a la plantilla anterior si se superan los umbrales.

Respuesta profunda paso a paso

1. Explicar el modelo de aislamiento

Un user namespace mapea los usuarios del contenedor a diferentes UID y GID del host. Root dentro del contenedor puede realizar las operaciones necesarias dentro de ese namespace, pero sus capacidades son válidas solo allí y no otorgan poder de root en el host. Kubernetes habilita un Pod con hostUsers: false y asigna mapeos de host sin superposiciones en un nodo.

Esto cambia un límite de identidad del kernel; no es un sandbox completo. Continúa utilizando seccomp, AppArmor o SELinux, políticas de red, sistemas de archivos de solo lectura, mínimo privilegio y nodos con parches aplicados. Los user namespaces son un control, no una solución para todas las vías de escape.

2. Verificar la elegibilidad del runtime y de los nodos

Confirma el soporte de user namespaces en kubelet, CRI y el runtime OCI en cada nodo de destino. La documentación de Kubernetes enumera soporte como containerd 2.0, CRI-O 1.25, runc 1.2 y crun 1.9; los despliegues aún deben verificar el kernel, los montajes con idmapped y las configuraciones de la distribución.

La política de admisión puede rechazar nodos o combinaciones de capacidades que no sean elegibles. CI renderiza el Pod final y verifica hostUsers, el contexto de seguridad, los namespaces del host y los tipos de volumen. Antes del despliegue, un Pod de prueba valida la creación, los montajes, los reinicios y la reprogramación en nodos.

3. Evaluar volúmenes y UID/GID

En el Pod, runAsUser, runAsGroup y fsGroup siguen describiendo al usuario dentro del contenedor. La semántica de permisos de los volúmenes debería seguir utilizable como antes, por lo que las aplicaciones normalmente no necesitan una reescritura general de propiedad solo porque los user namespaces estén habilitados.

Los archivos fuera del rango mapeado de UID/GID pueden aparecer como un ID de desbordamiento (overflow ID) y es posible que no se puedan escribir. Escanea propietarios, scripts de inicio, volúmenes compartidos y herramientas de respaldo/restauración antes de la migración. Repara las imágenes o los datos antes de habilitar user namespaces para esa carga de trabajo.

4. Manejar combinaciones prohibidas y políticas

Con los user namespaces habilitados, un Pod no puede usar ciertos namespaces del host como hostNetwork, hostPID o hostIPC. Las cargas de trabajo que necesitan dispositivos del host, modo privilegiado o montajes especiales de proc requieren una revisión por separado. Los Pod Security Standards pueden relajar verificaciones seleccionadas de forma controlada, pero eso no es un permiso para eliminar todas las demás políticas.

Marca las cargas de trabajo dependientes de namespaces del host como diferidas y registra la aprobación de la excepción, los controles compensatorios y una fecha de expiración. No elimines campos automáticamente solo para pasar la admisión; eso convierte una falla funcional en una degradación de seguridad invisible.

5. Diseñar rendimiento, SLO y observabilidad

Rastrea la latencia de inicio del Pod y de montaje de volúmenes, la CPU y memoria del nodo, los errores de permisos dentro del contenedor, la pérdida de monitoreo, el éxito de respaldo/restauración y los reinicios. Los montajes idmapped pueden evitar un chown recursivo en volúmenes grandes, pero mide con el kernel, runtime y sistema de archivos reales en lugar de depender de una afirmación teórica.

Etiqueta logs y métricas con la versión de migración, pool de nodos, imagen y tipo de volumen. Las señales de seguridad incluyen pruebas de escape rechazadas, operaciones privilegiadas fallidas y violaciones de Pod Security; las señales del negocio incluyen errores de peticiones, latencia e integridad de datos.

6. Migración por etapas y rollback

Comienza con cargas de trabajo sin estado que no utilicen ningún namespace del host y empleen volúmenes simples, luego expande a servicios con estado. Conserva el hash de una plantilla con hostUsers=true para cada lote. Detén el proceso automáticamente ante errores de permisos, regresión en el tiempo de inicio, tasa de errores del negocio, fallas de lectura/escritura de volúmenes o desalojos (evictions) de nodos.

El rollback cambia más de un campo: verifica que los montajes de volúmenes, los usuarios de runAs, los agentes de monitoreo y la salida de admisión regresen a su forma anterior. Evita actualizar el runtime, el kernel y la imagen en la misma ventana para que las fallas sigan siendo atribuibles.

7. Declarar el beneficio de seguridad y el riesgo residual

Los user namespaces reducen el impacto en el host de un escape de contenedor como root y proporcionan un dominio más restringido para cargas de trabajo que necesitan administración local al contenedor. No protegen los secretos de la aplicación, ataques lógicos entre contenedores, malas políticas de red ni un servicio compartido que ya haya sido comprometido.

La revisión de seguridad debe listar los hostPath, dispositivos, capacidades, interfaces del kernel y service accounts restantes, para luego combinar seccomp, SELinux, aislamiento de nodos y aplicación de parches de vulnerabilidades en una defensa en profundidad.

Ejemplo de respuesta de alta calidad

Construiría una matriz de elegibilidad: los nodos de destino deben ser Linux y cumplir con los requisitos de user namespaces para kubelet, runtime CRI/OCI, kernel y sistema de archivos. Excluiría Pods que utilicen hostNetwork, hostPID, hostIPC, dispositivos privilegiados o suposiciones sobre UID del host. Las plantillas elegibles establecen hostUsers: false; las pruebas confirman que la semántica de UID/GID del contenedor se mantiene correcta mientras el host ve un mapeo sin privilegios.

Antes del despliegue escanearía propietarios de volúmenes, scripts de inicio, volúmenes compartidos y rutas de respaldo/restauración, incluyendo el comportamiento de overflow-ID. Un Pod de prueba verifica la creación, montajes, reinicios y reprogramación. Los despliegues canary miden la latencia de inicio y montaje, errores de permisos, SLO del negocio, desalojos, monitoreo y señales de respaldo. El hash de la plantilla anterior permanece disponible para un rollback inmediato.

Trataría los user namespaces como una capa de defensa en profundidad y mantendría seccomp, SELinux/AppArmor, políticas de red, mínimo privilegio y aplicación de parches en nodos. El beneficio de seguridad, el costo de rendimiento y las cargas de trabajo diferidas pertenecen a la lista de verificación de migración; configurar un solo campo no constituye la migración en sí misma.

Errores comunes

• Escribir únicamente hostUsers: false sin verificar las condiciones de Linux, runtime, kernel y volúmenes.
• Decir que el root del contenedor se convierte en un usuario ordinario e ignorar los dos significados de UID.
• Tratar los user namespaces como una solución automática para cada riesgo de escape, privilegios o red.
• Omitir los límites de hostNetwork, hostPID, hostIPC, hostPath, dispositivos y montajes de proc.
• Aplicar chown recursivo a cada volumen o fallar al escanear archivos con UID/GID desbordados (overflow).
• Actualizar runtime, kernel e imagen juntos, haciendo imposible atribuir las fallas.
• No contar con una plantilla anterior, condición de detención automática o un rollback verificable.

Preguntas de seguimiento y respuestas

¿Qué versión de Kubernetes hace que los user namespaces sean estables?

La documentación oficial marca la característica como estable y habilitada por defecto en Kubernetes v1.36; los Pods aún deben optar por ella mediante spec.hostUsers: false. Verifica las versiones reales del clúster y de los nodos antes del despliegue.

¿Puede el root del contenedor seguir utilizando capacidades?

Puede utilizar capacidades válidas dentro de ese user namespace, pero esas capacidades no se convierten automáticamente en privilegios del host. Aplica mínimo privilegio, seccomp y controles LSM.

¿Se romperán todos los permisos de PVC existentes?

La semántica de UID/GID del contenedor normalmente se mantiene estable, por lo que no se requiere una reescritura general de propiedad. Los archivos fuera del rango de mapeo pueden convertirse en overflow IDs y deben escanearse y repararse.

¿Por qué no se puede combinar con hostNetwork?

Los user namespaces dependen de límites de usuarios y recursos aislados, y algunas combinaciones de namespaces del host debilitarían ese aislamiento, por lo que Kubernetes las prohíbe. Mantén las cargas de trabajo con red del host como excepciones explícitas con controles compensatorios.

¿Cómo demuestras que el riesgo se redujo?

Ejecuta pruebas de aislamiento de escapes y operaciones privilegiadas, observa el UID del host, las capacidades y el alcance de acceso, y compara los errores de negocio, la latencia de inicio y la integridad de los volúmenes. El éxito en la creación del Pod por sí solo no es una prueba.

¿Qué cargas de trabajo deberían esperar?

Difiere las cargas de trabajo que necesiten namespaces del host, dispositivos especiales, interfaces del kernel privilegiadas o esquemas de UID/GID de volumen no reparables. Registra el motivo, los controles compensatorios y una fecha de reevaluación.