Seguridad de Kubernetes (Kubernetes security)

Un clúster es una API y un conjunto de controladores que hacen que la realidad se parezca a lo que dice esa API. Todo pasa por ahí: crear cargas de trabajo, leer secretos, cambiar permisos. Asegurar un clúster va, por tanto, sobre todo de quién puede llamar a esa API y qué le puede pedir.

El riesgo lo llevan cuatro capas. El plano de control, es decir, el servidor de API, el planificador, los controladores y el almacén de datos que guarda todos los objetos, secretos incluidos. Los permisos, expresados como control de acceso basado en roles, que es de grano fino y muy fácil de equivocar en la dirección de conceder de más. El aislamiento de las cargas, que es la frontera entre un contenedor y el nodo en el que corre, y que es mucho más débil de lo que casi todo el mundo supone. Y la cadena de suministro de imágenes, porque un clúster ejecuta lo que le dijeron que se descargara.

La propiedad que hace distintos a los clústeres frente a otras plataformas es que varios permisos de aspecto corriente equivalen al control total. El derecho a crear un pod es el derecho a ejecutar un contenedor en un nodo, montar una ruta del host y leer cualquier cosa que haya en ese nodo, incluidas las credenciales de otras cargas. El derecho a leer secretos en un espacio de nombres donde corre un componente privilegiado es el derecho a convertirse en él. A ninguno de los dos le llama administrador ninguna interfaz.

La identidad de las cargas viene de las cuentas de servicio, cuyos tokens se montan dentro de los pods. Cuando un clúster está federado con un proveedor de cloud, esa identidad se extiende hacia fuera, y un pod comprometido se convierte en un principal de cloud.

El hallazgo que más veces escribimos es un permiso que se lee como inofensivo. Una cuenta de servicio de integración continua con derecho a crear cargas en un espacio de nombres, de forma que cualquiera que pueda influir en una tubería puede ejecutar un contenedor privilegiado. Un rol de desarrollo que incluye poder ejecutar dentro de los pods, que es ejecución remota de código en todas las cargas de ese espacio de nombres. Un rol que puede crear enlaces de rol, que es el derecho a concederse a sí mismo lo que quiera. Ninguno parece administrador, y todos lo son.

El segundo es una configuración de carga que le regala el host al contenedor. Contenedores privilegiados, montajes de rutas del host, red del host, y capacidades que se añadieron para que algo funcionara y no se quitaron nunca. Un contenedor con el sistema de ficheros del host montado es un proceso en el nodo, y en ese caso el escape de contenedor no es un exploit, es copiar un fichero.

El tercero son los secretos. En un clúster por defecto, los objetos de secreto están codificados en base64 en el almacén de datos, no cifrados, así que el acceso de lectura a ese almacén, o a una copia de seguridad suya, es acceso de lectura a todos los secretos del clúster. Y los secretos montados en los pods los puede leer cualquiera que pueda ejecutar en el pod, lo que nos devuelve al modelo de permisos.

El cuarto es la red, donde lo que hay por defecto es que cada pod llega a todos los demás. Sin políticas, una sola carga comprometida alcanza el clúster entero, incluidos los endpoints internos de componentes que daban por hecho que nadie podía llamarlos. En los encargos, esto es lo que convierte una única aplicación vulnerable en un compromiso de clúster.

El quinto es la unión con el cloud. Un pod con una cuenta de servicio federada a un rol de cloud significa que un fallo de aplicación se convierte en una credencial de cloud. Es la misma cadena que un SSRF que llega a un endpoint de metadatos, y acaba en el mismo sitio.

Las conversaciones sobre seguridad de Kubernetes meten tres problemas distintos en una sola palabra. Tienen dueños distintos y herramientas distintas.

La razón para separarlos es que la mayoría de las organizaciones compran herramienta para el tercero, hacen algo del segundo a base de valores por defecto, y no miran nunca el primero, que es donde están las rutas a administrador del clúster.

Conceder permisos con comodín en un rol. Todos los verbos sobre todos los recursos es ser administrador con pasos de más.

Pasar por alto los verbos peligrosos. Crear pods, ejecutar dentro de pods, leer secretos, crear enlaces de rol y suplantar equivalen cada uno a bastante más de lo que aparentan.

