Einem Berichtsleser begrenzten Zugriff gewähren

AWSBeginner
Jetzt üben

Einführung

Ein Berichtsnutzer benötigt einen privaten Bericht und nicht den gesamten Speicherzugriff der verwaltenden Identität. Sie gewähren seiner unabhängigen IAM-Identität begrenzten Zugriff, testen tatsächliche Anfragen und widerrufen anschließend die Berechtigung, während die Berichtsdaten erhalten bleiben.

Bauen Sie auf Ressourcenreferenzen und dem Lesen von S3-Objekten auf. Sie sollten die IAM-Elemente Action und Resource verstehen; Rollenvertrauensbeziehungen, Instanzprofile und persönliche Zugriffsschlüssel sind nicht erforderlich. Beide CLI-Identitäten sind in dieser frischen Umgebung vorbereitet.

Bezug zu Zertifizierungen

Zertifizierung Prüfungsaufgabe Übung
Cloud Practitioner (CLF-C02) Task 2.3 und 3.1 Eine Identitätsrichtlinie nach dem Prinzip der geringsten Rechte über wiederholbare Infrastrukturkonfiguration verwalten.
Developer – Associate (DVA-C02) Task 3.3, Skill 3.3.4 Grundlagenübung zur Bereitstellung einer Infrastrukturdefinition.
DevOps Engineer – Professional (DOP-C02) Task 2.1 Grundlagenübung zur Verwaltung von Ressourcen über eine IaC-Definition.
Solutions Architect – Associate (SAA-C03) Task 1.1 Grundlagenübung zum Begrenzen einer IAM-Leserichtlinie und zum Prüfen erlaubter und verweigerter Zugriffe.

Konzeptübersicht der tatsächlichen Ressourcen und der Grenzen zum Erhalt bestehender Ressourcen in diesem Lab.

Den Bericht vorbereiten und die Leseidentität beobachten

In diesem Schritt erstellen Sie den Berichtsspeicher und beobachten, dass eine gültige unabhängige Leseidentität zunächst keinen Zugriff hat.

Die standardmäßige CLI-Identität verwaltet die Infrastruktur. Das bereitgestellte Profil reader gehört zum unabhängigen IAM-Benutzer report-reader; dessen Zugriff wird nicht von der verwaltenden Identität übernommen. Das Erstellen von Speicher berechtigt diesen Benutzer nicht automatisch. Die Profilauswahl ändert die signierende Identität einer AWS-Anfrage und nicht die Ressource selbst.

Erstellen Sie einen Berichtsspeicher im vorbereiteten Stammverzeichnis:

cd /home/labex/project/reader-access
cat > main.tf <<'EOF'
resource "aws_s3_bucket" "reports" {
  bucket = "terraform-reader-reports"
}
resource "aws_s3_object" "report" {
  bucket       = aws_s3_bucket.reports.id
  key          = "reports/current.csv"
  content      = "orders,12\n"
  content_type = "text/csv"
}
EOF
terraform init
terraform plan

Erwarten Sie zwei Erstellungen. Wenden Sie die Konfiguration an und geben Sie yes ein:

terraform apply

Versuchen Sie, den Bericht mit der unabhängigen Leseidentität zu lesen. || true lässt diesen Befehlsblock nach dem beabsichtigten Fehler fortfahren; es macht aus der Anfrage keinen erfolgreichen Lesezugriff.

aws s3api \
  get-object \
  --profile reader \
  --bucket terraform-reader-reports \
  --key reports/current.csv \
  reader-report.csv || true

Erwarten Sie AccessDenied. Die Identität ist gültig, hat jedoch keine passende Berechtigung. Halten Sie das separate Objekt team-reference-reports/keep.txt während des gesamten Labs privat. AWS View verwendet die verwaltende Identität, um den Speicher zu untersuchen; eine Objektvorschau dort beweist nicht, dass die Leseidentität darauf zugreifen kann. AWS View nach der Bereitstellung: Der tatsächlich erstellte eigene Speicher erscheint neben dem erhaltenen Referenzbericht.

Nur das Lesen des vorgesehenen Berichts erlauben

In diesem Schritt erstellen Sie mit Ressourcenreferenzen eine IAM-Identitätsrichtlinie und überprüfen sowohl erlaubte als auch verbotene Lesezugriffe.

Eine Inline-Identitätsrichtlinie wird direkt an einen Benutzer angefügt und gewährt diesem Benutzer Aktionen. s3:GetObject gilt für einen Objekt-ARN und nicht für einen Bucket-ARN. jsonencode wandelt einen Terraform-Wert in gültiges JSON um. So können Sie gewöhnliche HCL-Ressourcenreferenzen verwenden, statt manuell eine JSON-Zeichenfolge mit Escape-Sequenzen aufzubauen.

Erstellen Sie policy.tf. Der Name der Leseidentität ist vorgegeben; der Ziel-ARN der Richtlinie kombiniert den ARN des erstellten Buckets mit dem Schlüssel des tatsächlichen Objekts.

