Tema 16
Kubernetes ofrece automatización y escalabilidad para microservicios, pero también concentra gran parte del riesgo operativo en un plano de control poderoso. Si pods, permisos, políticas de red y admisión no están bien gobernados, el clúster se convierte en una superficie de ataque amplia y difícil de contener.
Kubernetes simplifica despliegue, descubrimiento, escalado y operación de microservicios, pero también agrega un plano de control con mucho poder. Ese plano decide qué corre, con qué imagen, en qué nodo, con qué red, con qué identidad y con qué permisos. Si esas decisiones quedan demasiado abiertas, el clúster entero hereda una postura débil.
La seguridad en Kubernetes no se reduce a proteger contenedores individuales. También implica controlar objetos del clúster, cuentas de servicio, políticas de red, permisos administrativos, flujos de despliegue y admisión de workloads.
Este tema introduce los bloques fundamentales de ese gobierno: pods, namespaces, RBAC, network policies y admission control.
En Kubernetes el pod es la unidad mínima desplegable. Agrupa uno o más contenedores que comparten ciertos recursos. Desde el punto de vista de seguridad, esto significa que la decisión de qué contenedores comparten pod no es neutra: compartir red, volumen o ciclo de vida puede ampliar superficie de interacción.
Conviene evitar mezclar componentes sin una razón fuerte, porque el pod establece una cercanía operativa que también puede facilitar abuso o exposición de datos.
Los namespaces ayudan a organizar workloads y recursos, y también aportan una primera capa de segmentación lógica. No sustituyen políticas de seguridad profundas, pero permiten separar dominios, equipos, ambientes o tipos de carga.
Una buena separación por namespaces ayuda a:
En Kubernetes, los pods suelen actuar a través de service accounts. Estas identidades permiten autenticar workloads frente al API server y, en ciertos escenarios, también frente a otros sistemas. Si todas las cargas usan cuentas por defecto o cuentas demasiado amplias, la trazabilidad y el mínimo privilegio se pierden rápidamente.
Una práctica madura implica:
RBAC, o Role-Based Access Control, define qué sujetos pueden realizar qué acciones sobre qué recursos del clúster. Es uno de los mecanismos más críticos, porque controla acceso al plano de control, a objetos sensibles y a capacidades administrativas.
| Elemento | Para qué sirve | Riesgo si se configura mal |
|---|---|---|
| Role | Permisos dentro de un namespace | Escalamiento de acceso local |
| ClusterRole | Permisos de alcance más amplio o cluster-wide | Impacto transversal sobre el clúster |
| Binding | Asocia roles con identidades | Asignación accidental de privilegios elevados |
Aplicar mínimo privilegio en Kubernetes implica mucho más que limitar acceso humano. También significa revisar qué puede hacer cada pipeline, controlador, operador, pod o cuenta técnica.
Por defecto, muchos clústeres tienden a permitir una conectividad demasiado amplia entre pods. Las network policies permiten restringir qué tráfico entra o sale de un conjunto de pods según namespaces, labels y reglas declaradas.
Su valor principal es reducir movimiento lateral y delimitar caminos válidos de comunicación.
Con ellas se puede expresar, por ejemplo:
El admission control permite validar o mutar objetos antes de que queden aceptados en el clúster. Es una pieza muy poderosa porque ayuda a impedir que workloads inseguros lleguen siquiera a ejecutarse.
Se puede usar para exigir políticas como:
Más allá del contenedor en sí, la especificación del pod define parte importante de la seguridad del runtime. Security contexts, usuarios, capabilities, privilegios, mounts y comportamiento del filesystem son decisiones que deben revisarse sistemáticamente.
Una mala especificación puede reintroducir dentro de Kubernetes todos los riesgos que el hardening del contenedor intentaba reducir.
Kubernetes facilita distribuir configuración y secretos a los workloads, pero eso no significa que todo esté resuelto por usar objetos nativos. Hay que revisar quién puede leerlos, montarlos, exportarlos o modificarlos.
El riesgo crece especialmente cuando:
Aunque este tema se centra en pods y políticas lógicas, no hay que olvidar que la seguridad del clúster también depende de nodos y del plano de control. Si un atacante obtiene control amplio sobre un nodo o sobre componentes administrativos, el impacto puede ser muy superior al de comprometer un pod aislado.
Por eso la seguridad del clúster requiere pensar en capas: workload, namespace, red, API server, control plane y nodo.
Kubernetes genera una gran cantidad de eventos y cambios de estado. Esa información es valiosa para seguridad si se observa correctamente. Conviene registrar y correlacionar al menos:
Kubernetes ofrece una base poderosa para operar microservicios, pero exige disciplina de seguridad en varios planos al mismo tiempo. Cuando pods, identidades, permisos y políticas de red están bien gobernados, el clúster puede convertirse en un entorno controlado y observable. Cuando no lo están, la automatización acelera también la propagación del riesgo.
En el próximo tema estudiaremos service mesh, mTLS y políticas de tráfico entre microservicios para ver cómo reforzar identidad, cifrado y control de comunicación dentro del clúster.