Seguridad de Kubernetes: RBAC, políticas de red y seguridad de pods

Kubernetes orquesta cargas de trabajo contenerizadas a gran escala, pero su complejidad crea una amplia superficie de ataque. Entre los componentes clave que deben protegerse se incluyen: el API Server (el plano de control central; su compromiso proporciona el control de todo el clúster), etcd (la base de datos del estado del clúster; almacena los secretos en base64 y debe cifrarse en reposo), kubelet (el agente del nodo; una API de kubelet sin autenticación permite ejecutar pods arbitrarios), el runtime de contenedores (Docker/containerd) y la red que conecta todos los pods. Quienes se preparen para Security+ deben comprender que las configuraciones incorrectas de Kubernetes se encuentran entre los hallazgos de seguridad en la nube más comunes.

El RBAC (Role-Based Access Control) de Kubernetes controla qué usuarios, cuentas de servicio y procesos pueden realizar determinadas acciones sobre recursos específicos de la API. El modelo consta de cuatro objetos: Role (permisos dentro de un namespace), ClusterRole (permisos en todo el clúster), RoleBinding (concede un Role a un sujeto dentro de un namespace) y ClusterRoleBinding (concede un ClusterRole a un sujeto en todo el clúster). Cada comando kubectl se traduce en una llamada a la API que se comprueba frente a las reglas de RBAC. Si RBAC no está configurado, cualquier usuario autenticado (o cuenta de servicio) puede tener acceso administrativo.

Cada pod de Kubernetes se ejecuta con una cuenta de servicio, una identidad utilizada para la autenticación ante la API. De forma predeterminada, los pods utilizan la cuenta de servicio default de su namespace, que puede tener permisos amplios. El principio de mínimo privilegio exige crear cuentas de servicio específicas para cada aplicación, con solo los permisos que necesita. Además, establecer automountServiceAccountToken: false en los pods que no necesitan acceso a la API impide que el token de la cuenta de servicio se monte en el sistema de archivos del pod, donde una aplicación comprometida podría utilizarlo para realizar llamadas a la API.

De forma predeterminada en Kubernetes, todos los pods pueden comunicarse con todos los demás pods de cualquier namespace. Un pod comprometido puede intentar inmediatamente acceder a bases de datos, API internas y otros microservicios. Los recursos Kubernetes NetworkPolicy definen reglas que restringen el tráfico entre pods según etiquetas, namespaces y puertos. El enfoque recomendado consiste en aplicar una política de red de «denegar todo de forma predeterminada» en cada namespace y, después, añadir reglas explícitas de autorización para las rutas de comunicación necesarias. Tenga en cuenta que NetworkPolicy requiere un plugin CNI compatible (Calico, Cilium, Weave); Kubernetes sin modificaciones ignora NetworkPolicy si no cuenta con un CNI compatible.

Los Pod Security Standards (PSS), introducidos en Kubernetes 1.23 y estables desde la versión 1.25, sustituyen a la directiva obsoleta Pod Security Policy (PSP) mediante tres perfiles integrados que se aplican en el nivel del namespace: Privileged (sin restricciones, para componentes del sistema), Baseline (impide escaladas de privilegios conocidas, como los contenedores privilegiados y el acceso a la red del host) y Restricted (reforzado; exige usuarios que no sean root, elimina todas las capacidades y aplica sistemas de archivos raíz de solo lectura). Los namespaces se etiquetan para aplicar un nivel de política, y los pods que lo infringen se rechazan durante la admisión.

Los Secrets de Kubernetes almacenan datos confidenciales, como contraseñas, tokens y certificados TLS. De forma predeterminada, los Secrets se almacenan en etcd como valores codificados en base64, no cifrados. Cualquiera que pueda leer etcd o tenga permisos RBAC suficientes puede decodificarlos fácilmente. Entre las prácticas recomendadas se incluyen: habilitar el cifrado en reposo de etcd mediante AES-GCM con una clave almacenada en un KMS (AWS KMS, GCP KMS), integrarlo con un gestor de secretos externo como HashiCorp Vault o AWS Secrets Manager mediante Secrets Store CSI Driver y restringir el acceso a los Secrets mediante RBAC para que solo puedan leerlos las cuentas de servicio que los necesiten.

