Utiliza credenciales temporales con un rol IAM

Introducción

Un trabajador necesita acceso a informes mediante una identidad temporal de trabajo. Crearás un rol, elegirás quién puede utilizarlo, probarás su permiso de lectura y revocarás el acceso antes de la limpieza.

Completa primero Concede el mínimo privilegio a un lector de informes para conocer los campos de las políticas y los límites de solicitudes. Esta VM nueva prepara los perfiles default, worker y outsider. Utiliza /home/labex/project y AWS View; no necesitas configurar una cuenta personal. Mantén privados los archivos de credenciales, las cachés de la CLI y las respuestas AssumeRole sin filtrar.

Relación con las certificaciones

Descripción general del laboratorio

Define la confianza del rol y su permiso de lectura

En este paso, crearás ReportReader con una política de confianza que identifica al llamante permitido. Una política de confianza es una política de recurso del rol: su Principal identifica quién puede asumir ese rol. La política de permisos del rol define por separado lo que puede hacer una sesión resultante.

El trabajo necesita ahora una sesión temporal de rol. Usa los campos conocidos Action y Resource para su acceso a S3, y una política de confianza separada para entrar en el rol. Probarás ambas decisiones por separado antes de revocar el acceso.

Un rol IAM define permisos y quién puede asumirlo. AWS Security Token Service (STS) emite credenciales temporales para una sesión de rol, una identidad distinta de la de quien la solicita.

Confirma el ARN del trabajador para compararlo con la confianza inicial.

cd /home/labex/project

aws sts get-caller-identity --profile worker --query Arn --output text

Espera arn:aws:iam::123456789012:user/report-worker. Empieza con una confianza que identifica únicamente al operador. sts:AssumeRole solicita una sesión de rol; Principal es un ARN de identidad, no un nombre de perfil. Deliberadamente, el trabajador todavía no es de confianza.

cat > trust.json <<'JSON'
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::123456789012:user/iam03-operator"},"Action":"sts:AssumeRole"}]}
JSON

aws iam create-role \
  --role-name ReportReader \
  --assume-role-policy-document file://trust.json \
  --query Role.Arn \
  --output text

Espera el ARN que termina en role/ReportReader. Crear un rol no le concede permisos de S3. Añade una política insertada limitada: el rol solo puede realizar GetObject sobre el informe de hoy, no escribirlo ni leer nóminas.

cat > role-policy.json <<'JSON'
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"s3:GetObject","Resource":"arn:aws:s3:::labex-iam03-reports/reports/today.txt"}]}
JSON

aws iam put-role-policy \
  --role-name ReportReader \
  --policy-name ReportRead \
  --policy-document file://role-policy.json

aws iam get-role --role-name ReportReader --query Role.AssumeRolePolicyDocument

aws iam get-role-policy \
  --role-name ReportReader \
  --policy-name ReportRead \
  --query PolicyDocument

Lee ambos documentos almacenados. La confianza controla la entrada; los permisos del rol controlan las operaciones de la sesión. El trabajador todavía no es de confianza. Prueba ese control de entrada seleccionando únicamente el campo seguro ARN devuelto.

aws sts assume-role --profile worker --role-arn arn:aws:iam::123456789012:role/ReportReader --role-session-name report-run --query AssumedRoleUser.Arn --output text || true

Espera AccessDenied. No elimines el filtro de consulta: una respuesta correcta sin filtrar incluye secretos.

Autoriza al llamante y utiliza un perfil de rol

En este paso, permitirás al trabajador solicitar ReportReader, actualizarás la confianza del rol y utilizarás un perfil de rol. Ambos usuarios de prueba recibirán el mismo permiso de llamante; solo el trabajador de confianza debería obtener la sesión de rol.

Escribe una política de llamante cuyo Resource sea el ARN exacto del rol y después adjúntala al trabajador.

cat > assume-policy.json <<'JSON'
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"sts:AssumeRole","Resource":"arn:aws:iam::123456789012:role/ReportReader"}]}
JSON

