¿Cómo hackear clústeres y nodos de Kubernetes a través de etcd?

Kubernetes se ha convertido en la plataforma de orquestación de facto para gestionar aplicaciones en contenedores, pero con su adopción generalizada, la seguridad de los clústeres de Kubernetes ha sido objeto de un mayor escrutinio. Un elemento central de la arquitectura de Kubernetes es etcd, un almacén clave-valor de alta disponibilidad que se utiliza para conservar el estado del clúster y sus detalles de configuración. Si bien etcdes esencial para la funcionalidad del clúster de Kubernetes , también presenta un objetivo tentador para los atacantes. Una nueva investigación muestra cómo una situación comprometida etcdpuede conducir a un control total sobre el clúster, permitiendo cambios no autorizados en los recursos, alterando las operaciones y potencialmente provocando violaciones de datos o interrupciones del servicio. La arquitectura de Kubernetes se divide en dos partes principales: el plano de control y los nodos. El plano de control actúa como eje central e incluye componentes como kube-apiserver (el cerebro del clúster), programador (que asigna pods a nodos), administrador de control (que gestiona el estado de varios elementos del clúster) y etcd ( un almacén de valores clave para datos del clúster). Los nodos contienen componentes como kubelet (que garantiza que los pods se ejecuten correctamente) y kube-proxy (que conecta los servicios a la red).

Etcd es más que un simple componente de almacenamiento en Kubernetes; Es una parte crítica de la arquitectura. Es una base de datos clave-valor que almacena toda la información del clúster. Los datos en etcd se almacenan utilizando un formato de serialización llamado Protobuf, desarrollado por Google para el intercambio de datos eficiente entre sistemas. Kubernetes utiliza Protobuf para serializar diferentes tipos de datos, como pods y roles, cada uno de los cuales requiere diferentes parámetros y definiciones.

La investigación describe una herramienta llamada auger, que puede serializar y deserializar datos almacenados en etcd en formatos más legibles como YAML y JSON. NCC Group ha desarrollado un contenedor para auger llamado kubetcd para mostrar cómo un etcd comprometido puede ser crítico.

LAS 8 MEJORES HERRAMIENTAS GRATUITAS PARA PRUEBAS DE SEGURIDAD Y AUDITORÍA DE SU CLUSTER DE KUBERNETES EN 2022

Sin embargo, explotar etcd tiene limitaciones. Necesitaría acceso de root al host que ejecuta etcd y tener los certificados necesarios para la autenticación. Además, esta técnica se aplica principalmente a entornos Kubernetes autoadministrados, no a los administrados que ofrecen los proveedores de la nube.

Cómo hackear pods de Kubernetes y ejecutar código malicioso de forma remota

El acceso directo a etcd podría usarse para alterar los recursos de Kubernetes, como cambiar la fecha de inicio de un pod o crear inconsistencias que dificulten la administración de los pods.

El acceso directo a etcd, el almacén clave-valor de Kubernetes, podría permitir a un atacante realizar modificaciones no autorizadas en el estado del clúster, lo que podría provocar diversos problemas de seguridad. Aquí hay algunos ejemplos de cómo esto podría explotarse:

Cambiar las marcas de tiempo del pod :

• Los atacantes con acceso etcdpodrían alterar las marcas de tiempo de creación de los pods. Esto podría usarse para disfrazar pods maliciosos como procesos confiables y de larga duración.
• Ejemplo:
  bash kubetcd create pod nginx -t nginx --time 2000-01-31T00:00:00Z
  este comando establece la marca de tiempo de un pod nginx al 31 de enero de 2000, haciendo que parezca como si hubiera estado ejecutándose durante más de 20 años.

Ganando persistencia :

• Al cambiar la ruta donde se almacenan los datos de un pod etcd, un atacante podría evitar que los comandos normales de la API de Kubernetes eliminen el pod.
• Ejemplo:
  bash kubetcd create pod maliciouspod -t nginx -p randomentry
  este comando crea un pod y almacena sus datos en una ruta diferente, lo que dificulta que Kubernetes lo administre o elimine.

Creando Pods semi-ocultos :

• Los atacantes podrían manipular las entradas del espacio de nombres etcdpara ejecutar pods en un espacio de nombres que no coincida con su manifiesto. Esto puede causar confusión y dificultar el manejo de los grupos.
• Ejemplo:
  bash kubetcd create pod hiddenpod -t nginx -n invisible --fake-ns
  este comando crea un pod que parece ejecutarse en el defaultespacio de nombres pero que en realidad está asociado con el invisibleespacio de nombres en etcd. Este pod no aparecerá en el espacio de nombres predeterminado, lo que lo hará semi-oculto.

