Utilisez des identifiants temporaires avec un rôle IAM

Introduction

Un traitement a besoin d'accéder aux rapports avec une identité de travail temporaire. Vous créerez un rôle, choisirez qui peut l'utiliser, testerez son autorisation de lecture et révoquerez l'accès avant le nettoyage.

Terminez d'abord Accordez le moindre privilège à un lecteur de rapports pour les champs des politiques et les limites des requêtes. Cette nouvelle VM prépare les profils default, worker et outsider. Utilisez /home/labex/project et AWS View ; aucune configuration de compte personnel n'est nécessaire. Gardez les fichiers d'identifiants, les caches CLI et les réponses AssumeRole non filtrées privés.

Lien avec les certifications

Vue d’ensemble du lab

Définissez la confiance et l'autorisation de lecture du rôle

Dans cette étape, vous créerez ReportReader avec une politique de confiance nommant son appelant autorisé. Une politique de confiance est une politique de ressource sur le rôle : son Principal identifie qui peut assumer ce rôle. La politique d'autorisations du rôle définit séparément ce qu'une session obtenue peut faire.

Le traitement a maintenant besoin d’une session de rôle temporaire. Utilisez les champs Action et Resource connus pour son travail dans S3, et une politique de confiance distincte pour l’entrée dans le rôle. Vous testerez ces deux décisions séparément avant de retirer l’accès.

Un rôle IAM définit des autorisations et qui peut l'assumer. AWS Security Token Service (STS) émet des identifiants temporaires pour une session de rôle, une identité différente de celle de son appelant.

Confirmez l'ARN du traitement pour le comparer à la confiance initiale.

cd /home/labex/project

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

Attendez-vous à arn:aws:iam::123456789012:user/report-worker. Commencez avec une confiance nommant uniquement l'opérateur. sts:AssumeRole demande une session de rôle ; Principal est un ARN d'identité, pas un nom de profil. Le traitement n'est volontairement pas encore approuvé.

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

Attendez-vous à un ARN se terminant par role/ReportReader. Créer un rôle ne lui donne pas d'autorisations S3. Ajoutez une politique intégrée limitée : le rôle peut effectuer GetObject uniquement pour le rapport d'aujourd'hui, sans l'écrire ni lire la paie.

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

Relisez les deux documents. La confiance contrôle l'entrée ; les autorisations du rôle contrôlent les opérations de la session. Le traitement n'est pas encore approuvé. Testez cette condition d'entrée en sélectionnant uniquement le champ ARN renvoyé, sans secret.

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

Attendez-vous à AccessDenied. Ne retirez pas le filtre de requête : une réponse réussie non filtrée contient des secrets.

Autorisez l'appelant et utilisez un profil de rôle

Dans cette étape, vous permettrez au traitement de demander ReportReader, mettrez à jour la confiance du rôle et utiliserez un profil de rôle. Les deux utilisateurs de test recevront la même autorisation d'appelant ; seul le traitement approuvé devrait obtenir la session de rôle.

Rédigez une politique d'appelant dont Resource est l'ARN exact du rôle, puis attachez-la au traitement.

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

Pour isoler la vérification de confiance, donnez à outsider la même autorisation d'appelant limitée. Cet utilisateur de comparaison jetable ne figure pas dans le document de confiance.

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

Attendez-vous à AccessDenied : son Allow d'identité ne remplace pas la confiance existante nommant uniquement l'opérateur. Remplacez cette confiance par le traitement prévu et mettez à jour le rôle.

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

Attendez-vous à AccessDenied même si la politique d'identité d'outsider permet AssumeRole. Son ARN n'est pas approuvé. Répétez comme traitement :

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 confiance du rôle a décidé quel appelant pouvait entrer. Un Allow d'identité ne peut pas la contourner. Pour une confiance du même compte nommant directement un utilisateur, cette confiance peut accorder l'entrée sans Allow d'identité distinct ; les autorisations d'appelant identiques ici aident à isoler la comparaison de confiance.

