Fundamentos de ciberseguridad para Kubernetes

Este artículo está orientado a personas o equipos responsables de la optimización y el gobierno de la arquitectura de Kubernetes, ya que proporciona una base sólida para comprender por qué Kubernetes es el objetivo de los actores de amenazas y cómo prevenir estos ataques. Nos centramos en algunas de las debilidades de seguridad más comunes que pueden estar presentes en el entorno Kubernetes y explicamos cómo remediarlas de forma inmediata.

¿Por qué atacan a Kubernetes?

Kubernetes es utilizado con frecuencia por los desarrolladores back-end, lo que permite prever que la persistencia de los ataques basados en esta tecnología continuará a medida que crezca dicho mercado. Los actores de amenazas, ya sean oportunistas o altamente motivados, comparten un interés por la eficiencia y el impacto. 

Al poner el foco en tecnologías consolidadas o de uso habitual, el coste del ataque y los recursos necesarios se reducen debido a la disponibilidad del objetivo, a los problemas de seguridad conocidos y a las técnicas apropiadas. Independientemente de los recursos, las habilidades o los motivos, para estos actores es simplemente lógico desde el punto de vista empresarial adoptar las mismas herramientas que sus víctimas.

La sofisticación de la arquitectura de Kubernetes también resulta atractiva para estos individuos y grupos porque ofrece una amplia superficie de ataque con numerosas oportunidades para acceder y exfiltrar datos confidenciales, destruir archivos clave, pivotar a sistemas conectados o realizar criptominería. La complejidad inherente de Kubernetes también conlleva que los errores sean frecuentes; las configuraciones erróneas constituyen la principal causa de vulnerabilidades en la nube. Esto, a su vez, fomenta el desarrollo de técnicas de ataque sofisticadas y más difíciles de detectar.

Estos son algunos ejemplos de vulnerabilidades y ataques que afectaban a tecnologías de contenedores y orquestación, específicamente en entornos de Kubernetes:

• Vulnerabilidad en AWS IAM Authenticator: permitía la escalada de privilegios en clústeres de Kubernetes. Esta falla fue remediada antes de que se registraran explotaciones conocidas en ambientes productivos.
• Malware Kinsing: explotaba imágenes de Kubernetes y contenedores de PostgreSQL vulnerables para infiltrarse y comprometer sistemas.
• Operación de cryptojacking de Dero: utilizaba DaemonSets para desplegar pods maliciosos en una campaña de minería de criptomonedas a gran escala, aprovechando los recursos del sistema infectado.

Ninguno de los mecanismos de seguridad integrados en Kubernetes está activo por defecto, lo que hace que sus clústeres, nodos y pods sean vulnerables por diseño. Esto implica que la responsabilidad de comprender e implementar adecuadamente los controles de seguridad recaiga en el usuario.

Errores comunes de configuración en Kubernetes

Controles de seguridad de pods inseguros

Los controladores de admisión y las herramientas de gestión de políticas pueden configurarse para limitar las capacidades de los contenedores asignadas a los pods dentro de un clúster. Sin estas restricciones, cualquier usuario con permiso para crear pods podría asignarles privilegios no justificados o capacidades excesivas. Este escenario proporcionaría a un actor de amenazas un vector de escape del contenedor («container escape»), permitiéndole:

• Acceder al nodo subyacente (host) y, en consecuencia, a información sensible como secretos, claves o datos de configuración.
• Escalar sus privilegios accediendo a las cuentas de servicio de cada pod alojado en el nodo.
• Aprovechar la configuración de Kubelet para hacerse pasar por el propio nodo, lo que comúnmente conduce a un compromiso total del clúster.

Incluso cuando no es posible una escalada directa de privilegios, los threat actors pueden intentar moverse lateralmente a la red del host, accediendo a puertos privilegiados, procesos o sistemas de archivos, o incluso a pods alojados en otros espacios de nombres, lo cual podría desencadenar más ataques.

Soluciones

