Temporäre Zugangsdaten mit einer IAM-Rolle verwenden

Einführung

Ein Worker benötigt Berichtszugriff über eine temporäre Aufgabenidentität. Du erstellst eine Rolle, bestimmst, wer sie verwenden darf, testest ihre Leseberechtigung und entziehst den Zugriff vor der Bereinigung.

Schließe zuerst Einem Berichtsleser minimale Berechtigungen geben ab, um Richtlinienfelder und Anfragegrenzen kennenzulernen. Diese neue VM bereitet die Profile default, worker und outsider vor. Verwende /home/labex/project und AWS View; eine persönliche Kontoeinrichtung ist nicht erforderlich. Halte Zugangsdaten-Dateien, CLI-Caches und ungefilterte AssumeRole-Antworten vertraulich.

Bezug zu Zertifizierungen

Lab-Überblick

Definiere Vertrauen und Leseberechtigung der Rolle

In diesem Schritt erstellst du ReportReader mit einer Vertrauensrichtlinie, die ihren erlaubten Aufrufer benennt. Eine Vertrauensrichtlinie ist eine Ressourcenrichtlinie auf der Rolle: Ihr Principal identifiziert, wer diese Rolle übernehmen darf. Die Berechtigungsrichtlinie der Rolle definiert separat, was eine entstehende Sitzung tun darf.

Der Berichtsjob braucht jetzt eine temporäre Rollensitzung. Verwende die bekannten Felder Action und Resource für seine S3-Arbeit und eine separate Vertrauensrichtlinie für den Eintritt in die Rolle. Du prüfst beide Entscheidungen getrennt, bevor du den Zugriff entziehst.

Eine IAM-Rolle definiert Berechtigungen und wer sie übernehmen darf. AWS Security Token Service (STS) stellt temporäre Zugangsdaten für eine Rollensitzung aus, eine andere Identität als ihr Aufrufer.

Bestätige die ARN des Workers, damit du sie mit dem anfänglichen Vertrauen vergleichen kannst.

cd /home/labex/project

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

Erwarte arn:aws:iam::123456789012:user/report-worker. Beginne mit Vertrauen, das nur den Operator benennt. sts:AssumeRole fordert eine Rollensitzung an; Principal ist eine Identitäts-ARN und kein Profilname. Dem Worker wird bewusst noch nicht vertraut.

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

Erwarte die ARN, die mit role/ReportReader endet. Das Erstellen einer Rolle gibt ihr keine S3-Berechtigungen. Ergänze eine enge Inline-Richtlinie: Die Rolle darf GetObject nur für den heutigen Bericht ausführen, ihn weder schreiben noch Gehaltsdaten lesen.

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

Lies beide Dokumente zurück. Vertrauen steuert den Eintritt; Rollenberechtigungen steuern die Operationen der Sitzung. Dem Worker wird noch nicht vertraut. Teste diese Grenze und wähle dabei nur das sichere zurückgegebene ARN-Feld aus.

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

Erwarte AccessDenied. Entferne den Abfragefilter nicht: Eine ungefilterte erfolgreiche Antwort enthält Geheimnisse.

Autorisiere den Aufrufer und verwende ein Rollenprofil

In diesem Schritt erlaubst du dem Worker, ReportReader anzufordern, aktualisierst das Vertrauen der Rolle und verwendest ein Rollenprofil. Beide Testbenutzer erhalten dieselbe Aufruferberechtigung; nur der vertrauenswürdige Worker sollte die Rollensitzung erhalten.

Schreibe eine Aufruferrichtlinie, deren Resource die genaue Rollen-ARN ist, und füge sie dann an den Worker an.

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

Um die Vertrauensprüfung zu isolieren, gib dem Außenseiter dieselbe enge Aufruferberechtigung. Dieser entbehrliche Vergleichsbenutzer ist nicht im Vertrauensdokument enthalten.

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

Erwarte AccessDenied: Sein Identitäts-Allow überschreibt das vorhandene Vertrauen nicht, das nur den Operator benennt. Ersetze dieses Vertrauen durch den vorgesehenen Worker und aktualisiere die Rolle.

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

Erwarte AccessDenied, obwohl die Identitätsrichtlinie des Außenseiters AssumeRole erlaubt. Seiner ARN wird nicht vertraut. Wiederhole den Aufruf als Worker:

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

Das Vertrauen der Rolle entschied, welcher Aufrufer eintreten durfte. Ein Identitäts-Allow kann es nicht umgehen. Bei Vertrauen innerhalb desselben Kontos, das einen Benutzer direkt benennt, kann dieses Vertrauen den Eintritt ohne separates Identitäts-Allow gewähren; die gleichen Aufruferberechtigungen hier helfen, den Vertrauensvergleich zu isolieren.

