IAM: políticas, herencia y roles

IAM controla quién puede hacer qué sobre qué recurso. Para dar acceso se concede un rol a un principal sobre un recurso. Los permisos no se conceden directamente: siempre van dentro de roles.

Políticas de permiso (allow policies)

Una allow policy (antes «política de IAM») es un objeto JSON o YAML asociado a un recurso con una lista de vinculaciones de rol (role bindings): cada una une un rol con los principales que lo tienen.

{
  "bindings": [
    { "role": "roles/storage.objectViewer",
      "members": ["group:analysts@example.com"] },
    { "role": "roles/compute.instanceAdmin.v1",
      "members": ["user:ana@example.com"],
      "condition": { "title": "until-dec",
        "expression": "request.time < timestamp('2026-12-31T00:00:00Z')" } }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 3
}

• Hasta 1500 principales por política.
• El etag controla la concurrencia: evita que dos cambios simultáneos se pisen.
• Versión: la 1 no admite condiciones; la 3 añade el campo condition (la 2 es interna).
• Los cambios suelen aplicarse en unos 2 minutos, pero a veces tardan 7 minutos o más.

Herencia y política efectiva

Una allow policy en un contenedor se aplica a ese contenedor y a todo lo que tiene debajo: organización → carpetas → proyectos → recursos. La política efectiva de un recurso es la unión de su política y las de todos sus antecesores: basta con que una vinculación de cualquier nivel conceda el acceso.

• Un permiso concedido arriba no se puede quitar con una allow policy más abajo. Para restringir hace falta una política de denegación.
• Los recursos que no admiten allow policy propia (por ejemplo, los buckets de logs) heredan las de sus antecesores: se concede el rol en el proyecto.
• Buenas prácticas de Google: conceder roles a grupos en lugar de a usuarios sueltos; pocos equipos con roles en la organización (seguridad, red); carpetas que reflejen la estructura de la empresa.

Crear y gestionar roles personalizados

• Se crean en una organización o un proyecto, nunca en una carpeta (para usarlo en una carpeta, créalo en la organización). Solo se pueden conceder dentro de esa organización o proyecto.
• Límite: 300 por organización y 300 por proyecto.
• Un rol de proyecto no puede incluir permisos que solo funcionan a nivel de carpeta u organización.
• No todos los permisos se admiten: cada uno tiene nivel SUPPORTED, TESTING o NOT_SUPPORTED.
• Algunos permisos van en pareja: para actualizar una política se necesita getIamPolicy además de setIamPolicy. Conviene partir de un rol predefinido.
• Fase de lanzamiento informativa: ALPHA, BETA, GA, DEPRECATED. Con DISABLED el rol sigue en las políticas pero no tiene efecto.
• El ID del rol no se puede cambiar. Un rol borrado se puede recuperar durante 7 días, y su ID no se puede reutilizar hasta pasados 44 días.
• Quien puede editar roles personalizados puede añadirse cualquier permiso: limita ese poder a muy pocas personas.

gcloud iam roles create vmOperator --project=my-project \
  --title="VM Operator" --description="Start and stop VMs" \
  --permissions="compute.instances.get,compute.instances.list,compute.instances.start,compute.instances.stop" \
  --stage=GA

gcloud iam roles create orgAuditor --organization=123456789012 --file=role.yaml
gcloud iam roles update vmOperator --project=my-project --stage=DISABLED
gcloud iam roles delete vmOperator --project=my-project
gcloud iam roles undelete vmOperator --project=my-project

Ver, conceder y revocar acceso

# Conceder o quitar un rol (cambio puntual)
gcloud projects add-iam-policy-binding my-project \
  --member=group:devs@example.com --role=roles/compute.viewer
gcloud projects remove-iam-policy-binding my-project \
  --member=group:devs@example.com --role=roles/compute.viewer

# Cambios masivos: leer, modificar y escribir
gcloud projects get-iam-policy my-project --format=json > policy.json
gcloud projects set-iam-policy my-project policy.json

• Formato de los principales: user:, group:, serviceAccount:, domain:.
• set-iam-policy sobrescribe la política entera. Sigue siempre el patrón leer-modificar-escribir para no borrar vinculaciones sin querer; el etag rechaza la escritura si otro la cambió entre medias.
• Los mismos comandos existen para carpetas (gcloud resource-manager folders), organizaciones y recursos concretos.

IAM Conditions

Control de acceso basado en atributos: la vinculación solo concede el rol si la expresión, escrita en un subconjunto de CEL (Common Expression Language), es verdadera. Sirven, por ejemplo, para acceso temporal o limitado a recursos con cierto nombre. También se usan en reglas de denegación y en Principal Access Boundary.

request.time < timestamp('2026-12-31T00:00:00Z')
resource.name.startsWith('projects/_/buckets/exampleco-site-assets/')

• No se pueden usar con los roles básicos heredados (Owner, Editor, Viewer) ni con allUsers o allAuthenticatedUsers.
• Una vinculación condicional no anula una sin condición: si el principal ya tiene el rol sin condición, lo tiene siempre.
• En un bucket de Cloud Storage requieren acceso uniforme a nivel de bucket.
• Google recomienda no superar 100 vinculaciones condicionales por política.

Políticas de denegación y Principal Access Boundary

Privileged Access Manager (PAM) permite que los principales pidan acceso temporal y auditable, con justificación o aprobación, en lugar de tener un rol de forma permanente.

Escenarios de examen

Trampas frecuentes del examen