Endurecimiento de Kubernetes: una base práctica

Kubernetes se ha convertido en el plano de control predeterminado para las cargas de trabajo modernas y, con esa ubicuidad, también en un objetivo apetecible. Un clúster no es un único sistema, sino una colección distribuida de APIs, controladores, rutas de red e identidades, y cada una de esas capas puede configurarse mal de formas que amplían en silencio el radio de impacto de un solo contenedor comprometido. Este artículo expone una base práctica de endurecimiento para defensores e ingenieros de plataforma que operan clústeres en producción. El enfoque, de principio a fin, es entender para defender: describimos cómo surgen las debilidades, qué telemetría revela el abuso y qué controles reducen la superficie de ataque sin volver la plataforma imposible de operar.

Por qué importa una base de endurecimiento

Las instalaciones predeterminadas de Kubernetes optimizan la funcionalidad y la velocidad de desarrollo, no el mínimo privilegio. De fábrica puede encontrar tokens de cuenta de servicio montados de forma permisiva, contenedores que corren como root, ninguna política de red y un servidor de API alcanzable desde más lugares de los previstos. Nada de esto es un error; es un punto de partida que asume que usted aplicará sus propias barandillas. Una base ofrece una definición escrita y verificable de la postura mínima que todo clúster debe cumplir, de modo que la seguridad sea una propiedad de la plataforma y no algo que cada equipo reinventa. Sin ella, la deriva es inevitable y las auditorías se vuelven arqueología.

Una buena base es por capas. Cubre el plano de control, los nodos, las cargas de trabajo, la red, la cadena de suministro y las identidades que lo unen todo. Además se impone mediante maquinaria y no mediante buenas intenciones: el control de admisión, la política como código y el escaneo continuo de configuración convierten la base en algo que el clúster se niega a violar.

El plano de control y el servidor de API

El servidor de API es la puerta de entrada a todo. La autenticación anónima debe estar deshabilitada, y cada solicitud debe portar una identidad verificable respaldada por credenciales de corta vida. El registro de auditoría de kube-apiserver es su fuente de verdad más valiosa; actívelo con una política que registre metadatos para las lecturas y cuerpos completos de solicitud para las escrituras sobre recursos sensibles como secrets, roles y role bindings. Almacene esos registros fuera del clúster para que un atacante que aterrice dentro no pueda recortar sus propias huellas. Etcd, que guarda todo el estado del clúster incluidos los secrets, debe estar cifrado en reposo y ser alcanzable solo por el servidor de API mediante TLS mutuo.

Restrinja a nivel de red quién puede alcanzar el punto final de la API. Un plano de control gestionado con un punto final privado y una lista de redes autorizadas elimina una amplia franja del riesgo expuesto a internet. Los certificados deben rotar automáticamente, y la kubeconfig de administrador del clúster debe tratarse como una credencial de joya de la corona y no como un archivo que vive en portátiles.

Identidad de carga de trabajo y RBAC

El control de acceso basado en roles es donde la mayoría de los clústeres reales filtran privilegio. Los dos antipatrones que hay que cazar son los verbos o recursos comodín en un rol y los enlaces al rol integrado cluster-admin para personas o cuentas de servicio que no lo necesitan de verdad. Conceda el conjunto más estrecho de verbos sobre el conjunto más estrecho de recursos en el ámbito más estrecho, y prefiera roles con espacio de nombres frente a los de todo el clúster. Toda cuenta de servicio que pueda crear pods, leer secrets o modificar role bindings es en la práctica un camino hacia un control más amplio, porque esos verbos pueden encadenarse en escalada.

Deshabilite el montaje automático de tokens de cuenta de servicio de forma predeterminada y actívelo solo para cargas de trabajo que realmente llamen a la API. Donde una carga necesite permisos de nube, use la federación de identidad de carga de trabajo de la plataforma para que los pods reciban tokens de corta vida y de audiencia acotada en lugar de claves estáticas de larga vida incrustadas en secrets. Revise el RBAC de forma continua; un enlace razonable el trimestre pasado puede ser peligroso tras una reorganización de equipo.

Endurecer las propias cargas de trabajo

A nivel de pod, el objetivo es convertir un contenedor comprometido en un callejón sin salida en lugar de una rampa de lanzamiento. Ejecute como usuario no root con un sistema de archivos raíz de solo lectura, descarte todas las capacidades de Linux y añada de vuelta solo lo estrictamente necesario, y prohíba la escalada de privilegios con allowPrivilegeEscalation: false. Los contenedores privilegiados, el uso compartido de espacios de nombres del host (hostPID, hostNetwork, hostIPC) y los montajes de rutas del host son las funciones que más desean los atacantes, porque cada una erosiona la frontera entre el contenedor y el nodo. Trátelas como excepciones que requieren revisión explícita, no como valores predeterminados.

Aplique un perfil de seccomp como RuntimeDefault para acotar las llamadas al sistema que un contenedor puede emitir y, donde sus cargas lo toleren, sume AppArmor o SELinux por encima. Los Pod Security Standards le dan tres niveles nombrados —privileged, baseline y restricted— y el controlador integrado Pod Security Admission puede imponer el nivel restricted por espacio de nombres. Para reglas más ricas, un motor de políticas como Kyverno o un despliegue de OPA/Gatekeeper permite expresar e imponer restricciones específicas de la organización como código.

Segmentación de red