Kubernetes admite varios controladores de admisión de seguridad, como el popular PodSecurity Admission Controller, y herramientas de gestión de políticas de terceros que pueden validar y controlar aspectos de seguridad en las especificaciones de los pods. Estas herramientas funcionan interceptando las solicitudes de creación de recursos enviadas al servidor API, y validando cada una frente a las especificaciones de seguridad predefinidas, como la restricción de acceso a procesos y volúmenes del host. Si una solicitud no cumple con estas especificaciones, se deniega, limitando así cualquier intento malicioso.

Cualquiera de estas soluciones puede implantarse y aplicarse en un clúster para proporcionar la protección necesaria. Una vez desplegado, el controlador necesitará ser configurado adecuadamente para ser efectivo. La mayoría de las herramientas de gestión de políticas en Kubernetes incluyen políticas integradas que pueden proporcionar un estándar de seguridad de referencia. No obstante, como medida de seguridad adicional, es crucial restringir proactivamente lo siguiente:

• Acceso a pods privilegiados.
• Uso de capacidades privilegiadas.
• Acceso a espacios de nombres y procesos del host.
• Acceso a montajes sensibles del sistema de archivos del host.
• Acceso raíz.
• Uso de redes y puertos del host.
• Acceso de escritura al sistema de archivos.
• Procedencia de la imagen, para garantizar que los pods solo se ejecuten con imágenes que utilizan una base aprobada y que han sido analizadas recientemente en busca de vulnerabilidades.

En el ámbito de controladores de admisión y herramientas de políticas de seguridad de pods de terceros, hay diversas opciones disponibles. Algunas de las más populares incluyen:

• Azure Policy para Azure Kubernetes Service (AKS): las políticas de Azure pueden activarse para asegurar que se apliquen las políticas de seguridad adecuadas a los recursos de Kubernetes. Estas políticas utilizan el webhook Gatekeeper para Open Policy Agent (OPA) con el fin de gestionar definiciones de políticas individuales y grupos de políticas (Initiatives).
• OPA/Gatekeeper: OPA es un controlador de políticas de código abierto para implementaciones en la nube que ofrece controles de seguridad para múltiples servicios cloud, incluido Kubernetes. Gatekeeper es la implementación específica para Kubernetes que permite la aplicación de políticas deseadas de manera activa.
• Kyverno: es un motor de políticas nativo de Kubernetes y de código abierto que facilita la gestión de políticas que se tratan como recursos de Kubernetes. Kyverno puede validar, mutar y generar recursos de Kubernetes y soporta integración con CI/CD para probar automáticamente las políticas y validar los recursos.

La supervisión y auditoría regulares de estos controles son fundamentales para mantener la protección de los pods a medida que evolucionen el entorno y las tecnologías. Es imprescindible revisar y actualizar periódicamente las políticas para incorporar las mejores prácticas y la información más reciente sobre vulnerabilidades. Además, cuando los pods requieran capacidades privilegiadas por razones legítimas, es esencial minimizar las excepciones a las políticas establecidas.

Más información

• Migración de seguridad de pods de Kubernetes.
• Admisión de seguridad de pods de Kubernetes
• Estándares de seguridad de pods de Kubernetes.
• Política de Microsoft Azure: plantillas para Kubernetes.
• Seguridad de pods con Kyverno.
• Seguridad de pods con OPA/Gatekeeper.

(Nota con respecto a las políticas de seguridad de pods de Kubernetes (PSP): las PSP eran el controlador de admisión de seguridad original incorporado en Kubernetes para hacer cumplir las normas de seguridad de los pods. Aunque seguían siendo completamente funcionales, se dejaron de utilizar a partir de Kubernetes v1.21 y se eliminaron en la versión v1.25. Se recomienda migrar cualquier configuración existente de PSP a otro controlador compatible).

Falta de políticas de red

Por defecto, Kubernetes establece una red plana en la que se permiten todas las conexiones de red entrantes y salientes. Esto posibilita que los pods se comuniquen entre sí y con otras entidades dentro del clúster, así como con internet público si existe una ruta externa disponible. En ausencia de políticas de red específicas, no existen restricciones sobre las comunicaciones dentro del clúster, lo que permite todo el tráfico de red hacia y desde los pods. Un actor de amenazas podría aprovechar esta configuración para comunicarse con aplicaciones y servicios, y utilizarlos para lanzar ataques contra el clúster y servicios relacionados. El acceso sin restricciones a internet también podría permitirles establecer canales de comando y control (C2), utilizando, por ejemplo, técnicas de servicios web para filtrar datos, mantener la persistencia e instalar software malicioso.

