Planteamiento y alcance
Operas un clúster de Kubernetes multi-inquilino en nodos Linux que ejecutan SELinux en modo enforcing. La plataforma utiliza volúmenes CSI y algunas cargas de trabajo comparten un volumen. El equipo planea actualizar a v1.36. Diseña verificaciones de compatibilidad, un despliegue canary, observabilidad y reversión sin asumir que todos los nodos tienen SELinux habilitado.
Qué está evaluando el entrevistador
El entrevistador quiere que separes los nodos con SELinux de los nodos ordinarios, expliques la diferencia entre un contexto de montaje y el reetiquetado recursivo, e identifiques los riesgos cuando Pods con y sin privilegios comparten un volumen. Una respuesta sólida también cubre los controladores CSI, securityContext del Pod, la latencia de inicio, el acceso a los datos, los límites de admisión y la reversión basada en versiones.
Preguntas para aclarar primero
- ¿Qué nodos están en modo enforcing y qué controladores CSI y sistemas de archivos están dentro del alcance admitido?
- ¿El almacenamiento compartido es una restricción estricta del negocio, o se pueden dividir los volúmenes o intercambiar datos de forma explícita?
- ¿La migración optimiza la latencia de inicio, el aislamiento de inquilinos, la continuidad de la carga de trabajo o un balance explícito?
- ¿Permite la versión desplegada una política de etiquetado explícita y cuáles son la ventana de reversión y los requisitos de retención de evidencias?
Respuesta de 30 segundos
“Primero haría un inventario de los modos de SELinux de los nodos, los controladores CSI, los tipos de volumen y las relaciones de uso compartido. La mejora de v1.36 utiliza contextos de montaje para los volúmenes admitidos, lo que reduce el costo del reetiquetado recursivo pero puede cambiar los resultados de acceso para volúmenes compartidos. Ejecutaría cargas de trabajo equivalentes en un grupo de nodos aislado, verificando montajes, etiquetas, lecturas y escrituras, latencia de inicio y registros de denegación antes de expandir. Si falla una salvaguarda, detendría las nuevas cargas de trabajo, preservaría los Pods en ejecución y las evidencias, y revertiría usando una política admitida por la versión desplegada.”
Solución paso a paso
1. Construir el inventario de impacto
Registra el kernel y el estado de SELinux de cada nodo, si está en modo enforcing o permissive, la versión de Kubernetes, la versión del controlador CSI y el tipo de volumen. Exporta seLinuxOptions de cada Pod, su identidad, nivel de privilegios, rutas de montaje y relaciones de uso compartido. Los nodos sin SELinux no deben incluirse en la misma conclusión de comportamiento.
2. Explicar el cambio de comportamiento
El cambio en Kubernetes hace que la mejora de etiquetado de volúmenes de SELinux sea estable en v1.36. Para los volúmenes admitidos, el sistema puede usar un contexto de montaje en lugar de reetiquetar cada archivo de forma recursiva. Esto suele reducir el trabajo de inicio para volúmenes grandes, pero la suposición de que un volumen compartido se reetiqueta antes de usarse puede fallar cuando acceden a él diferentes dominios de seguridad. Un montaje exitoso no demuestra que la aplicación pueda leer y escribir.
3. Verificar los límites del controlador y las políticas
Para cada controlador CSI, verifica la compatibilidad con contextos de montaje, el comportamiento del sistema de archivos y las restricciones de opciones de montaje. Consulta la documentación de la versión desplegada para seLinuxChangePolicy, los feature gates relacionados y los valores predeterminados; no copies un campo o cambies desde una versión anterior sin verificación. La política de admisión debe restringir privilegios innecesarios, definir dominios de seguridad para volúmenes compartidos y auditar cambios.
4. Ejecutar comparaciones reproducibles
Prepara Pods de prueba con la misma imagen, UID/GID, securityContext y datos de volumen. Cubre un solo Pod, uso compartido en el mismo dominio, uso compartido con y sin privilegios, un volumen vacío y un volumen con muchos archivos. Verifica contextos de montaje, etiquetas de archivos, lecturas y escrituras, recuperación tras reinicios, expansión y reconexiones CSI. Mide cada intervalo desde la creación del Pod hasta Ready.
5. Añadir salvaguardas al canary
Crea un grupo de nodos dedicado y un conjunto pequeño de StorageClasses CSI, y comienza con tareas reintentables. No asignes el mismo volumen compartido a una combinación no verificada de dominios de seguridad durante el canary. Establece umbrales para registros de denegación, fallos de montaje, errores de permisos de la aplicación, latencia de inicio y éxito de reinicio. Detén la expansión cuando se active una salvaguarda; no ocultes el problema ampliando SELinux o los privilegios.
6. Gestionar el riesgo de volúmenes compartidos
Cuando un volumen es compartido por Pods con y sin privilegios, primero divide el volumen o unifica el dominio de seguridad antes de continuar. Para un uso compartido inevitable, define quién es el propietario del etiquetado, cuándo se monta el volumen y cómo se reclama, y luego valida una matriz de acceso real. Elimina un volumen antiguo solo después de que se demuestre la recuperación de la aplicación, de modo que un problema de etiquetado no se confunda con pérdida de datos.
7. Preservar evidencias para la reversión
La reversión comienza evitando que nuevos Pods ingresen al grupo canary mientras se preservan las tareas en ejecución y los eventos. Luego, selecciona una política recursiva explícitamente admitida o un grupo de nodos más antiguo para la versión desplegada. Conserva configuraciones de feature gates, etiquetas de nodos, configuración de CSI, manifiestos de Pods y registros de denegación AVC de SELinux. Vuelve a ejecutar la misma comparación tras la reversión; un comando de despliegue exitoso por sí solo no es prueba de recuperación.
Respuesta modelo
Estructuraría la migración en inventario, comparación, canary y reversión. Solo los nodos Linux con SELinux disponible en modo enforcing están dentro del alcance, y la compatibilidad del controlador CSI debe verificarse con la versión de Kubernetes desplegada. v1.36 utiliza contextos de montaje para volúmenes admitidos, reduciendo el reetiquetado recursivo pero requiriendo pruebas específicas para volúmenes compartidos y diferentes dominios de seguridad. Las pruebas cubren volúmenes vacíos y grandes, un solo Pod, uso compartido en el mismo dominio y uso compartido con y sin privilegios; comparan etiquetas, acceso, registros de denegación, latencia de inicio y recuperación tras reinicios. El grupo canary solo acepta trabajo reintentable. Si se supera un umbral, se detiene la expansión, se preserva la evidencia y se redirige el nuevo trabajo a una ruta documentada y admitida.
Errores comunes
- Tratar a todos los nodos como nodos SELinux → el alcance del impacto es incorrecto → particionar por modo de nodo y estado enforcing.
- Probar solo que el montaje sea exitoso → el acceso en tiempo de ejecución sigue denegado → probar la identidad real, las etiquetas, las lecturas, las escrituras y el reinicio.
- Ampliar privilegios inmediatamente → el límite de seguridad se expande → corregir el dominio de seguridad, la relación de uso compartido o la configuración del controlador.
- Ignorar las diferencias de CSI → una clase de volumen falla en el canary → crear una matriz con el controlador, el sistema de archivos y el tipo de volumen.
- Eliminar todos los Pods durante la reversión → se pierden evidencias y se detienen las tareas → congelar el nuevo tráfico y retener el estado y los registros.
Preguntas de seguimiento y respuestas
¿El modo permisivo requiere la misma migración?
Aun así amerita inventario y pruebas porque el modo permisivo registra denegaciones sin aplicarlas normalmente. No representa el comportamiento de enforcing, por lo que los criterios de liberación deben reproducirse en nodos con modo enforcing.
¿Cómo separas un problema de etiquetado de un problema de CSI?
Mantén constantes el nodo, la imagen y el contexto de seguridad mientras cambias el tipo de volumen o el controlador. Compara eventos de montaje, denegaciones del kernel, etiquetas de archivos y registros de CSI. Atribuye el problema a la ruta del contexto de seguridad solo cuando se reproduzca a través de distintos controladores.
¿Un inicio más rápido es suficiente para demostrar el éxito?
No. El rendimiento es solo una señal. La matriz de acceso para diferentes dominios, la recuperación tras reinicios, la expansión, el comportamiento de reconexión y la evidencia de auditoría también deben cumplir con los criterios de liberación.
¿Qué pasa si los volúmenes compartidos no pueden usar un único dominio de seguridad?
Es preferible dividir el volumen o utilizar una ruta de intercambio de datos explícita. Si compartir es inevitable, la plataforma debe ser propietaria de las decisiones de ciclo de vida y del dominio de seguridad, y las combinaciones permitidas de Pods deben aplicarse mediante políticas y someterse a pruebas de regresión.