El 95% de la seguridad en la nube se decide en la capa IAM
Más del 90% de los incidentes de seguridad en la nube se originan en una configuración incorrecta de Cloud IAM. Una clave de Service Account con permisos excesivos que aparece accidentalmente en un repositorio de GitHub público, un empleado que ya no trabaja en la empresa pero cuya cuenta sigue teniendo acceso a recursos de producción, alguien que agrega silenciosamente permisos de propietario sin que nadie lo note hasta que el daño ya está hecho — todos estos escenarios comienzan con una falla de Cloud IAM. En el examen de Associate Cloud Engineer, el dominio de Cloud IAM representa aproximadamente el 17% de las preguntas y evalúa el juicio de seguridad real en lugar de la memorización mecánica. Este artículo cubre el panorama completo: el modelo de Cloud IAM, cómo usar las cuentas de servicio de forma segura, cómo Workload Identity y Workload Identity Federation eliminan la necesidad de claves de larga duración, y cómo Cloud Audit Logs proporcionan visibilidad sobre todo lo que sucede en su entorno.
---
El modelo de Cloud IAM: miembros, roles y Policy Bindings
Cloud IAM opera sobre tres conceptos fundamentales. Un miembro responde a la pregunta "¿quién?", un rol responde "¿qué puede hacer?", y un Policy Binding conecta a un miembro con un rol sobre un recurso específico.
Existen cinco tipos de miembros en Cloud IAM.
| Tipo de miembro | Descripción | Ejemplo | |-----------------|-------------|---------| | Google Account | Identidad personal de Google | user@gmail.com | | Service Account | Identidad para aplicaciones y VMs | my-app@project-id.iam.gserviceaccount.com | | Google Group | Colección de cuentas gestionadas como unidad | dev-team@company.com | | Google Workspace Domain | Todas las cuentas de un dominio | @company.com | | allAuthenticatedUsers | Cualquier identidad autenticada con Google | (usar con precaución en recursos públicos) |
Vincular un rol a un Google Group en lugar de usuarios individuales es el patrón recomendado a escala. Una vez que el grupo tiene el binding, solo necesitas gestionar la membresía del grupo — la política de Cloud IAM en sí nunca cambia, lo que reduce significativamente la complejidad de auditoría. Una sola política admite hasta 1.500 bindings.
Trampa del examen: allUsers significa cualquier persona en internet sin autenticación requerida, mientras que allAuthenticatedUsers significa cualquier identidad que se haya autenticado con una cuenta de Google. Usa allUsers solo en buckets de Cloud Storage que sean intencionalmente públicos y nunca en recursos que contengan datos sensibles.
---
Tres tipos de roles y el principio de mínimo privilegio
Cloud IAM ofrece tres categorías de roles. Entender cuándo es apropiado cada uno es uno de los caminos más claros hacia un mejor puntaje en el examen.
| Tipo de rol | Ejemplos | Alcance | Señal en el examen | |-------------|----------|---------|--------------------| | Básico | roles/owner, roles/editor, roles/viewer | Proyecto completo, muy amplio | Casi siempre incorrecto — viola el mínimo privilegio | | Predefinido | roles/compute.admin, roles/bigquery.dataViewer | Acotado por servicio y acción | Respuesta correcta en la mayoría de escenarios | | Personalizado | Combinaciones de permisos seleccionados por el usuario | Control extremadamente fino | Usar cuando ningún rol predefinido se ajusta |
Los roles básicos están desaconsejados por razones concretas. roles/editor puede modificar casi cualquier recurso en un proyecto, y roles/owner otorga control total incluyendo la capacidad de cambiar políticas de Cloud IAM. Otorgar cualquiera de estos roles a alguien que solo necesita gestionar un único servicio viola el principio de mínimo privilegio. Cuando una pregunta del examen incluye frases como "con los permisos mínimos" o "sin otorgar acceso innecesario", busca el rol predefinido más específico que aplique.
Los roles personalizados existen para situaciones en las que ningún rol predefinido cumple el requisito. Una restricción crítica: los roles personalizados solo pueden crearse a nivel de organización o proyecto — los roles personalizados a nivel de carpeta no están soportados. IAM Recommender utiliza 90 días de datos de uso y aprendizaje automático para identificar permisos que nunca han sido ejercidos y recomienda eliminarlos. Cualquier escenario del examen que involucre una iniciativa de mínimo privilegio a nivel organizacional después de una auditoría debe apuntar a IAM Recommender.
!3 tipos de roles de IAM
Herencia de políticas e IAM Conditions
Los recursos de GCP se organizan en una jerarquía, y las políticas de Cloud IAM se propagan hacia abajo a través de esa jerarquía.
| Nivel | Descripción | Dirección de herencia | |-------|-------------|----------------------| | Organization | Unidad de nivel superior (empresa o dominio) | Fluye a todos los elementos secundarios | | Folder | Agrupación por departamento o entorno | Fluye a los proyectos secundarios | | Project | Límite principal de aislamiento de recursos | Fluye a los recursos secundarios | | Resource | Instancia de Compute Engine, bucket de Cloud Storage, etc. | Nivel más bajo — solo recibe |
La regla crítica de la herencia es que los permisos otorgados en un nivel superior no pueden revocarse en un nivel inferior. Si un miembro recibe roles/editor a nivel de Folder, todos los proyectos dentro de esa carpeta heredan acceso de editor y no existe un mecanismo para bloquearlo en un proyecto hijo específico. Esto hace que la ubicación de los bindings de roles sea tan importante como la elección del rol mismo — otorga en el alcance más estrecho que satisfaga el requisito.
IAM Conditions extiende los Policy Bindings con control de acceso basado en atributos. Puedes adjuntar condiciones basadas en tiempo, nombre del recurso o tipo de recurso para que un binding sea sensible al contexto. Un patrón operacional común es otorgar a un ingeniero de despliegue acceso elevado solo durante una ventana de mantenimiento aprobada, con el binding que expira automáticamente cuando la ventana se cierra — sin limpieza manual requerida.
| Tipo de condición | Ejemplo de uso | Escenario | |-------------------|----------------|----------| | Basada en tiempo | Permitir acceso solo durante horario laboral (09:00–18:00) | Restricción de acceso al entorno de desarrollo | | Nombre del recurso | Aplicar solo a buckets que coincidan con un patrón de nomenclatura específico | Separar buckets de dev y prod por entorno | | Tipo de recurso | Aplicar solo a compute.googleapis.com/Instance | Rol de gestión exclusiva de VMs |
---
Cuentas de servicio: naturaleza dual y riesgo de gestión de claves
Una Service Account desempeña dos roles distintos simultáneamente en Cloud IAM. Como miembro, recibe roles de Cloud IAM y actúa como la identidad que accede a los recursos de GCP. Como recurso, puede ser el sujeto de un Policy Binding que controla quién puede suplantarla. Toda superficie de cómputo de GCP — instancias de Compute Engine, servicios de Cloud Run, Cloud Functions — adjunta una Service Account para interactuar con otros servicios de GCP.
Las claves de Service Account (archivos de credenciales JSON) se encuentran entre los artefactos más peligrosos en un entorno de GCP.
| Método de acceso | Nivel de seguridad | Recomendado | Notas | |------------------|-------------------|-------------|-------| | Clave de Service Account (JSON) | Bajo | No recomendado | Sin expiración; riesgo inmediato si se expone | | Suplantación de Service Account | Alto | Recomendado | Tokens de corta duración; trazabilidad en Cloud Audit Logs | | Workload Identity (GKE) | Muy alto | Fuertemente recomendado | Sin claves; credenciales con rotación automática | | Workload Identity Federation (externo) | Muy alto | Fuertemente recomendado | Identidad de IdP externo intercambiada por tokens GCP de corta duración |
Los archivos de clave no tienen expiración incorporada. Una vez emitida, una clave permanece válida indefinidamente a menos que sea revocada explícitamente. La inclusión accidental en repositorios de GitHub, imágenes de Docker o archivos de log es una clase recurrente de incidentes. La guía oficial de Google es eliminar las claves de Service Account en favor de los mecanismos de Workload Identity siempre que sea posible.
La suplantación de Service Account funciona otorgando a un principal el rol roles/iam.serviceAccountTokenCreator, lo que le permite solicitar tokens OAuth de corta duración que llevan los permisos de la Service Account. Estos tokens expiran automáticamente después de como máximo una hora, y cada evento de suplantación queda registrado en Cloud Audit Logs, proporcionando una trazabilidad completa. En entornos heredados donde las claves no pueden evitarse, implementa rotación regular, eliminación inmediata de claves sin uso y almacenamiento gestionado por Cloud KMS.
---
Workload Identity y Workload Identity Federation
Distinguir entre estos dos mecanismos de autenticación sin claves es un enfoque consistente del examen de Associate Cloud Engineer.
| Atributo | Workload Identity (GKE) | Workload Identity Federation (externo) | |----------|-------------------------|-----------------------------------------| | Objetivo | Pods de GKE exclusivamente | AWS, Azure, GitHub Actions, sistemas on-premises | | Mecanismo | Kubernetes Service Account → vínculo con GCP Service Account | Token de IdP externo intercambiado por token GCP de corta duración | | Claves requeridas | Ninguna | Ninguna | | Escenario típico | Carga de trabajo GKE llamando a APIs de GCP | Pipeline de CI/CD externo o multi-cloud llamando a APIs de GCP |
Workload Identity vincula una Kubernetes Service Account (KSA) dentro de un pod de GKE con una GCP Service Account (GSA). El pod llama a las APIs de GCP sin ningún material de clave; las credenciales se obtienen automáticamente del servidor de metadatos y se rotan sin intervención del operado