Publicado en

Riesgo en Google Cloud: Cómo un archivo YAML de Kubernetes puede comprometer toda su organización

•Publicado enSeguridad en la Nube

El desafío de la gestión de credenciales en la nube

En el ecosistema actual de la nube, la gestión de credenciales es uno de los mayores dolores de cabeza para los equipos de TI. Tradicionalmente, los desarrolladores necesitaban claves de cuentas de servicio (archivos JSON) para crear bases de datos o máquinas virtuales. Sin embargo, estas claves suelen dispersarse, olvidarse en repositorios de código o quedar activas tras la salida de un empleado, creando lo que conocemos como secret sprawl.

Para solucionar esto, muchas empresas han adoptado el modelo GitOps a través de herramientas como el Google Kubernetes Config Connector (KCC). Este sistema permite a los desarrolladores describir los recursos de Google Cloud (GCP) mediante archivos de configuración YAML dentro de Kubernetes, delegando la creación real del recurso a un controlador con altos privilegios. Pero, como ha revelado una reciente investigación de Varonis, esta comodidad introduce un riesgo crítico de escalada de privilegios.

El problema del «Adjunto Confundido» (Confused Deputy)

El riesgo reside en una vulnerabilidad de diseño conocida como el problema del adjunto confundido. En este escenario, el KCC actúa como un intermediario con gran autoridad que obedece órdenes de usuarios con menor autoridad sin verificar si estos últimos tienen permiso real para ejecutar dicha acción en el destino final (Google Cloud).

El proceso funciona de la siguiente manera:

  1. Kubernetes RBAC: El sistema solo verifica si el usuario tiene permiso para crear un recurso YAML en un espacio de nombres (namespace) específico.
  2. Google Cloud IAM: Google Cloud solo verifica si la cuenta de servicio del KCC tiene permisos para realizar el cambio solicitado.

El fallo: Ninguno de los dos sistemas comprueba si el usuario original que envió el YAML tiene los permisos necesarios en Google Cloud para realizar esa operación específica.

ConfigConfusion: De usuario limitado a Dueño de la Organización

Un atacante que tenga acceso a un namespace de Kubernetes gestionado por KCC y permisos para crear recursos de tipo IAMPolicyMember puede, mediante un simple comando, asignarse a sí mismo el rol de roles/owner (propietario) a nivel de toda la organización de Google Cloud.

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: escalada-privilegios
spec:
  member: "serviceAccount:atacante@proyecto.iam.gserviceaccount.com"
  role: roles/owner
  resourceRef:
    kind: Organization
    external: "ID-DE-TU-ORGANIZACION"

Al aplicar este archivo, el KCC —que suele estar configurado con permisos de administrador para poder gestionar la infraestructura— procesa la solicitud y otorga el control total al atacante, quien ahora puede acceder a todos los datos, borrar infraestructuras o secuestrar la cuenta corporativa.

¿Cómo proteger su infraestructura?

Google ha señalado que este comportamiento es «por diseño», lo que traslada la responsabilidad de la seguridad a los administradores de la plataforma. Desde Intedya, recomendamos seguir esta lista de verificación para mitigar el riesgo:

  • Modo Namespaced: Configure KCC en modo de espacio de nombres, asignando una cuenta de servicio de Google distinta y con privilegios limitados para cada namespace de Kubernetes.
  • Principio de Menor Privilegio: Evite otorgar roles como roles/owner o roles/resourcemanager.organizationAdmin a la cuenta de servicio global de KCC a menos que sea estrictamente indispensable.
  • Restricción de Recursos IAM: Limite estrictamente quién puede crear recursos de tipo IAMPolicyMember, IAMPolicy y IAMPartialPolicy dentro del clúster.
  • Monitorización Activa: Implemente alertas para cualquier cambio en las políticas de IAM a nivel de organización o carpeta que sea originado por la cuenta de servicio de KCC.

La automatización de la infraestructura es vital para la agilidad empresarial, pero nunca debe comprometer la visibilidad de la cadena de autorización. Una configuración robusta y una auditoría constante son las únicas defensas eficaces contra este tipo de brechas silenciosas.

Fuentes