Administra un equipo con grupos IAM

Introducción

Dos analistas necesitan el mismo acceso a informes. Administrarás una política compartida, transferirás la responsabilidad de los informes de Alice a Bob y comprobarás que un antiguo miembro pierde ese acceso.

Completa primero Concede el mínimo privilegio a un lector de informes para conocer las políticas de identidad y las solicitudes permitidas y denegadas. Esta VM nueva proporciona default para la administración y alice, bob y outsider para las pruebas. Utiliza /home/labex/project y AWS View para comparar la pertenencia con las lecturas reales.

Relación con las certificaciones

Descripción general del laboratorio

Crea un equipo y una política compartida

En este paso, crearás un grupo vacío y adjuntarás una política insertada. Un grupo es un objeto de administración de permisos, no una nueva identidad para solicitudes. Primero confirma el operador y Alice mediante STS; los ARN deberían terminar en user/iam02-operator y user/alice, respectivamente.

El equipo necesita el permiso de lectura que practicaste con un usuario. Asígnalo una vez a un grupo y cambia sus miembros al transferir la responsabilidad entre analistas. El informe y la política permanecen iguales durante el traspaso; cambia el usuario que hereda el permiso.

Un grupo IAM reúne usuarios para que hereden sus permisos. No tiene credenciales y no puede iniciar sesión ni asumir un rol por sí mismo. Este ejercicio practica una organización existente de usuarios IAM; el acceso humano de producción suele utilizar federación y roles temporales.

cd /home/labex/project

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

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

Alice inicialmente no tiene permiso para leer el informe existente. El operador es responsable de su preparación. Prueba antes de conceder el acceso:

aws s3api get-object --profile alice --bucket labex-iam02-reports --key reports/today.txt before.txt || true

Espera AccessDenied. || true permite que un comando que falla intencionadamente termine en una secuencia pegada; no convierte un fallo de conexión en una prueba de permisos.

Crea ReportTeam. Esto todavía no crea miembros ni concede permisos.

aws iam create-group --group-name ReportTeam

Escribe una política que permita únicamente GetObject en el prefijo de informes de este bucket. Un ARN de objeto incluye su clave; el comodín después de reports/ no coincide con las nóminas ni con otro bucket. Un Allow coincidente concede una solicitud a menos que un Deny explícito aplicable lo anule.

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

put-group-policy almacena esta política insertada directamente en el grupo. Se aplica a sus miembros; editar solo el archivo local no tiene efecto.

aws iam put-group-policy \
  --group-name ReportTeam \
  --policy-name ReportRead \
  --policy-document file://team-policy.json

aws iam get-group --group-name ReportTeam --query 'Users[].UserName'

aws iam get-group-policy \
  --group-name ReportTeam \
  --policy-name ReportRead \
  --query PolicyDocument

La lista de miembros está vacía. Alice sigue siendo rechazada porque ninguna pertenencia la conecta con la política.

aws s3api get-object --profile alice --bucket labex-iam02-reports --key reports/today.txt still-denied.txt || true

Añade a Alice y prueba el límite de permisos

En este paso, conectarás a Alice con la concesión del grupo y compararás sus solicitudes reales con las de Bob y outsider. add-user-to-group cambia la pertenencia; no crea ni muestra credenciales.

aws iam add-user-to-group --group-name ReportTeam --user-name alice

aws iam get-group --group-name ReportTeam --query 'Users[].UserName'

aws iam list-groups-for-user --user-name alice --query 'Groups[].GroupName'

Espera Alice en ReportTeam y ReportTeam en la lista de grupos de Alice. Ahora utiliza las credenciales de Alice para solicitar los bytes del informe.

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

cat alice-report.txt

Espera Daily orders: 145. La misma solicitud de informe de Bob y outsider debe fallar porque no son miembros.

aws s3api get-object --profile bob --bucket labex-iam02-reports --key reports/today.txt bob-denied.txt || true

aws s3api get-object --profile outsider --bucket labex-iam02-reports --key reports/today.txt outsider-denied.txt || true

Alice también sigue siendo rechazada fuera del alcance de recursos del grupo. Estos objetos existentes permiten diagnosticar la autorización, no una clave ausente.

aws s3api get-object --profile alice --bucket labex-iam02-reports --key private/payroll.txt private-denied.txt || true