Los controladores de admisión son plugins del servidor de API de Kubernetes que interceptan las solicitudes de la API después de la autenticación y la autorización, pero antes de guardar los objetos, lo que les permite validar, modificar o rechazar solicitudes. Entre los controladores de admisión relevantes para la seguridad se incluyen: PodSecurity (aplica los Pod Security Standards), ImagePolicyWebhook (permite verificar externamente la firma de imágenes), AlwaysPullImages (obliga a extraer imágenes nuevas para impedir el uso de imágenes maliciosas almacenadas localmente en caché) y OPA/Gatekeeper (Open Policy Agent; la opción más flexible, que permite expresar políticas personalizadas en el lenguaje Rego para aplicar cualquier regla de seguridad de la organización).

Reforzar los componentes del plano de control de Kubernetes es fundamental: el servidor de API debe tener --anonymous-auth=false para deshabilitar el acceso sin autenticación, --audit-log-path configurado para capturar toda la actividad de la API y TLS para todas las conexiones. El kubelet debe tener --authorization-mode=Webhook (no AlwaysAllow) y la autenticación anónima deshabilitada. etcd debe contar con cifrado TLS entre pares y para clientes, acceso de red restringido (solo debe ser accesible para el servidor de API) y cifrado de los datos en reposo. El CIS Kubernetes Benchmark proporciona una lista de comprobación exhaustiva para la configuración de todos los componentes.

Los namespaces de Kubernetes proporcionan una separación lógica de los recursos, pero por sí solos no constituyen un límite de seguridad sólido; principalmente ofrecen aislamiento organizativo. Para lograr un aislamiento real entre tenants (por ejemplo, las cargas de trabajo de distintos clientes), se necesitan controles adicionales: políticas de red para bloquear el tráfico entre namespaces, cuotas de recursos para evitar ataques de denegación de servicio causados por vecinos ruidosos, pools de nodos independientes para tenants con un aislamiento sólido o clústeres dedicados por tenant. Muchas organizaciones utilizan Hierarchical Namespaces o soluciones comerciales como vCluster para lograr una multitenencia más sólida dentro de un único clúster.

El registro de auditoría de Kubernetes registra cada solicitud a la API: quién la realizó, desde dónde, qué acción se solicitó y a qué recurso se dirigió. Los registros de auditoría son esenciales para la investigación forense después de un incidente de seguridad y para detectar comportamientos anómalos, como vinculaciones de roles inusuales, accesos a secretos o comandos exec en pods de producción. Los registros de auditoría deben enviarse por streaming a un SIEM centralizado. Falco proporciona supervisión del comportamiento de los contenedores, mientras que los servicios de Kubernetes gestionados en la nube (EKS, GKE, AKS) ofrecen integración nativa de los registros de auditoría con sus respectivas plataformas de registro.

La seguridad de la cadena de suministro para Kubernetes garantiza que solo las imágenes confiables y verificadas lleguen a producción. Las recomendaciones de la CNCF sobre seguridad de la cadena de suministro incluyen: verificar las firmas de las imágenes con Cosign antes de la implementación (aplicado mediante controladores de admisión), generar y verificar SBOM (listas de materiales de software) para todas las imágenes de contenedor con el fin de rastrear la procedencia de los componentes, fijar las imágenes a resúmenes criptográficos (myimage@sha256:abc123) en lugar de etiquetas mutables, y analizar todos los charts de Helm de terceros en busca de configuraciones incorrectas y vulnerabilidades antes de la implementación.

Compruebe su comprensión de los conceptos de CompTIA Security+ (SY0-701) tratados en esta lección.

En esta lección ha aprendido lo siguiente: Kubernetes RBAC controla el acceso a la API mediante Roles, ClusterRoles y Bindings; aplique siempre el principio de mínimo privilegio a las cuentas de servicio; las configuraciones de denegación predeterminada de NetworkPolicy evitan el movimiento lateral entre pods y espacios de nombres; y los Pod Security Standards aplican el fortalecimiento de los contenedores en el nivel del espacio de nombres, bloqueando los contenedores privilegiados, el acceso a la red del host y la ejecución como root. A continuación, exploraremos la seguridad sin servidor y las superficies de ataque a nivel de función.