13. Seguridad en Kubernetes: arquitectura, API server, etcd, RBAC y namespaces

13.1 Introducción

Kubernetes es una plataforma de orquestación para ejecutar contenedores en clusters. Automatiza despliegues, escalado, recuperación, networking y configuración de aplicaciones distribuidas.

Desde seguridad, Kubernetes es un plano de control poderoso. Quien obtiene permisos suficientes sobre la API puede crear pods, leer secretos, montar volúmenes, modificar despliegues, exponer servicios o moverse entre namespaces.

Por eso la seguridad de Kubernetes empieza por comprender sus componentes principales y los límites reales que ofrece.

13.2 Arquitectura general

Un cluster Kubernetes se divide en plano de control y nodos de trabajo. El plano de control decide el estado deseado; los nodos ejecutan los workloads.

13.3 API server

El API server es la entrada principal al cluster. Todas las operaciones relevantes pasan por él: crear pods, consultar secretos, modificar roles, aplicar manifiestos o leer eventos.

Su protección debe contemplar:

• Autenticación fuerte e integrada con identidad corporativa.
• Autorización mediante RBAC y mínimo privilegio.
• Auditoría de operaciones sensibles.
• Acceso de red restringido al endpoint de administración.
• Protección contra uso de credenciales antiguas o kubeconfigs filtrados.
• Admission control para validar objetos antes de aceptarlos.

13.4 etcd

etcd almacena el estado del cluster. Contiene objetos, configuraciones y secretos. Si etcd se expone o se accede sin autorización, el atacante puede leer o alterar información crítica.

Controles importantes:

• No exponer etcd a redes no confiables.
• Usar TLS para comunicación con componentes autorizados.
• Habilitar cifrado de secretos en reposo.
• Proteger backups de etcd como datos sensibles.
• Limitar acceso administrativo a operadores autorizados.
• Monitorear cambios y errores relacionados con el datastore.

13.5 Nodos y kubelet

Los nodos ejecutan pods. El kubelet recibe instrucciones del plano de control y coordina con el runtime de contenedores. Si un nodo se compromete, los pods que ejecuta y sus credenciales pueden quedar expuestos.

Riesgos habituales:

• Kubelet expuesto sin autenticación o autorización adecuada.
• Nodos con parches pendientes.
• Credenciales de pods accesibles desde el filesystem del nodo.
• Contenedores privilegiados con acceso al host.
• Permisos cloud del nodo demasiado amplios.
• Falta de separación entre workloads de distinta sensibilidad.

13.6 Pods, deployments y servicios

Un pod es la unidad mínima de ejecución en Kubernetes. Un deployment administra réplicas y actualizaciones. Un service proporciona una forma estable de acceder a pods.

13.7 Namespaces

Los namespaces organizan recursos dentro del cluster. Ayudan a separar equipos, aplicaciones o ambientes, pero no son por sí solos un límite fuerte de seguridad.

Un namespace puede servir para:

• Agrupar recursos de una aplicación o equipo.
• Aplicar RBAC específico.
• Definir cuotas y límites de recursos.
• Aplicar políticas de red.
• Separar configuraciones y secretos por contexto.

Para que la separación sea efectiva, el namespace debe combinarse con RBAC, network policies, resource quotas y políticas de admisión.

13.8 RBAC

RBAC controla qué acciones pueden realizar usuarios, grupos y service accounts sobre recursos Kubernetes. Es uno de los mecanismos más importantes para aplicar mínimo privilegio.

Conceptos base:

• Role: permisos dentro de un namespace.
• ClusterRole: permisos a nivel de cluster o reutilizables en namespaces.
• RoleBinding: asigna un Role o ClusterRole dentro de un namespace.
• ClusterRoleBinding: asigna permisos a nivel de todo el cluster.
• Verbs: acciones como get, list, watch, create, update, delete o patch.

13.9 Service accounts

