Cómo un único archivo YAML de Kubernetes puede transferir una organización de GCP
Para evitar el problema de dispersión de credenciales en la nube, la comunidad de Kubernetes utiliza controladores GitOps que permiten a los desarrolladores gestionar recursos mediante archivos de configuración en formato YAML. En Google Cloud, la herramienta utilizada para este fin es Google Kubernetes Config Connector (KCC), que se ejecuta en un clúster de GKE y procesa estas solicitudes empleando su propia cuenta de servicio, la cual suele poseer privilegios elevados para administrar infraestructura a nivel de organización o de proyecto sin que los desarrolladores necesiten credenciales directas.
Esta configuración, sin embargo, genera una vulnerabilidad conocida como ConfigConfusion, descubierta por un investigador de seguridad. Un atacante con acceso limitado a un espacio de nombres (namespace) en Kubernetes y permisos para crear recursos específicos puede utilizarlos indirectamente para asignarse el rol de propietario en toda la organización de Google Cloud. El problema radica en que Kubernetes valida únicamente los permisos dentro del clúster, mientras que Google Cloud solo verifica los permisos de la cuenta de servicio de KCC, cayendo en un escenario típico de "diputado confuso" (confused deputy) donde se ejecutan acciones con más autoridad de la que posee el usuario original.
Ante este hallazgo, la postura de Google ha sido considerar que KCC funciona tal como fue diseñado y que los riesgos derivan de decisiones de configuración del administrador al otorgar permisos amplios. Implementar una solución que valide la identidad en la nube de cada usuario rompería el modelo operativo original de la herramienta. No obstante, problemas similares de arquitectura de operadores de infraestructura ocurren en otras plataformas como AWS y Azure, aunque estas últimas implementan medidas para limitar el alcance de los permisos por servicio o por espacio de nombres.