Sin pasar por los controladores de admisión :

• Los controladores de admisión hacen cumplir las políticas de seguridad en Kubernetes. Al inyectar recursos directamente en etcd, un atacante puede eludir estos controles e implementar pods privilegiados que podrían comprometer el clúster.
• Ejemplo:
  bash kubetcd create pod privilegedpod -t nginx -n restricted-ns -P
  este comando inyecta un pod privilegiado en un espacio de nombres que se supone está restringido por las políticas de admisión de seguridad del pod (PSA).

Manipulación de funciones de clúster y vinculaciones de funciones :

• Los atacantes pueden modificar roles y vinculaciones de roles directamente etcdpara escalar privilegios.
• Ejemplo:
  bash kubetcd modify rolebinding admin-binding --clusterrole=cluster-admin --user=attacker
  este comando hipotético cambia un enlace de rol para otorgar al attackerusuario privilegios de administrador del clúster.

Estos ejemplos muestran los peligros potenciales si un atacante obtiene acceso directo a etcd. Pueden realizar cambios que no están sujetos a los controles y equilibrios habituales de la API de Kubernetes, lo que lleva a un control no autorizado sobre los recursos del clúster. Por este motivo, asegurar etcdel acceso es fundamental en un entorno de Kubernetes.

Mitigación

Para mitigar los riesgos asociados etcdy prevenir los tipos de manipulación mencionados anteriormente, se deben implementar varios pasos y mejores prácticas:

Control de acceso :

• Restrinja el acceso etcdmediante la implementación de mecanismos sólidos de autenticación y autorización. Utilice certificados de cliente TLS para proteger la comunicación con etcd.
• Rote periódicamente etcdlas credenciales de acceso y audite los registros de acceso para detectar intentos de acceso no autorizados.

Políticas de red :

• Limite el acceso a la red a etcdlos servidores, asegurándose de que solo componentes específicos y autorizados puedan comunicarse con etcd.
• Implemente reglas de firewall o políticas de red de Kubernetes para controlar el tráfico hacia etcdlos servidores.

Cifrado etcd :

• Habilite el cifrado en reposo para etcdproteger datos confidenciales. Incluso si los atacantes obtienen acceso físico al etcdalmacenamiento, no deberían poder leer los datos sin las claves de cifrado.

Copias de seguridad periódicas :

• Haga una copia de seguridad periódica del etcdalmacén de datos. En caso de una infracción, esto permite restaurar el clúster a un buen estado conocido.
• Garantice la integridad de las copias de seguridad verificándolas y probándolas periódicamente.

Seguimiento y Auditoría :

• Implemente monitoreo para detectar actividades anormales, como cambios inesperados en etcd.
• Utilice herramientas como las capacidades de auditoría integradas de etcd, Falco u otros sistemas de detección de intrusiones para alertar sobre comportamientos sospechosos.

Principio de privilegio mínimo :

• Aplicar el principio de privilegio mínimo para el etcdacceso. Asegúrese de que solo los componentes necesarios tengan el nivel de acceso mínimo requerido para realizar sus funciones.

Gestión de parches :

• Actualice periódicamente etcda la última versión para mitigar las vulnerabilidades causadas por defectos de software.

Controladores de admisión :

• Utilice controladores de admisión como OPA Gatekeeper o Kyverno para definir y aplicar políticas que puedan ayudar a prevenir la creación de recursos no autorizados dentro de Kubernetes.

Contextos y políticas de seguridad :

• Aplique contextos de seguridad y políticas de seguridad de pods (o sus sucesoras, como Admisión de seguridad de pods) para aplicar configuraciones relacionadas con la seguridad en pods y evitar la escalada de privilegios.

Plan de recuperación de desastres :

• Tenga un plan de recuperación ante desastres en caso de que etcdse vea comprometido. Este plan debe incluir pasos para aislar los sistemas afectados, revocar las credenciales comprometidas y restaurar a partir de copias de seguridad.

Educación y formación :

• Capacite al equipo de operaciones para que comprenda los riesgos de seguridad asociados con etcdKubernetes y cómo aplicar las mejores prácticas para proteger el clúster.

Al implementar estas mitigaciones, las organizaciones pueden reducir significativamente el riesgo de acceso no autorizado y manipulación etcd, protegiendo así sus clústeres de Kubernetes. Mitigar los riesgos asociados etcd garantiza la integridad y confiabilidad de los clústeres de Kubernetes. Al implementar las mejores prácticas de seguridad de la industria y mantener una postura proactiva ante posibles vulnerabilidades, las organizaciones pueden implementar y administrar con confianza sus cargas de trabajo en contenedores, manteniéndolas seguras en un panorama de amenazas en constante evolución.