Pwning Kubernetes

Feb 02 2023

Escrito por: Yu Pengfei, Mah Chia Hui Introducción El crecimiento explosivo del uso de Kubernetes durante la última década fue un gran espectáculo. Sin embargo, Rome no se construyó en un día y, al igual que cualquier otra pila de tecnología importante en uso hoy en día, la tecnología de contenedores tardó varias décadas en madurar antes de que Kubernetes se presentara como la mejor articulación en su etapa actual.

Escrito por: Yu Pengfei , Mah Chia Hui

Introducción

El crecimiento explosivo del uso de Kubernetes durante la última década fue un gran espectáculo. Sin embargo, Rome no se construyó en un día y, al igual que cualquier otra pila de tecnología importante en uso hoy en día, la tecnología de contenedores tardó varias décadas en madurar antes de que Kubernetes se presentara como la mejor articulación en su etapa actual.

A medida que se almacenan más aplicaciones en contenedores, los motores de orquestación como Kubernetes se han vuelto extremadamente populares. Como motor de orquestación, Kubernetes ayuda a administrar, escalar e implementar aplicaciones en contenedores. Dicho esto, hay toneladas de motores de orquestación diferentes (como Docker Swarm); entonces, ¿por qué Kubernetes sigue siendo tan popular? Una respuesta rápida radica en que Kubernetes es rico en funciones, repleto de capacidades como la reparación automática y el escalado automático. Además de eso, la mayoría de los proveedores de servicios en la nube (CSP) implementan Kubernetes como un servicio administrado. Esto consolida su posición como el "estándar de oro" para los motores de orquestación. La adopción de Kubernetes sigue creciendo, con el 96 % de las organizaciones usando o evaluando Kubernetes. (https://thenewstack.io/is-kubernetes-adoption-slowing/)

Problemas de Mo' Honey Mo'

Con el uso generalizado de Kubernetes, no sorprende que también sea una superficie de ataque preciada que los atacantes intentan detectar y explotar activamente. Con su ascenso novedoso, los desarrolladores también cometen errores en su implementación, configuración o despliegue.

Este artículo es el primero de nuestra serie sobre la seguridad de Kubernetes. Proporcionará una descripción general de algunos ataques comunes y las mejores prácticas de seguridad básicas para Kubernetes. Los artículos posteriores profundizarán en ataques más complejos, como HostPath Mounting, pods/nodos de trampolín, etc., y sus soluciones.

Para entender los ataques, primero debemos entender la arquitectura de Kubernetes, el siguiente diagrama de alto nivel es un buen punto de partida. Siéntase libre de pasar a "Metodología de ataque" si ya está familiarizado con la arquitectura de Kubernetes y sus fundamentos.

Diagrama de arquitectura de Kubernetes

vainas

Kubernetes se compone de muchas partes móviles, y su unidad de trabajo más baja se conoce como POD . Un pod puede albergar varios contenedores y volúmenes de almacenamiento diferentes. Cada pod también tiene su dirección IP única. También es ultraescalable, ya que se basa en planos de implementación (archivo yaml).

Nodos

Para simplificar las cosas para todos, solo desglosaremos el tipo de nodos para:

● Nodos trabajadores

● Nodo principal

Un conjunto de nodos forma un clúster.

Nodos trabajadores:

Los pods residen en estos nodos trabajadores que pueden ser máquinas virtuales o físicas. Puede pensar en ellos como máquinas anfitrionas para pods.

Nodo maestro:

Un Master Node es el administrador final de todo el clúster. Controla y administra todos los nodos trabajadores, que incluyen los siguientes componentes: servidor Kube-API, Kube-Controller-Manager, Kube Scheduler, etc.

espacio de nombres

Un espacio de nombres de Kubernetes es un mecanismo de aislamiento que aísla recursos dentro de un clúster, generalmente usado cuando diferentes equipos están trabajando en el mismo clúster. En el contexto de la ciberseguridad, cada objeto/recurso de espacio de nombres es exclusivo del espacio de nombres. La invocación de objetos/recursos entre espacios de nombres es imposible ya que estos objetos/recursos están aislados dentro de sus espacios de nombres.

Ahora, con todo este nuevo conocimiento, debe tener una comprensión fundamental del entorno de Kubernetes. Pasemos al lado más jugoso de las cosas, ¿cómo se ataca a Kubernetes?

Metodología de ataque

La metodología de un atacante sofisticado se puede dividir en tres etapas.

Etapa 1: punto de apoyo inicial

La forma principal de obtener un punto de apoyo inicial es comprometer una aplicación web o un microservicio alojado en el clúster. El objetivo del atacante es lograr la ejecución remota de código en la aplicación enumerando la aplicación e identificando las vulnerabilidades explotables (p. ej., log4shell, apache struts).

Etapa 2: Escalada de privilegios

Al afianzarse en el clúster de Kubernetes, un atacante estaría dentro de una cápsula que, como se explicó, es simplemente un contenedor acoplable. Un atacante podría olfatear el contenedor en busca de datos confidenciales, pero se limita a lo que está disponible. . Como tal, el atacante buscará escalar a un pod con más privilegios o a un nodo.

Las siguientes son algunas técnicas comunes que emplearía un atacante:

Archivos confidenciales

Remediación:

Además de la práctica estándar de no dejar credenciales confidenciales sin cifrar en un pod, un administrador de Kubernetes debe adherirse a los principios de privilegio mínimo al otorgar privilegios al token de la cuenta de servicio.

Aplicaciones accesibles

Remediación:

Para administrar qué pods, espacios de nombres o incluso servidores externos pueden llegar a un recurso de Kubernetes en particular, un administrador de Kubernetes puede usar el recurso de política de red de Kubernetes .

Servicios de metadatos en la nube

Remediación:

El administrador de Kubernetes puede utilizar el recurso de política de red de Kubernetes antes mencionado para evitar que un atacante acceda a la API de metadatos de la nube y a otras aplicaciones alojadas en el clúster que no son necesarias para las funciones comerciales principales.

ruptura de la vaina

Remediación:

El administrador de Kubernetes puede utilizar el recurso del controlador de admisión, un recurso de Kubernetes que valida cada recurso que se crea en el clúster de Kubernetes mediante un conjunto de reglas definido. Un recurso que no cumpla con el conjunto de reglas definido no se creará, lo que generará un error.

Etapa 3: Obtener las joyas de la corona

En el ecosistema de Kubernetes, las joyas de la corona hacen referencia al nodo maestro. Un atacante que haya obtenido acceso completo al nodo maestro esencialmente tendría el control completo del clúster de Kubernetes. El atacante repetiría las técnicas detalladas en las etapas 1 y 2, para moverse lateralmente desde un pod infectado al nodo subyacente y finalmente al nodo maestro. Para evitar que ocurra el peor de los casos, un administrador de Kubernetes debe asegurarse de que el clúster esté configurado de forma segura con algunas de las soluciones mencionadas anteriormente.

¿Eso es todo?

Para obtener una visión más completa de la postura de seguridad de Kubernetes de su organización, le recomendamos que utilice la matriz de ataque de Kubernetes de Microsoft. La matriz comprende las principales tácticas que son relevantes para la seguridad de Kubernetes. Cada uno de ellos contiene varias técnicas que los atacantes pueden usar para lograr diferentes objetivos.

Conclusión

A medida que más organizaciones adopten Kubernetes como la herramienta de facto para administrar la orquestación de contenedores, más datos confidenciales terminarán en los clústeres de Kubernetes. Hay una necesidad aún mayor de administradores de sistemas que buscan configurar su clúster para configurarlo de forma segura. Un atacante con acceso total al nodo maestro de un clúster de Kubernetes es lo último que querría ver un CISO.