En entornos de cloud pública, las comunicaciones de red sin restricciones también pueden dar a los pods acceso a recursos dentro de la red virtual de la nube. Esto puede facilitar oportunidades de movimiento lateral y acceso a datos sensibles, incluyendo los servicios de metadatos de instancia.

Soluciones

Para restringir las comunicaciones de red, las políticas de red de Kubernetes pueden aplicarse a través de una interfaz de red de contenedores (CNI) compatible. Las políticas de red de Kubernetes son una implementación centrada en la aplicación que permite a los desarrolladores controlar el tráfico a nivel de IP/puerto por espacio de nombres. Si no se aplica ninguna  política de red de Kubernetes dentro de un espacio de nombres, se permite todo el tráfico de entrada y salida.

Es recomendable crear y aplicar políticas de red de Kubernetes para todos los espacios de nombres dentro del clúster. Una medida muy segura podría ser establecer una regla predeterminada que deniegue todas las comunicaciones de red de entrada y salida dentro de cada espacio de nombres. Posteriormente, se pueden aplicar conjuntos de reglas adicionales para permitir el tráfico legítimo necesario, dependiendo del caso de uso de cada pod y aplicación.

Las políticas de red de Kubernetes se pueden configurar para restringir el tráfico de red basándose en las siguientes designaciones:

• Pods que están permitidos.
• Espacios de nombres permitidos.
• Bloques IP (excepción: el tráfico hacia y desde el nodo donde se ejecuta un pod siempre está permitido, independientemente de la dirección IP).

Una vez que se aplica una política de red con un selector coincidente, los pods correspondientes rechazarán todo el tráfico que no esté explícitamente permitido. Dado que el orden de las políticas no es específico, todas las políticas aplicadas se evalúan conjuntamente, y el tráfico solo se permite si existe una regla que lo autorice. Para concretar más: para que se establezca una conexión entre un pod de origen y uno de destino, tanto la política de salida del pod de origen como la política de entrada del pod de destino deben permitir la conexión. Si alguna de las políticas, ya sea de salida o de entrada, no permite la conexión, entonces esta no se establecerá.

Más información

• Kubernetes: políticas de red.

Gestión insegura de secretos

Kubernetes requiere una distribución segura de secretos para permitir la comunicación de las aplicaciones con otros servicios; por ejemplo, una aplicación que solicita credenciales para autenticarse en una base de datos backend y ejecutar consultas. A menudo, este aspecto de seguridad se pasa por alto, ya sea por usar sistemas inadecuados o por un manejo incorrecto de los datos. Los secretos pueden quedar expuestos de múltiples maneras, tales como:

• Directamente dentro de un contenedor: cualquier persona con acceso al contenedor puede recuperar la información usando el comando ‘env’.
• En PodSpecs: cualquier usuario con permiso para obtener información sobre Pods/ReplicaSets/Deployments puede ver los pares de variables y valores dentro del PodSpec.
• En nodos: los usuarios con acceso al nodo anfitrión pueden inspeccionar los contenedores para extraer las variables de entorno.
• En soluciones de registro: por ejemplo, en Azure Monitor, las variables de entorno de los contenedores se pueden acceder a través de la función «Insights».
• Dentro del código de la aplicación, el código fuente, etc.

Soluciones

Como primera medida, los secretos deben eliminarse de todas las fuentes de datos en texto plano, como los PodSpecs y los ConfigMaps. Se debe implementar una solución dedicada a la gestión de secretos, y los valores de los secretos deben ser rotados regularmente para reducir la posibilidad de que una clave comprometida sea explotada. Esto ayudará a fortalecer la seguridad y reducir las vulnerabilidades en las operaciones de Kubernetes.

Secretos de Kubernetes

