Aislamiento multi-inquilino

En Kubernetes, un espacio de nombres agrupa recursos y permite aplicar permisos, cuotas y políticas por grupo, pero por sí solo no aísla: sin políticas de red, los pods de un espacio pueden hablar con los de otro, y mientras compartan nodo comparten núcleo del sistema operativo y recursos de la máquina. El aislamiento fuerte es una suma de capas, y cuánto se añade depende de cuánta confianza haya entre inquilinos.

Una política de red de denegación por defecto bloquea el tráfico que no se permitió expresamente; sin ella, el espacio acepta conexiones de cualquier otro pod del clúster, incluidos los de otros inquilinos. En una plataforma multi-inquilino, un espacio sin esa política es un vecino con la puerta abierta.

Lee la tabla de espacios y busca el que no tiene política.

Los límites de recursos (cuotas de CPU y de memoria por espacio) impiden que un inquilino consuma lo que necesitan los demás. Sin ellos, un error de un inquilino, un pico de carga o un abuso se convierten en un problema de todos los que comparten nodo.

Cruza la tabla de espacios con las incidencias de rendimiento: ¿quién aparece como causa sin tener tope?

Los permisos de un inquilino deben quedarse en su espacio. Una cuenta de servicio con permiso de lectura de secretos en todo el clúster puede leer los secretos de los demás inquilinos, aunque el resto de los controles esté bien puesto. Las cuentas de plataforma tienen ámbito de clúster por necesidad; las de un inquilino, no.

Las incidencias de la última semana tienen un patrón: afectan a espacios que comparten nodos con otro que no tiene cuota. El aislamiento de recursos es una mezcla de cuotas, de prioridades y, para cargas sensibles al tiempo de respuesta como el plano de usuario, de nodos reservados. Cada capa cuesta capacidad: se pone donde el riesgo lo justifica.