Las service accounts son identidades usadas por pods y controladores dentro del cluster. Si un pod se compromete, el atacante puede intentar usar el token de su service account para consultar o modificar recursos.

Buenas prácticas:

• Crear service accounts específicas por aplicación.
• Evitar usar la service account default para workloads.
• Asignar permisos mínimos y por namespace.
• Deshabilitar montaje automático de tokens si no se necesitan.
• Revisar qué service accounts pueden leer secretos o crear pods.
• Usar identidades de workload para acceso cloud cuando corresponda.

13.10 Secretos en Kubernetes

Kubernetes permite almacenar secretos como objetos. Sin embargo, un Secret no debe interpretarse como protección completa. Su seguridad depende de cifrado, RBAC, auditoría y forma de entrega al pod.

Riesgos frecuentes:

• Roles con permiso amplio para leer secretos.
• Secretos sin cifrado en etcd.
• Secretos montados en pods que no los necesitan.
• Secretos replicados entre namespaces sin control.
• Valores sensibles incluidos en manifiestos versionados.
• Falta de rotación y auditoría de acceso.

13.11 Seguridad de red dentro del cluster

Por defecto, muchos clusters permiten comunicación amplia entre pods. Esto facilita operación, pero también movimiento lateral si un workload se compromete.

Medidas base:

• Aplicar network policies por namespace y aplicación.
• Permitir solo flujos necesarios entre servicios.
• Separar workloads públicos, internos y de datos.
• Controlar tráfico de egreso desde pods.
• Monitorear conexiones anómalas entre namespaces.

13.12 Kubernetes administrado

En servicios administrados, el proveedor gestiona parte del plano de control. Eso reduce carga operativa, pero no elimina responsabilidades del cliente.

13.13 Auditoría y eventos

La auditoría permite investigar acciones sobre el cluster. Sin registros, es difícil saber quién creó un pod, leyó un secreto, modificó un role binding o expuso un servicio.

Eventos relevantes:

• Lectura de secretos y configmaps sensibles.
• Creación de pods privilegiados.
• Cambios en RBAC.
• Creación de service accounts y tokens.
• Modificación de ingress, services y network policies.
• Uso de imágenes no aprobadas.
• Accesos fallidos o anómalos al API server.

13.14 Errores frecuentes

• Usar cluster-admin para tareas que requieren permisos limitados.
• Permitir que todos los namespaces se comuniquen sin restricciones.
• Usar la service account default en workloads.
• No cifrar secretos en etcd.
• Exponer el API server a redes amplias sin controles.
• No auditar cambios en RBAC.
• Ejecutar contenedores privilegiados sin justificación.
• Confiar en namespaces como único mecanismo de aislamiento.

13.15 Lista de verificación

• ¿El API server está restringido y auditado?
• ¿Los secretos en etcd están cifrados?
• ¿RBAC aplica mínimo privilegio por equipo, namespace y aplicación?
• ¿Existen pocos ClusterRoleBinding y todos tienen justificación?
• ¿Los workloads usan service accounts específicas?
• ¿Los namespaces tienen cuotas, límites y políticas de red?
• ¿Los nodos y runtimes están actualizados?
• ¿Se registran cambios de RBAC, secretos, ingress y pods privilegiados?

13.16 Qué debes recordar de este tema

• El API server es el punto central de control del cluster.
• etcd contiene estado y secretos; debe protegerse como activo crítico.
• RBAC mal diseñado puede dar acceso excesivo a usuarios, pods o pipelines.
• Los namespaces organizan recursos, pero necesitan políticas adicionales para aislar.
• Las service accounts deben tratarse como identidades privilegiadas de workloads.

13.17 Conclusión

La seguridad en Kubernetes depende de controlar su plano de control, proteger etcd, aplicar RBAC con mínimo privilegio, aislar namespaces y auditar cambios críticos. Estos elementos son la base antes de avanzar hacia hardening de workloads y políticas de admisión.

En el próximo tema estudiaremos hardening de Kubernetes: Pod Security, admission control, network policies y runtime security.