aws s3api get-object --profile alice --bucket labex-iam02-reference --key reference.txt reference-denied.txt || true

Espera AccessDenied en las cuatro solicitudes negativas. AWS View muestra la pertenencia y realiza solicitudes GetObject reales para cada usuario; despliega el informe de hoy para inspeccionar los bytes recibidos por Alice.

Transfiere la pertenencia y vuelve a comprobar el acceso anterior

En este paso, transferirás la responsabilidad de los informes a Bob y verificarás que Alice pierde la concesión heredada. Eliminar la pertenencia a un grupo elimina los permisos heredados de ese grupo. No revoca otras concesiones que un usuario pudiera tener; estos usuarios preparados no tienen ninguna.

Añade primero a Bob y después elimina a Alice. Los dos usuarios comparten la misma política de grupo mientras ambos son miembros; después de la eliminación, solo Bob debería heredarla.

aws iam add-user-to-group --group-name ReportTeam --user-name bob

aws iam remove-user-from-group --group-name ReportTeam --user-name alice

aws iam get-group --group-name ReportTeam --query 'Users[].UserName'

Espera únicamente Bob. Lee el informe como Bob y después repite la solicitud idéntica como Alice.

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

cat bob-report.txt

aws s3api get-object --profile alice --bucket labex-iam02-reports --key reports/today.txt former-member.txt || true

aws s3api get-object --profile outsider --bucket labex-iam02-reports --key reports/today.txt outsider-denied.txt || true

Bob recibe 145; Alice y outsider reciben AccessDenied. Las credenciales seleccionan quién realiza la llamada, mientras que los permisos efectivos actuales determinan si su solicitud tiene éxito.

El grupo concede lectura, no escritura. Prueba el reemplazo proporcionado como Bob y confirma que el informe original sigue existiendo.

aws s3api put-object --profile bob --bucket labex-iam02-reports --key reports/today.txt --body upload.txt || true

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

cat bob-report.txt

Espera AccessDenied de PutObject seguido de Daily orders: 145 sin cambios. AWS View ahora muestra a Bob como miembro y a Alice rechazada; la propia política del grupo no ha cambiado.

Elimina el equipo y limpia sus datos

En este paso, revocarás el acceso heredado de Bob antes de eliminar el grupo y los datos de informes propios. IAM exige que un grupo no tenga miembros ni políticas adjuntas antes de eliminarlo. Conserva intactos el grupo independiente ReferenceTeam y la pertenencia de outsider a él.

aws iam remove-user-from-group --group-name ReportTeam --user-name bob

aws s3api get-object --profile bob --bucket labex-iam02-reports --key reports/today.txt revoked.txt || true

Espera AccessDenied mientras el informe todavía existe. Elimina la política insertada y después el grupo vacío.

aws iam delete-group-policy --group-name ReportTeam --policy-name ReportRead

aws iam delete-group --group-name ReportTeam

aws iam list-groups --query 'Groups[].GroupName'

aws iam get-group --group-name ReferenceTeam --query 'Users[].UserName'

Solo queda ReferenceTeam, que sigue conteniendo outsider. Elimina exactamente las dos claves de objetos propias y comprueba que el bucket de informes está vacío antes de eliminarlo.

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

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

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

Comprueba que KeyCount es 0 y no quedan entradas de objetos en Contents.

aws s3api delete-bucket --bucket labex-iam02-reports

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

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

cat reference.txt

Solo queda el bucket de referencia, con Platform reference: keep. Las consultas correctas a la API demuestran la limpieza; los errores de red no. AWS View muestra Group removed y Reports bucket removed. Los usuarios y recursos preparados se retiran cuando termina el entorno desechable; el grupo y los permisos creados por el estudiante ya no existen.

Resumen

Asignaste una política a un grupo, demostraste que la pertenencia concede acceso a informes, transferiste ese acceso y confirmaste que el antiguo miembro y outsider seguían siendo rechazados. La pertenencia a un grupo es una fuente de permisos; revisa todas las políticas aplicables cuando una identidad siga autorizada inesperadamente. Revocaste el acceso antes de la limpieza delimitada y conservaste el grupo y los datos ajenos a la tarea.

Para ampliar este tema, consulta la referencia de AWS: Grupos de usuarios y permisos heredados IAM.