Saltar al contenido
CLF-C02Sesión 5 · Políticas, roles y federación

Hazlo tú (20 min)

Vas a terminar de preparar tu identidad de trabajo: MFA para estudio-diario y un rol con el que crear recursos en los laboratorios siguientes. Costo: $0. IAM y AWS STS no tienen cargo adicional. Los botones se citan en inglés.

Plan gratuito: como en la Sesión 4, IAM, STS y CloudShell figuran entre los servicios gratuitos del registro simplificado, pero AWS no lo confirma para toda cuenta del plan gratuito. Si tu cuenta no te deja crear el rol, no pases al plan de pago: haz solo la parte D, en papel.

El esquema. estudio-diario sigue siendo de solo lectura, como mínimo privilegio para el día a día. Cuando un laboratorio cree o borre recursos, asumirá el rol laboratorio-escritura, que exige MFA y da credenciales de una hora. El rol usa la política administrada por AWS PowerUserAccess: permite casi todos los servicios, pero no IAM, AWS Organizations ni la configuración de la cuenta. Es amplia para una empresa, pero en una cuenta de práctica evita pedir permisos en cada sesión. No puede cambiar permisos ni unir la cuenta a una organización, lo que la pasaría al plan de pago.

Seguridad: no crees claves de acceso. El usuario raíz vuelve solo en la parte A: estudio-diario no puede darse permisos a sí mismo.

Parte A · Preparar MFA y el rol (como usuario raíz).

  1. Entra en console.aws.amazon.com como Root user, con su MFA, y abre IAM. Anota tu número de cuenta de 12 dígitos: aparece en el menú de arriba a la derecha.

  2. En Users, abre estudio-diario y la pestaña Security credentials. En Multi-factor authentication (MFA) elige Assign MFA device.

  3. Escribe un nombre, como estudio-diario-app, elige Authenticator app y Next. Elige Show QR code y escanéalo con tu app de autenticación; la de la Sesión 2 sirve, porque guarda varias cuentas.

  4. Escribe dos códigos seguidos en MFA code 1 y MFA code 2, y elige Add MFA.

  5. En Roles, elige Create role. En Trusted entity type elige AWS account y luego This account. Marca Require MFA y elige Next.

  6. Busca y marca PowerUserAccess. Elige Next, escribe laboratorio-escritura en Role name y elige Create role.

  7. En Policies, elige Create policy y cambia el editor a JSON. Borra lo que trae y pega esta política, con tu número de cuenta en lugar de 111122223333:

    {
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::111122223333:role/laboratorio-escritura"
  }]
}

  8. Elige Next, escribe asumir-laboratorio como nombre y elige Create policy: una política administrada por el cliente.

  9. En User groups, abre lectura-estudio, pestaña Permissions, y elige Add permissions › Attach policies. Marca asumir-laboratorio y confirma con Attach policies.

  10. Cierra la sesión del usuario raíz.

Parte B · Entrar con MFA y asumir el rol.

  1. Entra con estudio-diario por la URL que copiaste en la Sesión 4. Ahora te pide un código MFA.
  2. Abre el menú de arriba a la derecha y elige Switch role. Escribe tu número de cuenta y laboratorio-escritura como nombre del rol. En Display name escribe laboratorio, elige un color y luego Switch Role. El menú muestra ahora laboratorio con ese color.
  3. Abre CloudShell (si no ves su icono, cambia de Región) y ejecuta aws sts get-caller-identity: el resultado contiene assumed-role/laboratorio-escritura. Son credenciales temporales de STS, no las de tu usuario.
  4. Ejecuta aws iam create-group --group-name prueba-escritura. Recibes AccessDenied: ni siquiera el rol puede tocar IAM.
  5. Abre el menú de arriba a la derecha y elige Switch back. Vuelves a ser estudio-diario, solo lectura.

Parte C · Probar con el simulador de políticas. Como estudio-diario, abre IAM › Policy simulator. Solo dice si una acción se permitiría.

  1. Elige como identidad el rol laboratorio-escritura. Añade las acciones cloudformation:CreateStack e iam:CreateUser y ejecuta la simulación. La primera sale permitida; la segunda, negada implícitamente.
  2. Cambia la identidad al usuario estudio-diario y simula cloudformation:CreateStack y sts:AssumeRole. Para la segunda, indica como recurso el ARN del rol, el mismo de la política del paso 7 de la parte A. La primera sale negada: tu usuario solo lee. La segunda sale permitida por asumir-laboratorio.

Comprueba: puedes explicar por qué el paso 4 de la parte B falló aunque el rol tenga muchos permisos, y por qué el paso 2 de la parte C permite asumir el rol pero no crear una pila.

Con qué identidad trabajas desde ahora. Entras siempre como estudio-diario, con MFA. Para leer y explorar te quedas así. Cuando un laboratorio cree, cambie o borre recursos, eliges Switch role › laboratorio, y Switch back al terminar. Si el laboratorio usa terminal, abre CloudShell después de cambiar de rol: aws login en tu equipo te da solo la lectura de tu usuario. El usuario raíz se queda guardado para sus tareas exclusivas.

Limpieza: no creaste recursos con costo. Conserva el MFA, el rol y la política: los usarás desde la Sesión 6. Si abandonas el curso, borra el rol en Roles y la política en Policies con Delete, además del usuario y el grupo de la Sesión 4.

Parte D · Predecir la decisión (en papel, 5 min). Ana está en un grupo con Allow en cloudformation:* y tiene una política en línea con Deny en cloudformation:DeleteStack. Luis no tiene políticas. ¿Qué pasa?

  1. Ana crea una pila.
  2. Ana borra una pila.
  3. Luis lista las pilas.

Comprueba: 1 permitido; 2 negado, porque el Deny explícito gana; 3 negado implícitamente.

63