Los secretos de Kubernetes son un recurso integrado que ofrece un método eficaz para almacenar información sensible, separada de los pods y aplicaciones que dependen de ellos, lo que ayuda a reducir el riesgo de exposición de dicha información a través del flujo de trabajo de la aplicación. Para mejorar la protección de los secretos, se pueden utilizar configuraciones de control de acceso basado en roles (RBAC) que ofrecen un control de acceso más detallado. Sin embargo, es importante destacar que ni el cifrado ni la rotación de claves son características predeterminadas en los secretos de Kubernetes, por lo que es crucial implementar ambas para asegurar una protección adecuada.

Una limitación de los secretos de Kubernetes es que no permiten restringir el acceso a secretos individuales mediante asignaciones RBAC detalladas, de modo que cualquier persona con permiso para acceder a secretos puede hacerlo en todo el espacio de nombres o el clúster, según los permisos asignados. El acceso a secretos es un permiso de alto riesgo que frecuentemente conduce a movimiento lateral y escalada de privilegios, así como a la exposición de información altamente sensible. En situaciones donde se requieren controles más detallados, es recomendable considerar el uso de una herramienta de gestión de secretos dedicada de terceros.

Soluciones de gestión de secretos de terceros

Existen múltiples soluciones de gestión de secretos de terceros disponibles que ofrecen características de seguridad adicionales. Las opciones comunes incluyen:

• Nube nativa: cada plataforma proporciona su propia solución dedicada de gestión de secretos, como Azure Key Vault y AWS Secrets Manager. Estas soluciones almacenan y cifran los secretos dentro del entorno nativo de la nube, facilitando también la rotación automática de los valores secretos, la gestión del acceso a los secretos mediante políticas IAM y la posibilidad de realizar auditorías centralizadas.
• Herramientas de código abierto: en el ecosistema de Kubernetes se pueden implementar diversas herramientas dedicadas a la gestión de secretos que ofrecen funciones avanzadas como secretos dinámicos, espacios de nombres, arrendamientos y revocación de datos secretos. Entre los productos más utilizados se incluyen:
  • Hashicorp Vault.
  • CyberArk Conjur.
  • Lyft Confidant.
  • AquaSec.

Herramientas como Hashicorp Vault pueden implementarse como un sidecar, un contenedor independiente que se ubica y ejecuta junto al contenedor de aplicación principal dentro del mismo pod de Kubernetes. El contenedor sidecar es responsable de gestionar los secretos y transmitirlos de forma segura al contenedor de la aplicación principal según sea necesario. Esto mejora la seguridad de los secretos al separar la gestión de secretos de la aplicación principal, reduciendo así el riesgo de que los secretos queden expuestos o comprometidos.

Independientemente de la solución de gestión de secretos que se elija, los siguientes controles de seguridad son necesarios para proporcionar una protección adecuada y confiable:

• Aplicar una política de «necesidad de conocer», determinando exactamente qué aplicaciones contenedoras necesitan acceder a cada secreto individual, con el fin de minimizar el riesgo de exposición.
• Asegurar que los controles de acceso basados en roles (RBAC) sean robustos, de modo que solo las entidades restringidas y preaprobadas tengan autorización para acceder a los secretos.
• Cuando sea posible, aplicar la autenticación multifactor (MFA) y la gestión de credenciales justo a tiempo.
• Registrar y auditar periódicamente el acceso a los secretos, eliminando el acceso a las entidades si ya no son necesarias.
• Rotar y actualizar los secretos regularmente para reducir la ventana de oportunidad para que las credenciales comprometidas sean utilizadas de forma efectiva.

Uso del espacio de nombres predeterminado

Dentro de Kubernetes, los espacios de nombres son un mecanismo de seguridad que permite implementar límites de seguridad y aislar recursos dentro de un mismo clúster. La mayoría de las instancias de Kubernetes vienen con varios espacios de nombres predeterminados para desplegar recursos, incluidos “kube-system” (que aloja componentes del plano de control de Kubernetes), “kube-public” (para recursos públicos, cuyo uso generalmente se debe evitar) y “default”. Si no se especifica ningún espacio de nombres al programar recursos, Kubernetes utiliza el espacio de nombres “default” por defecto, lo que puede introducir riesgos debido a requisitos de seguridad contradictorios y a la falta de segregación efectiva. Si una aplicación o contenedor dentro del espacio de nombres “default” es comprometido, el actor de amenazas podría ser capaz de acceder a todos los demás recursos dentro de ese mismo espacio de nombres.