Tratar un espacio de nombres como frontera de seguridad. Es un ámbito de nombres y de política. Sin política de red, control de admisión y grupos de nodos separados, no es aislamiento.

Dejar la red en permitir por defecto. Todos los clústeres empiezan planos. Alguien tiene que dejar de tenerlo plano.

Dar por hecho que un contenedor es un sandbox. Es un conjunto de namespaces del kernel y cgroups. Configurado a la ligera, es un proceso en el host con otra vista del sistema de ficheros.

Empieza por los permisos, porque ahí están los caminos más cortos. Calcula quién llega a qué a través de los enlaces de rol, cuentas de servicio incluidas, y enumera en concreto todos los principales que pueden crear pods, ejecutar dentro de pods, leer secretos o modificar enlaces. Esa lista debería ser corta y normalmente no lo es. Esto es el control de acceso basado en roles de Kubernetes revisado como grafo y no como un conjunto de manifiestos sueltos.

Aplica los estándares de carga por admisión y no por revisión. Una política que rechaza pods privilegiados, montajes de rutas del host y capacidades innecesarias en el momento de la admisión se está aplicando; una guía en una wiki no. Usa los pod security standards que trae el producto como línea base y un controlador de admisión para todo lo que vaya más allá.

Aplica política de red de denegación por defecto en cada espacio de nombres y abre lo que haga falta, que es la versión de clúster de la microsegmentación y es el cambio que más limita una carga comprometida.

Cifra los secretos en el almacén de datos, restringe el acceso al almacén y a sus copias de seguridad, y prefiere un gestor de secretos externo con credenciales de vida corta antes que objetos de secreto de larga duración. Desactiva el montaje automático de los tokens de cuenta de servicio donde la carga no llame a la API, que son la mayoría.

Para la detección, el registro de auditoría es la fuente de más valor y con frecuencia no se recoge. Alerta sobre la creación de pods con ajustes privilegiados, sobre la ejecución dentro de pods fuera de una ventana de cambio, sobre cambios en los enlaces de rol, y sobre lecturas de secretos por parte de principales que no suelen leerlos.

La evaluación de un clúster se escribe como alcanzabilidad desde una posición de partida y no como una lista de ajustes: desde un pod de aplicación comprometido, a qué se llega y hasta dónde llega. Ese planteamiento es lo que hace el informe accionable, porque el cliente ve qué política concreta rompe la cadena.

Dejamos anotado el permiso o la configuración que permitió cada paso, citado de los propios objetos del clúster para que el equipo de plataforma lo pueda verificar, junto con las entradas de auditoría que produjo nuestra actividad, lo que muchas veces revela que el registro no se estaba recogiendo.

La severidad va detrás del escape y de la unión. Una carga mal configurada sin salida de su espacio de nombres es un hallazgo moderado. Esa misma carga en un nodo donde además corren componentes privilegiados, en un clúster federado con una cuenta de cloud, es crítica porque el camino sigue más allá del clúster.

Los clústeres se evalúan como parte de probar un entorno cloud y lo que corre dentro, donde los hallazgos interesantes suelen cruzar la frontera entre los dos.

¿Es un contenedor una frontera de seguridad? Por defecto, no. Es un conjunto de namespaces del kernel y de control groups que comparten el kernel del host. Configurado con rigor es una frontera razonable; configurado con privilegios, montajes del host o capacidades de más, no es frontera en absoluto.

¿Cuál es el permiso más peligroso de Kubernetes? Crear pods es la respuesta habitual, porque permite ejecutar un contenedor que monta el host o que usa la identidad del nodo. Ejecutar dentro de pods, leer secretos y crear enlaces de rol van justo detrás, y ninguno de ellos está etiquetado como administrativo.

¿Los secretos de Kubernetes están cifrados? En un clúster por defecto están codificados en base64 en el almacén de datos, y eso no es cifrado. El cifrado en reposo de los secretos hay que configurarlo de forma explícita, y el acceso al almacén y a sus copias de seguridad hay que restringirlo en consecuencia.

¿Un service mesh asegura el clúster? Asegura el tráfico entre servicios, que es valioso, y cubre una capa. No hace nada con los permisos demasiado amplios, con las cargas privilegiadas ni con la cadena de suministro de imágenes.