Kubernetes Pivoting to Clouds
GCP
Si estás ejecutando un clúster k8s dentro de GCP, probablemente querrás que alguna aplicación en ejecución dentro del clúster tenga acceso a GCP. Hay 2 formas comunes de hacerlo:
Montar claves de GCP-SA como secreto
Una forma común de dar acceso a una aplicación de Kubernetes a GCP es:
Crear una Cuenta de Servicio de GCP
Asignar los permisos deseados a la cuenta
Descargar una clave json de la SA creada
Montarla como un secreto dentro de la cápsula
Establecer la variable de entorno GOOGLE_APPLICATION_CREDENTIALS apuntando al camino donde se encuentra el json.
Por lo tanto, como un atacante, si comprometes un contenedor dentro de una cápsula, debes verificar esa variable de entorno y archivos json con credenciales de GCP.
Relacionar json de GSA con secreto de KSA
Una forma de dar acceso a una GSA a un clúster de GKE es vinculándolos de la siguiente manera:
Crea una cuenta de servicio de Kubernetes en el mismo espacio de nombres que tu clúster de GKE utilizando el siguiente comando:
Crea un Secreto de Kubernetes que contenga las credenciales de la cuenta de servicio de GCP a la que deseas otorgar acceso al clúster de GKE. Puedes hacer esto utilizando la herramienta de línea de comandos
gcloud
, como se muestra en el siguiente ejemplo:
Vincula el Secreto de Kubernetes a la cuenta de servicio de Kubernetes usando el siguiente comando:
En el segundo paso se establecieron las credenciales de la GSA como secreto de la KSA. Entonces, si puedes leer ese secreto desde dentro del clúster GKE, puedes escalar a esa cuenta de servicio de GCP.
Identidad de Carga de Trabajo de GKE
Con la Identidad de Carga de Trabajo, podemos configurar una cuenta de servicio de Kubernetes para actuar como una cuenta de servicio de Google. Las pods que se ejecutan con la cuenta de servicio de Kubernetes se autenticarán automáticamente como la cuenta de servicio de Google al acceder a las API de Google Cloud.
Los primeros pasos para habilitar este comportamiento son habilitar la Identidad de Carga de Trabajo en GCP (pasos) y crear la cuenta de servicio de GCP que deseas que k8s impersone.
Habilitar la Identidad de Carga de Trabajo en un nuevo clúster
Crear/Actualizar un nuevo nodepool (Los clústeres de Autopilot no necesitan esto)
Crear la Cuenta de Servicio de GCP para hacerse pasar por desde K8s con permisos de GCP:
Conéctate al cluster y crea la cuenta de servicio a utilizar
Vincular el GSA con el KSA
Ejecute un pod con el KSA y verifique el acceso al GSA:
Verifique el siguiente comando para autenticarse en caso necesario:
Como atacante dentro de K8s, debes buscar SAs con la anotación iam.gke.io/gcp-service-account
ya que indica que el SA puede acceder a algo en GCP. Otra opción sería intentar abusar de cada KSA en el clúster y verificar si tiene acceso.
Desde GCP siempre es interesante enumerar los enlaces y saber a qué acceso estás dando a los SAs dentro de Kubernetes.
Este es un script para iterar fácilmente sobre todas las definiciones de los pods buscando esa anotación:
AWS
Kiam & Kube2IAM (IAM role for Pods)
Una forma (obsoleta) de asignar roles IAM a los Pods es utilizar un Kiam o un Kube2IAM servidor. Básicamente necesitarás ejecutar un daemonset en tu clúster con un tipo de rol IAM privilegiado. Este daemonset será el encargado de otorgar acceso a los roles IAM a los pods que lo necesiten.
En primer lugar, necesitas configurar qué roles pueden ser accedidos dentro del espacio de nombres, y lo haces con una anotación dentro del objeto de espacio de nombres:
Una vez que el espacio de nombres esté configurado con los roles IAM que los Pods pueden tener, puedes indicar el rol que deseas en cada definición de pod con algo como:
Como atacante, si encuentras estas anotaciones en pods o namespaces o un servidor kiam/kube2iam en ejecución (probablemente en kube-system) puedes hacerte pasar por cualquier rol que ya esté usado por los pods y más (si tienes acceso a la cuenta de AWS, enumera los roles).
Crear Pod con Rol IAM
El rol IAM a indicar debe estar en la misma cuenta de AWS que el rol kiam/kube2iam y ese rol debe poder acceder a él.
Rol de IAM para Cuentas de Servicio de K8s a través de OIDC
Este es el método recomendado por AWS.
En primer lugar, necesitas crear un proveedor OIDC para el clúster.
Luego creas un rol de IAM con los permisos que la SA requerirá.
Crea una relación de confianza entre el rol de IAM y la SA nombre (o los espacios de nombres que otorgan acceso al rol a todas las SAs del espacio de nombres). La relación de confianza verificará principalmente el nombre del proveedor OIDC, el nombre del espacio de nombres y el nombre de la SA.
Finalmente, crea una SA con una anotación que indique el ARN del rol, y los pods que se ejecuten con esa SA tendrán acceso al token del rol. El token está escrito dentro de un archivo y la ruta se especifica en
AWS_WEB_IDENTITY_TOKEN_FILE
(predeterminado:/var/run/secrets/eks.amazonaws.com/serviceaccount/token
)
Para obtener aws usando el token de /var/run/secrets/eks.amazonaws.com/serviceaccount/token
, ejecuta:
Como atacante, si puedes enumerar un clúster de K8s, verifica las cuentas de servicio con esa anotación para escalar a AWS. Para hacerlo, simplemente ejecuta/crea un pod utilizando una de las cuentas de servicio privilegiadas de IAM y roba el token.
Además, si estás dentro de un pod, verifica variables de entorno como AWS_ROLE_ARN y AWS_WEB_IDENTITY_TOKEN.
A veces la Política de Confianza de un rol puede estar mal configurada y en lugar de dar acceso AssumeRole a la cuenta de servicio esperada, lo da a todas las cuentas de servicio. Por lo tanto, si eres capaz de escribir una anotación en una cuenta de servicio controlada, puedes acceder al rol.
Consulta la siguiente página para más información:
Encontrar Pods y SAs con Roles de IAM en el Clúster
Este es un script para iterar fácilmente sobre todos los pods y definiciones de sas buscando esa anotación:
Rol IAM del Nodo
La sección anterior trataba sobre cómo robar Roles IAM con pods, pero ten en cuenta que un Nodo del clúster de K8s va a ser una instancia dentro de la nube. Esto significa que es altamente probable que el Nodo vaya a tener un nuevo rol IAM que puedes robar (nota que usualmente todos los nodos de un clúster de K8s tendrán el mismo rol IAM, por lo que puede que no valga la pena intentar verificar en cada nodo).
Sin embargo, hay un requisito importante para acceder al punto final de metadatos desde el nodo, necesitas estar en el nodo (¿sesión ssh?) o al menos tener la misma red:
Robar Token de Rol IAM
Anteriormente hemos discutido cómo adjuntar Roles IAM a Pods o incluso cómo escapar al Nodo para robar el Rol IAM que la instancia tiene adjunto a ella.
Puedes usar el siguiente script para robar las nuevas credenciales de rol IAM en las que has trabajado arduamente:
Referencias
Last updated