Soluciones

Para minimizar el impacto de las aplicaciones comprometidas y aprovechar al mismo tiempo controles de seguridad más detallados, se pueden crear espacios de nombres personalizados para segmentar los servicios en categorías aisladas según su caso de uso y requisitos de seguridad. El uso de espacios de nombres en Kubernetes, junto con un RBAC robusto, permite establecer límites de seguridad entre aplicaciones y equipos, apoyando una arquitectura multi-tenant. Esto posibilita que cada usuario, equipo o aplicación opere dentro de su propio espacio de nombres, aislado de los demás usuarios del clúster y funcione como si fuera la única entidad en él.

Como mejor práctica de seguridad de Kubernetes, el espacio de nombres predeterminado no debe utilizarse para alojar servicios y aplicaciones de contenedores.

Se recomienda implementar espacios de nombres personalizados para cada servicio de aplicación y/o equipo. Luego, los administradores deben aplicar políticas RBAC detalladas, utilizando roles y vinculaciones de roles que sigan el principio de mínimo privilegio (PoLP) para asegurar que las cuentas de servicio y los usuarios solo tengan acceso a los recursos dentro de su propio espacio de nombres.

Además, deben implementarse otros controles de seguridad para aislar el acceso a espacios de nombres individuales, incluyendo:

• Controles de seguridad de pods: mediante el uso del controlador de admisión de seguridad de pods (o plugins similares de terceros), se puede restringir el uso de normas de seguridad de pods a espacios de nombres individuales. Esto debería utilizarse para limitar aspectos sensibles de las especificaciones de los pods, basándose en los requisitos de seguridad de las implantaciones en cada espacio de nombres.
• Políticas de red: las políticas de red deben limitar las comunicaciones a nivel de red únicamente a los recursos dentro del espacio de nombres correspondiente. Cuando sea necesario acceder a otros espacios de nombres, deben implementarse asignaciones de red de mínimo privilegio para reducir la posibilidad de movimiento lateral entre espacios de nombres.
• Restricciones de nodo: pueden aplicarse taints y tolerations a nivel de espacio de nombres para limitar en qué nodos pueden colocarse los contenedores. Esto es cada vez más crucial en clústeres Kubernetes autoalojados para evitar que las aplicaciones se programen en nodos maestros que contengan recursos sensibles del plano de control. Los taints y tolerations pueden implementarse utilizando controladores de admisión, como PodNodeSelector o políticas personalizadas proporcionadas por plugins de políticas de terceros.
• Cuotas de recursos: imponen restricciones para limitar el consumo de recursos por espacio de nombres y pueden prevenir que los equipos de un espacio de nombres excedan los límites de recursos como CPU y memoria. El controlador de admisión LimitRanger o políticas personalizadas también pueden implementarse para aplicar valores predeterminados a los pods que no envíen requisitos de recursos.

Más información

• CheatSheet de OWASP: utiliza los espacios de nombres de Kubernetes para aislar adecuadamente tus recursos de Kubernetes.
• Práctica recomendada de seguridad en Kubernetes.

Uso de cuentas de servicio predeterminadas

Las cuentas de servicio de Kubernetes proporcionan identidades para los procesos que se ejecutan en un pod. Los ataques que explotan las cuentas de servicio predeterminadas se benefician de la manera en que estas se asignan dentro de un clúster. A continuación se describe este proceso de asignación:

• Cuando se crea un espacio de nombres, automáticamente se genera y asigna una cuenta de servicio predeterminada a ese espacio de nombres.
• Esta cuenta de servicio predeterminada se asignará a todos los pods dentro del espacio de nombres, a menos que se especifique explícitamente una cuenta de servicio alternativa.
• Cuando se asigna una cuenta de servicio a un pod, el token de la cuenta de servicio (un JSON Web Token (JWT) identificable) se monta automáticamente en el contenedor del pod para permitir la autenticación ante la API de Kubernetes y otros servicios.