aws iam put-user-policy \
  --user-name report-worker \
  --policy-name AssumeReportReader \
  --policy-document file://assume-policy.json

Para aislar la comprobación de confianza, concede a outsider el mismo permiso limitado de llamante. Este usuario desechable de comparación no figura en el documento de confianza.

aws iam put-user-policy \
  --user-name outsider \
  --policy-name AssumeReportReader \
  --policy-document file://assume-policy.json

aws sts assume-role --profile worker --role-arn arn:aws:iam::123456789012:role/ReportReader --role-session-name before-trust --query AssumedRoleUser.Arn --output text || true

Espera AccessDenied: el Allow de su identidad no anula la confianza existente que identifica únicamente al operador. Reemplaza esa confianza por el trabajador previsto y actualiza el rol.

cat > trust.json <<'JSON'
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::123456789012:user/report-worker"},"Action":"sts:AssumeRole"}]}
JSON

aws iam update-assume-role-policy \
  --role-name ReportReader \
  --policy-document file://trust.json

aws sts assume-role --profile outsider --role-arn arn:aws:iam::123456789012:role/ReportReader --role-session-name outsider-test --query AssumedRoleUser.Arn --output text || true

Espera AccessDenied aunque la política de identidad de outsider permita AssumeRole. Su ARN no es de confianza. Repite como trabajador:

aws sts assume-role \
  --profile worker \
  --role-arn arn:aws:iam::123456789012:role/ReportReader \
  --role-session-name report-run \
  --query AssumedRoleUser.Arn \
  --output text

La confianza del rol decidió qué llamante podía entrar. Un Allow de identidad no puede evitarla. Cuando una confianza de la misma cuenta identifica directamente a un usuario, esa confianza puede conceder la entrada sin un Allow de identidad independiente; aquí las concesiones iguales de llamante ayudan a aislar la comparación de confianza.

Espera un ARN que termina en assumed-role/ReportReader/report-run. Un nombre de sesión ayuda a distinguir los usos del rol en los registros de actividad. Las credenciales de rol caducan; el perfil de rol de la CLI siguiente obtiene credenciales temporales por ti.

Configura el perfil report-role preparado para solicitar automáticamente estas credenciales temporales. source_profile selecciona al llamante y role_arn selecciona el rol objetivo. Estos ajustes no contienen valores secretos. La CLI almacena su caché temporal de forma segura; no la muestres.

aws configure set role_arn arn:aws:iam::123456789012:role/ReportReader --profile report-role

aws configure set source_profile worker --profile report-role

aws configure set role_session_name report-run --profile report-role

aws sts get-caller-identity --profile report-role --query Arn --output text

Espera de nuevo el ARN assumed-role. La CLI realiza la autenticación STS internamente para este perfil. La propia identidad del trabajador tiene permiso AssumeRole, no el permiso de S3 del rol.

aws s3api get-object --profile worker --bucket labex-iam03-reports --key reports/today.txt direct-worker.txt || true

Espera AccessDenied. Asumir un rol no adjunta sus permisos al usuario de origen.

Prueba los límites de recursos y acciones de la sesión de rol

En este paso, utilizarás el perfil de rol para el trabajo de informes y confirmarás que no puede realizar trabajo ajeno a la tarea. Una solicitud AssumeRole correcta solo demuestra la entrada al rol; las solicitudes reales de S3 demuestran su acceso efectivo.

aws s3api get-object \
  --profile report-role \
  --bucket labex-iam03-reports \
  --key reports/today.txt today.txt

cat today.txt

Espera Daily orders: 145. Prueba los dos recursos existentes fuera del ARN exacto de objeto del rol.

aws s3api get-object --profile report-role --bucket labex-iam03-reports --key private/payroll.txt private-denied.txt || true

aws s3api get-object --profile report-role --bucket labex-iam03-reference --key reference.txt reference-denied.txt || true

Ambos deben devolver AccessDenied. Después intenta sobrescribir el informe de hoy con el reemplazo no aprobado proporcionado. GetObject no autoriza PutObject.

