ConfigConnector permite que un YAML de Kubernetes tome control total de una organización GCP

Google Kubernetes Config Connector (KCC) permite declarar recursos de Google Cloud desde YAML en un clúster GKE. El controlador lee esos manifiestos y ejecuta las llamadas a la API de Cloud usando su propia cuenta de servicio, normalmente con permisos de nivel organizacional como roles/owner o roles/resourcemanager.organizationAdmin. La ventaja es que los desarrolladores ya no manejan claves de servicio, lo que elimina la propagación de secretos.

El problema surge cuando KCC actúa como un deputy confundido: no verifica si el usuario de Kubernetes que envía el manifiesto tiene permiso para solicitar la acción en Cloud. Un atacante que consiga acceso a un namespace observado por KCC y pueda crear recursos IAMPolicyMember puede inyectar un YAML como el siguiente:

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: escalation
  namespace: my-team
spec:
  member: "serviceAccount:attacker@attacker-project.iam.gserviceaccount.com"
  role: roles/owner
  resourceRef:
    apiVersion: resourcemanager.cnrm.cloud.google.com/v1beta1
    kind: Organization
    external: "123456789"

KCC procesa el recurso, llama a IAM y, al estar autorizado, otorga el rol owner al atacante. En la práctica, el atacante adquiere control total de la organización GCP sin nunca haber poseído una clave de servicio.

La vulnerabilidad, denominada ConfigConfusion, fue descrita por Justin O'Leary. El ataque explota la separación de dos sistemas de autorización: Kubernetes RBAC, que solo controla la creación del recurso dentro del clúster, y Google Cloud IAM, que solo verifica los permisos del servicio de KCC. Ninguno de los dos verifica la combinación completa, permitiendo que un usuario con privilegios limitados en Kubernetes realice acciones de nivel organizacional en Cloud.

Para mitigar el problema, los equipos deben aplicar controles de autorización cruzada, limitar los permisos del servicio de KCC a nivel de proyecto en lugar de organización, y habilitar auditorías que correlacionen eventos de Kubernetes con llamadas a la API de Cloud. También es recomendable usar políticas de least privilege y validar los manifiestos antes de que KCC los acepte.

Esta falla subraya la necesidad de revisar los modelos de confianza implícitos en arquitecturas GitOps donde la capa de orquestación actúa como intermediario con privilegios amplios. Sin una verificación integral, la comodidad de eliminar credenciales de desarrollador puede traducirse en una puerta de entrada a compromisos a gran escala.