Erwarte eine ARN, die mit assumed-role/ReportReader/report-run endet. Ein Sitzungsname hilft, Rollenverwendungen in Aktivitätsaufzeichnungen zu unterscheiden. Rollenzugangsdaten laufen ab; das CLI-Rollenprofil unten beschafft temporäre Zugangsdaten für dich.

Konfiguriere das vorbereitete Profil report-role so, dass es diese temporären Zugangsdaten automatisch anfordert. source_profile wählt den Aufrufer aus und role_arn die Zielrolle. Diese Einstellungen enthalten keine geheimen Werte. Die CLI speichert ihren temporären Cache sicher; gib ihn nicht aus.

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

Erwarte erneut die assumed-role-ARN. Die CLI führt für dieses Profil die STS-Authentifizierung intern aus. Die Worker-Identität selbst hat AssumeRole-Berechtigung und nicht die S3-Berechtigung der Rolle.

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

Erwarte AccessDenied. Das Übernehmen einer Rolle fügt ihre Berechtigungen nicht an den Quellbenutzer an.

Teste Ressourcen- und Aktionsgrenzen der Rollensitzung

In diesem Schritt verwendest du das Rollenprofil für die Berichtsaufgabe und bestätigst, dass es keine unbeteiligte Arbeit ausführen kann. Eine erfolgreiche AssumeRole-Anfrage beweist nur den Eintritt in die Rolle; tatsächliche S3-Anfragen beweisen ihren wirksamen Zugriff.

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

cat today.txt

Erwarte Daily orders: 145. Teste die zwei vorhandenen Ressourcen außerhalb der genauen Objekt-ARN der Rolle.

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

Beide müssen AccessDenied zurückgeben. Versuche dann, den heutigen Bericht mit dem bereitgestellten nicht freigegebenen Ersatz zu überschreiben. GetObject autorisiert PutObject nicht.

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

Erwarte PutObject AccessDenied und unverändertes Daily orders: 145. Eine fehlende lokale Datei, ein Fehler wegen abgelaufener Zugangsdaten oder ein nicht verfügbarer Dienst ist eine andere Diagnose und beweist keine Berechtigungsgrenze. AWS View zeigt das gespeicherte Vertrauen, die Rollenrichtlinie und tatsächliche Lesezugriffe der Rollensitzung; klappe den heutigen Bericht auf, um seine Bytes zu untersuchen.

Entziehe den Rollenzugriff und räume auf

In diesem Schritt entfernst du die Berichtsberechtigung der Rolle, bevor du ihre Daten löschst. Das Entfernen einer Rollenberechtigung und das Verhindern neuer Rollenübernahmen sind separate Aktionen; das alleinige Leeren eines lokalen Caches widerruft keine serverseitigen Berechtigungen.

Entferne ReportRead, während Rolle und Bericht noch existieren, und wiederhole dann den Lesezugriff über das Rollenprofil.

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

Erwarte AccessDenied. Entferne beide Aufruferberechtigungen und ersetze das direkte Worker-Vertrauen durch Vertrauen nur für den Operator. Das alleinige Entfernen eines Identitäts-Allow widerruft keine direkte Vertrauensberechtigung innerhalb desselben Kontos. Teste dann, dass der Worker keine neue Sitzung erhalten kann.

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

Erwarte AccessDenied, während die Rolle noch existiert. Lösche die Rolle erst nach diesen funktionalen Entzugsprüfungen.

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

Erwarte eine leere Rollenliste und KeyCount: 0 in der Objektantwort. Lösche den leeren eigenen Bucket und bestätige dann, dass die Referenz weiterhin mit ihren ursprünglichen Bytes existiert.

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

Nur der Referenz-Bucket mit Platform reference: keep bleibt erhalten. Diese erfolgreichen Abfragen belegen Löschung und Erhalt. Die entbehrliche Umgebung entfernt bei ihrem Ende vorbereitete Identitäten und temporäre Zugangsdaten-Dateien. Du hast die Rolle und die Aufruferberechtigungen entfernt, die für diese Übung erstellt wurden.

Zusammenfassung

Du hast das Vertrauen der Rolle von ihrer Berechtigungsrichtlinie getrennt, nachgewiesen, dass eine Aufruferberechtigung allein das Vertrauen nicht umgehen kann, und STS über ein CLI-Rollenprofil verwendet. Die Rollensitzung konnte nur ihren Bericht lesen und weder schreiben noch unbeteiligte Daten lesen. Du hast Rollen- und Aufruferberechtigungen vor der begrenzten Bereinigung entfernt. Bevorzuge temporäre Rollen gegenüber dauerhaften Workload-Schlüsseln und untersuche bei der Zugriffsdiagnose die tatsächliche Identität sowie erlaubte und verweigerte Anfragen.

Weitere Informationen bietet die AWS-Dokumentation: IAM-Rollen, Vertrauen und temporäre Anmeldeinformationen.