Attendez-vous à un ARN se terminant par assumed-role/ReportReader/report-run. Un nom de session aide à distinguer les utilisations du rôle dans les enregistrements d'activité. Les identifiants de rôle expirent ; le profil de rôle CLI ci-dessous obtient les identifiants temporaires pour vous.

Configurez le profil préparé report-role pour demander automatiquement ces identifiants temporaires. source_profile sélectionne l'appelant et role_arn sélectionne le rôle cible. Ces paramètres ne contiennent aucune valeur secrète. La CLI stocke son cache temporaire de manière sécurisée ; ne l'affichez pas.

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

Attendez-vous à nouveau à l'ARN assumed-role. La CLI effectue l'authentification STS en interne pour ce profil. L'identité du traitement elle-même possède l'autorisation AssumeRole, pas l'autorisation S3 du rôle.

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

Attendez-vous à AccessDenied. Assumer un rôle n'attache pas ses autorisations à l'utilisateur source.

Testez les limites de ressources et d'actions de la session de rôle

Dans cette étape, vous utiliserez le profil de rôle pour le traitement de rapports et confirmerez qu'il ne peut pas effectuer de travail sans rapport. Une requête AssumeRole réussie prouve uniquement l'entrée dans le rôle ; les véritables requêtes S3 prouvent son accès effectif.

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

cat today.txt

Attendez-vous à Daily orders: 145. Essayez les deux ressources existantes en dehors de l'ARN d'objet exact du rôle.

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

Toutes deux doivent renvoyer AccessDenied. Essayez ensuite d'écraser le rapport d'aujourd'hui avec le remplacement non approuvé fourni. GetObject n'autorise pas 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

Attendez-vous à PutObject AccessDenied et à Daily orders: 145 inchangé. Un fichier local manquant, une erreur d'identifiants expirés ou un service indisponible correspond à un autre diagnostic et ne prouve pas une limite d'autorisation. AWS View affiche la confiance stockée, la politique du rôle et les lectures réelles de la session de rôle ; développez le rapport d'aujourd'hui pour examiner ses octets.

Révoquez l'accès du rôle et nettoyez

Dans cette étape, vous retirerez l'autorisation de rapports du rôle avant de supprimer ses données. Retirer une autorisation du rôle et empêcher de nouvelles prises de rôle sont des actions distinctes ; vider un cache local seul ne révoque pas les autorisations côté serveur.

Retirez ReportRead pendant que le rôle et le rapport existent encore, puis répétez la lecture via le profil de rôle.

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

Attendez-vous à AccessDenied. Retirez les deux autorisations d'appelant et remplacez la confiance directe du traitement par une confiance limitée à l'opérateur. Retirer un Allow d'identité seul ne révoque pas une autorisation de confiance directe du même compte. Testez ensuite que le traitement ne peut pas obtenir une nouvelle session.

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

Attendez-vous à AccessDenied pendant que le rôle existe encore. Supprimez le rôle uniquement après ces vérifications fonctionnelles de révocation.

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

Attendez-vous à une liste de rôles vide et à KeyCount: 0 dans la réponse des objets. Supprimez le compartiment vide de l'exercice, puis confirmez que la référence existe toujours avec ses octets d'origine.

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

Seul le compartiment de référence reste avec Platform reference: keep. Ces requêtes réussies établissent la suppression et la conservation. L'environnement jetable récupère les identités préparées et les fichiers d'identifiants temporaires à sa fermeture. Vous avez retiré le rôle et les autorisations d'appelant créés pour cet exercice.

Résumé

Vous avez séparé la confiance du rôle de sa politique d'autorisations, prouvé qu'une autorisation d'appelant seule ne peut pas contourner la confiance et utilisé STS via un profil de rôle CLI. La session de rôle pouvait lire uniquement son rapport et ne pouvait ni écrire ni lire les données sans rapport avec la tâche. Vous avez retiré les autorisations du rôle et des appelants avant le nettoyage ciblé. Préférez les rôles temporaires aux clés permanentes des traitements et examinez l'identité réelle ainsi que les requêtes autorisées et refusées pour diagnostiquer l'accès.

Pour approfondir ce sujet, consultez la documentation AWS : Rôles, confiance et informations d’identification temporaires IAM.