De forma predeterminada, todo pod puede hablar con cualquier otro, lo que significa que un solo punto de apoyo ve toda la superficie este-oeste. Una NetworkPolicy de denegación por defecto por espacio de nombres, seguida de reglas de permiso explícitas para los flujos que cada aplicación realmente necesita, es uno de los controles de mayor impacto que puede aplicar. Convierte el movimiento lateral de un salto trivial en una actividad que debe cruzar una frontera impuesta, y hace visibles las conexiones anómalas. Para garantías más fuertes, una malla de servicios puede añadir TLS mutuo entre servicios y autorización consciente de la identidad, de modo que una posición de red robada no equivalga a una identidad robada.

No olvide la salida. Restringir lo que los pods pueden alcanzar hacia afuera limita la exfiltración de datos y desafila el malware que llama a casa a un host de mando y control. Combine la política de red con el registro de DNS y de egreso para que los destinos salientes inesperados se vuelvan eventos detectables.

Detección: señales que revelan el abuso

El endurecimiento reduce la superficie de ataque; la detección le dice cuándo alguien tantea lo que queda. La señal más rica es el registro de auditoría de la API. Vigile las solicitudes para enumerar secrets a través de espacios de nombres, la creación o modificación de objetos ClusterRoleBinding, exec o attach dentro de pods en ejecución, y pods creados con ajustes privilegiados o de espacio de nombres del host. Una ráfaga súbita de respuestas 403 Forbidden de una sola cuenta de servicio a menudo significa que se robaron credenciales y se prueban contra recursos que nunca debieron tocar.

En tiempo de ejecución, un sensor de comportamiento como Falco o un agente EDR con conciencia de contenedores puede marcar un shell abierto dentro de un contenedor, un proceso inesperado que lee /etc/shadow, una escritura en una ruta normalmente de solo lectura o una conexión saliente a una dirección sospechosa. Correlacione los eventos del clúster con los registros a nivel de nodo y del proveedor de nube; un atacante que escapa al nodo o pivota al punto final de metadatos de la nube deja rastros en más de un lugar, y la correlación es lo que convierte el ruido aislado en una historia clara.

Errores comunes

Los equipos suelen enviar una política fuerte en un clúster de pruebas y luego conceden amplias excepciones en producción porque acechaba una fecha límite, y la excepción nunca se revisa. Otro error recurrente es imponer la seguridad de pods mientras se deja el servidor de API alcanzable desde cualquier parte, de modo que el muro más fuerte no tiene puerta. Secrets de extracción de imágenes demasiado amplios, secrets pasados como variables de entorno donde afloran en registros y volcados de fallo, y clústeres que nunca rotan credenciales son huecos comunes. Y desactivar el registro de auditoría por ruidoso cambia su mejor activo forense por un poco menos de almacenamiento: un trato que lamentará durante un incidente.

Una lista de verificación práctica

Use esto como base de partida y adáptelo a su riesgo. Plano de control: auth anónima apagada, auditoría activa y enviada fuera del clúster, etcd cifrado, punto final de API privado con lista de redes. Identidad: sin cluster-admin permanente, sin RBAC comodín, automontaje de tokens apagado por defecto, identidad de carga para acceso a la nube. Cargas: no root, sistema de archivos raíz de solo lectura, capacidades descartadas, sin escalada de privilegios, seccomp RuntimeDefault, Pod Security Admission restricted, sin espacios de nombres del host sin revisión. Red: denegación por defecto de entrada y salida por espacio de nombres, reglas de permiso explícitas, mTLS de malla donde sea factible. Cadena de suministro: imágenes firmadas, verificación en admisión, escaneo de vulnerabilidades como puerta. Detección: alertas del registro de auditoría, sensor de comportamiento en ejecución, retención de registros que sobreviva al tiempo de permanencia.

FAQ: ¿Basta Pod Security Admission por sí solo?

Es una base integrada y sólida para imponer el perfil restricted, y todo clúster debería usarlo. Pero está deliberadamente limitado a un conjunto fijo de controles a nivel de pod. Para reglas específicas de la organización —etiquetas requeridas, registries permitidos, verificación de firmas de imagen o cuotas de recursos atadas a política— querrá un motor de políticas general como Kyverno o Gatekeeper a su lado. Piense en Pod Security Admission como el suelo y en el motor de políticas como los muros que construye encima.

FAQ: ¿Cómo endurezco sin bloquear a los desarrolladores?

Empiece en un modo de auditoría o advertencia para que los equipos vean qué se bloquearía antes de que algo se rompa de verdad, y publique la base con una guía de remediación clara. Ofrezca caminos dorados —imágenes base endurecidas, procesos de exención listos y plantillas que ya cumplen las reglas— para que la opción segura sea también la fácil. La imposición aterriza con suavidad cuando el equipo de plataforma elimina fricción en lugar de limitarse a decir que no.

Conclusión

Una base de endurecimiento de Kubernetes no es un proyecto único, sino un contrato vivo entre la seguridad y los equipos que entregan sobre la plataforma. Cierre el plano de control, acote la identidad con RBAC de mínimo privilegio e identidad de carga, convierta los contenedores comprometidos en callejones sin salida, segmente la red por defecto, verifique su cadena de suministro e instrumente todo para que el abuso sea visible. Impóngalo con control de admisión y política como código para que la postura no derive en silencio. Bien hecho, el endurecimiento es invisible para quienes construyen sobre el clúster y decisivo contra quienes intentan irrumpir.