aws s3api put-object --profile report-role --bucket labex-iam03-reports --key reports/today.txt --body upload.txt || true

aws s3api get-object \
  --profile report-role \
  --bucket labex-iam03-reports \
  --key reports/today.txt today.txt

cat today.txt

Espera AccessDenied de PutObject y Daily orders: 145 sin cambios. Un archivo local ausente, un error de credenciales caducadas o un servicio no disponible son diagnósticos diferentes y no demuestran un límite de permisos. AWS View muestra la confianza almacenada, la política de rol y las lecturas reales de la sesión de rol; despliega el informe de hoy para inspeccionar sus bytes.

Revoca el acceso del rol y limpia los recursos

En este paso, eliminarás la concesión de informes del rol antes de eliminar sus datos. Eliminar un permiso del rol e impedir nuevas asunciones son acciones independientes; borrar una caché local por sí solo no revoca permisos del servidor.

Elimina ReportRead mientras el rol y el informe todavía existen y después repite la lectura mediante el perfil de rol.

aws iam delete-role-policy --role-name ReportReader --policy-name ReportRead

aws s3api get-object --profile report-role --bucket labex-iam03-reports --key reports/today.txt revoked.txt || true

Espera AccessDenied. Elimina ambas concesiones de llamante y reemplaza la confianza directa del trabajador por una confianza exclusiva del operador. Eliminar únicamente un Allow de identidad no revoca una concesión de confianza directa de la misma cuenta. Después prueba que el trabajador no puede obtener una sesión nueva.

aws iam delete-user-policy --user-name report-worker --policy-name AssumeReportReader

aws iam delete-user-policy --user-name outsider --policy-name AssumeReportReader

cat > trust.json <<'JSON'
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::123456789012:user/iam03-operator"},"Action":"sts:AssumeRole"}]}
JSON

aws iam update-assume-role-policy \
  --role-name ReportReader \
  --policy-document file://trust.json

aws sts assume-role --profile worker --role-arn arn:aws:iam::123456789012:role/ReportReader --role-session-name after-revocation --query AssumedRoleUser.Arn --output text || true

Espera AccessDenied mientras el rol todavía existe. Elimina el rol únicamente después de estas comprobaciones funcionales de revocación.

aws iam delete-role --role-name ReportReader

aws iam list-roles --query 'Roles[].RoleName'

aws s3api delete-object --bucket labex-iam03-reports --key reports/today.txt

aws s3api delete-object --bucket labex-iam03-reports --key private/payroll.txt

aws s3api list-objects-v2 --bucket labex-iam03-reports

Espera una lista de roles vacía y KeyCount: 0 en la respuesta de objetos. Elimina el bucket propio vacío y después confirma que la referencia sigue existiendo con sus bytes originales.

aws s3api delete-bucket --bucket labex-iam03-reports

aws s3api list-buckets --query 'Buckets[].Name'

aws s3api get-object --bucket labex-iam03-reference --key reference.txt reference.txt

cat reference.txt

Solo queda el bucket de referencia con Platform reference: keep. Estas consultas correctas demuestran la eliminación y la conservación. El entorno desechable retira las identidades preparadas y los archivos de credenciales temporales cuando termina. Has eliminado el rol y las concesiones de llamante creadas para este ejercicio.

Resumen

Separaste la confianza del rol de su política de permisos, demostraste que una concesión de llamante por sí sola no puede evitar la confianza y utilizaste STS mediante un perfil de rol de la CLI. La sesión de rol solo podía leer su informe y no podía escribir ni leer datos ajenos a la tarea. Eliminaste tanto las concesiones del rol como las del llamante antes de la limpieza delimitada. Prefiere roles temporales a claves permanentes de cargas de trabajo e inspecciona la identidad real y las solicitudes permitidas y denegadas al diagnosticar el acceso.

Para ampliar este tema, consulta la referencia de AWS: Roles, confianza y credenciales temporales IAM.