cat > policy.tf <<'EOF'
resource "aws_iam_user_policy" "reader" {
  name = "ReadReport"
  user = "report-reader"
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect   = "Allow"
      Action   = "s3:GetObject"
      Resource = "${aws_s3_bucket.reports.arn}/${aws_s3_object.report.key}"
    }]
  })
}
EOF
terraform plan

Der Plan fügt eine Richtlinie hinzu und erhält dabei Bucket und Bericht. Wenden Sie ihn an und geben Sie yes ein:

terraform apply

Lesen Sie das Ziel mit demselben reader-Profil:

aws s3api \
  get-object \
  --profile reader \
  --bucket terraform-reader-reports \
  --key reports/current.csv \
  reader-report.csv
cat reader-report.csv

Erwarten Sie orders,12. Verwenden Sie nun dieselbe Identität für ein unabhängiges privates Objekt:

aws s3api \
  get-object \
  --profile reader \
  --bucket team-reference-reports \
  --key keep.txt \
  unrelated-report.txt || true

Erwarten Sie AccessDenied und keine heruntergeladenen Referenzdaten. Diese Richtlinie gewährt nur das Lesen von Berichten; sie darf weder das Schreiben noch das Löschen von Berichten erlauben. Weit gefasste Platzhalter für Aktionen oder Ressourcen können unbeabsichtigten Zugriff ermöglichen, selbst wenn das Lesen des Ziels funktioniert. Die Prüfung wertet die native Richtliniensemantik aus und führt tatsächlich erlaubte und verbotene Leseanfragen aus; sie verlangt kein bestimmtes JSON-Layout. Gleichwertige Zeichenfolgen-/Listenausdrücke und ein ausschließlich auf Berichte begrenztes Präfix können diese Aufgabe erfüllen, ohne neue Aktionen zu erlauben.

Die Berechtigung widerrufen, ohne Daten zu löschen

In diesem Schritt entfernen Sie die Richtlinie mit Terraform und weisen nach, dass sich der Zugriff ändert, während der Bericht erhalten bleibt.

Das Entfernen eines Ressourcenblocks schlägt die Entfernung dieser verwalteten Ressource vor. Löschen Sie nur policy.tf und lassen Sie die Speicherkonfiguration unverändert:

rm policy.tf
terraform plan -out=revoke.tfplan
terraform show revoke.tfplan

Erwarten Sie die Löschung einer Richtlinie und keine Löschung von Bucket oder Objekt. Führen Sie dieses gespeicherte Artefakt aus:

terraform apply revoke.tfplan

Versuchen Sie erneut, das Ziel mit derselben Leseidentität zu lesen:

aws s3api \
  get-object \
  --profile reader \
  --bucket terraform-reader-reports \
  --key reports/current.csv \
  after-revoke.csv || true

Erwarten Sie AccessDenied. Eine widerrufene Berechtigung entfernt keine bereits heruntergeladene lokale Datei, und das Vorhandensein von reader-report.csv beweist nicht, dass eine neue Anfrage berechtigt ist. Fragen Sie den gespeicherten Bericht mit der standardmäßigen verwaltenden Identität ab:

aws s3api \
  get-object \
  --bucket terraform-reader-reports \
  --key reports/current.csv \
  retained-report.csv
cat retained-report.csv

Der Bericht enthält weiterhin orders,12. Sie haben die Berechtigungsgrenze geändert, ohne Daten zu verändern. Informationen zum Unterschied zwischen Action und Resource finden Sie unter IAM-Richtlinienelemente.

Den eigenen Berichtsspeicher entfernen

In diesem Schritt bereinigen Sie den Speicher, nachdem Sie die Zugriffs- und Widerrufsprüfungen abgeschlossen haben.

Löschen Sie die verbleibenden Ressourcen dieses Root-Moduls und geben Sie yes ein:

terraform destroy

Bucket und Berichtsobjekt werden entfernt; die bereitgestellte Leseidentität und die Teamreferenz gehören zur vorbereiteten Umgebung und befinden sich nicht im State dieses Root-Moduls. Untersuchen Sie die abschließende Zuordnung und die erhaltene Referenz:

terraform state list
aws s3api \
  list-buckets \
  --query 'Buckets[].Name'
aws s3api \
  head-object \
  --bucket team-reference-reports \
  --key keep.txt \
  --query ContentLength

Die State-Liste ist leer und die Referenz bleibt erhalten. Lassen Sie beide vorbereiteten CLI-Identitäten konfiguriert, bis die abschließende Prüfung abgeschlossen ist.

Zusammenfassung

Sie haben mit jsonencode und Ressourcenreferenzen eine IAM-Identitätsrichtlinie definiert, erlaubte und verbotene Anfragen mit einer unabhängigen Leseidentität getestet, die Berechtigung widerrufen, ohne Berichtsdaten zu löschen, und ausschließlich den eigenen Speicher entfernt.