Inicialmente, la cuenta de servicio por defecto tiene permisos mínimos. Sin embargo, si un pod que utiliza esta cuenta solicita privilegios adicionales, estos se asignarán a todos los pods que utilicen la misma cuenta de servicio predeterminada, lo que podría resultar en varios pods con privilegios excesivamente altos. Para un actor de amenazas, esto representa una oportunidad de comprometer tokens de cuentas con privilegios elevados, escapar del clúster, moverse lateralmente y realizar acciones en el propio host.

Soluciones

Es posible dejar de utilizar la cuenta de servicio predeterminada para los pods dentro de un clúster siguiendo estos pasos:

• Evaluar la sensibilidad de cada carga de trabajo: identifica qué cargas de trabajo contienen datos sensibles o realizan operaciones sensibles y clasifícalas en consecuencia.
• Crear cuentas de servicio personalizadas: para cada carga de trabajo, crea una cuenta de servicio única y utiliza el control de acceso basado en roles (RBAC) para asignar los permisos necesarios para acceder a los recursos requeridos.
• Asignar cuentas de servicio a los pods: asigna la cuenta de servicio adecuada a cada pod y aplícala mediante controladores de admisión cuando sea pertinente.
• Implementar controles de acceso: utiliza RBAC para implementar configuraciones basadas en el principio de mínimo privilegio (PoLP) diseñadas para limitar el acceso a cada pod y sus tokens.
• Supervisar y revisar: monitorea y revisa regularmente las cuentas de servicio y sus permisos asociados para asegurarte de que continúan siendo adecuados para las cargas de trabajo a las que están asignados.
• Eliminar los tokens de servicio innecesarios: si una aplicación no requiere acceso a la API de Kubernetes, configúrala para evitar que la cuenta de servicio se monte en sus respectivos pods, añadiendo una medida de protección adicional.

¿Eres vulnerable a ataques en Kubernetes?

La manera más efectiva de reducir el riesgo de ciberataques basados en Kubernetes es configurar adecuadamente el plano de control. Algunos investigadores anticipan que, para 2025, la mayoría de los fallos de seguridad en la nube provendrán de errores de configuración evitables. Por un lado, la dependencia de los administradores y usuarios en aplicar las mejores prácticas de seguridad en Kubernetes supone un gran margen para el error humano. Por otro lado, con una planificación y proceso adecuados, corregir errores de configuración puede tener costes mínimos y, al hacerlo uno mismo, se mantiene la autonomía sobre los entornos que se manejan a diario. 

Las evaluaciones de seguridad de Kubernetes son un tipo de penetration testing que identifica vulnerabilidades en un entorno de Kubernetes simulando diferentes ataques contra él. El objetivo de estas evaluaciones es poner a prueba la resiliencia del entorno mediante la identificación de debilidades que podrían ser explotadas por un actor de amenazas. Durante la evaluación, los consultores simulan varios escenarios de ataque que permiten a un threat actor apuntar a configuraciones erróneas para obtener acceso no autorizado al clúster de Kubernetes, contenedores o aplicaciones y determinar el impacto global de tales riesgos. Esto puede incluir pruebas para detectar vulnerabilidades en la infraestructura de Kubernetes, errores de configuración en los recursos y despliegues de Kubernetes, y vulnerabilidades en las imágenes de los contenedores o en el código de las aplicaciones.

El objetivo de cualquier esfuerzo de seguridad no debe ser eliminar toda posibilidad de ataque o llegar a ser «totalmente seguro». Con tecnologías de rápida evolución como Kubernetes, esto es simplemente imposible. En su lugar, es mejor centrarse en la reducción del riesgo en los escenarios de mayor probabilidad e impacto. Aquí es donde puede ser muy útil una evaluación de seguridad de Kubernetes bien planificada.

Si tienes alguna pregunta o necesitas más detalles, no dudes en contactar con nosotros o dejar un comentario.