Der Anwendung Zugriff auf ihre Berichte geben

Einführung

Eine laufende Anwendung muss einen privaten Bericht lesen. Sie verbinden eine IAM-Rolle und ein Instanzprofil über Terraform-Referenzen, gewähren Zugriff auf das vorgesehene Objekt und testen die tatsächlichen Anfragen der Anwendung vor und nach dem Entfernen der Berechtigung.

Dieses Lab setzt Terraform-Referenzen und EC2-Bereitstellung sowie AWS-Rollenvertrauensbeziehungen, Instanzprofile und begrenzte S3-Berechtigungen voraus. Eine frische Umgebung stellt die laufende Anwendung, ihr Netzwerk, einen privaten Berichts-Bucket und eine unabhängige Referenzanwendung bereit. Sie erhalten die bereitgestellten Daten und die Referenzumgebung unverändert.

Bezug zu Zertifizierungen

Lab-Überblick

Der laufenden Anwendung eine Rollenidentität geben

In diesem Schritt definieren Sie eine EC2-Rolle und ein Instanzprofil, verknüpfen das Profil mit der bereitgestellten Anwendung und beobachten deren wirksame Laufzeitidentität.

Die obere Ansicht AWS View zeigt dieselben Ressourcen, die Sie in Terminal abfragen. Mit der Auswahl Request path können Sie den Anwendungszustand, die Laufzeitidentität oder eines der privaten Objekte anfordern. Terminal verwendet die vorbereitete verwaltende Identität; die Anwendung verwendet ihre eigene Instanzrolle. Eine erfolgreiche Abfrage der verwaltenden Identität beweist nicht, dass die Anwendung berechtigt ist.

Untersuchen Sie das vorbereitete Root-Modul und halten Sie die Instanz-ID fest:

cd /home/labex/project/application-reports
cat terraform.tfvars.json
cat application.tf
terraform state list
INSTANCE_ID=$(terraform output -raw instance_id)
echo "$INSTANCE_ID"
REPORT_BUCKET=$(terraform output -raw report_bucket)
echo "$REPORT_BUCKET"

Der vorhandene State verwaltet die Anwendungsinstanz. Netzwerk, AMI, Bucket und Referenzanwendung wurden separat bereitgestellt. User Data verweisen die Anwendung bereits auf report.csv im vorbereiteten Bucket, enthalten jedoch keinen Zugriffsschlüssel.

Wählen Sie in AWS View application-server, User · 198.51.100.10, Application · 8081 und Health aus und klicken Sie auf Send request. Erwarten Sie Connected · 200 und Report application. Wählen Sie Private report und senden Sie erneut. Die Anwendung kann ihn noch nicht lesen und meldet Connected · 503 mit Application storage unavailable: Die HTTP-Anwendung ist erreichbar, hat jedoch keine Laufzeitzugangsdaten.

Die Vertrauensrichtlinie einer IAM-Rolle steuert, wer sie übernehmen kann. Ein Instanzprofil verbindet die Rolle mit EC2. Keines der beiden Objekte gewährt für sich genommen die Berechtigung, ein S3-Objekt zu lesen. Erstellen Sie diese beiden Ressourcen:

cat > identity.tf <<'HCL'
resource "aws_iam_role" "reports" {
  name = "tf-report-reader"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Principal = { Service = "ec2.amazonaws.com" }
      Action = "sts:AssumeRole"
    }]
  })
}

resource "aws_iam_instance_profile" "reports" {
  name = "tf-report-reader"
  role = aws_iam_role.reports.name
}
HCL
sed -i '/vpc_security_group_ids/a\  iam_instance_profile = aws_iam_instance_profile.reports.name' application.tf
terraform fmt
terraform validate
terraform plan

Der Befehl sed fügt das Instanzprofilattribut nach dem vorhandenen Sicherheitsgruppenattribut ein. Seine Ressourcenreferenz verbindet die laufende Instanz mit dem Profil, das auf die Rolle verweist. Prüfen Sie den Plan: Rolle und Profil werden erstellt und die vorhandene Instanzzuordnung aktualisiert, ohne die Instanz zu ersetzen oder User Data zu ändern.

Wenden Sie die Konfiguration an und geben Sie yes ein:

terraform apply

Untersuchen Sie die native Zuordnung und das Profil:

aws ec2 \
  describe-iam-instance-profile-associations \
  --filters "Name=instance-id,Values=$INSTANCE_ID" \
  --query 'IamInstanceProfileAssociations[].{Instance:InstanceId,State:State,Profile:IamInstanceProfile.Arn}'
aws iam \
  get-instance-profile \
  --instance-profile-name tf-report-reader \
  --query 'InstanceProfile.{Name:InstanceProfileName,Roles:Roles[].RoleName}'

Wählen Sie in AWS View Workload identity für application-server aus und senden Sie eine Anfrage. Erwarten Sie Connected · 200 und einen ARN, der assumed-role/tf-report-reader/ enthält. Dieser stammt von STS im Gastsystem unter Verwendung temporärer Rollenzugangsdaten und nicht von der verwaltenden Identität in Terminal.

Wählen Sie Private report und senden Sie erneut. Erwarten Sie Connected · 403 und Access denied. Die Rollenidentität funktioniert jetzt, aber es gibt noch keine Objektleseberechtigung. Dies ist ein beabsichtigter Autorisierungsfehler.

Nur Zugriff auf den vorgesehenen Bericht gewähren

In diesem Schritt gewähren Sie der Anwendungsrolle eine Objektleseberechtigung und testen sowohl den erlaubten Bericht als auch ein unabhängiges privates Objekt.

Die Berechtigungsrichtlinie einer Rolle legt fest, was ihre Sitzung tun darf. Verwenden Sie eine Identitätsrichtlinie, die s3:GetObject für den exakten ARN von report.csv erlaubt. Der Bucket-Name stammt aus der bereitgestellten Eingabe; die Rolle aus der Ressourcenreferenz. Statische Zugangsdaten gehören nicht in User Data.

cat > permissions.tf <<'HCL'
resource "aws_iam_role_policy" "report" {
  name = "ReadApplicationReport"
  role = aws_iam_role.reports.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Action = ["s3:GetObject"]
      Resource = ["arn:aws:s3:::${var.report_bucket}/report.csv"]
    }]
  })
}
HCL
terraform fmt
terraform validate
terraform plan

Der Plan fügt eine Richtlinie hinzu. Er darf die Anwendung nicht ersetzen oder einen neuen Bucket erstellen. Wenden Sie ihn an und geben Sie yes ein:

terraform apply

Lassen Sie in AWS View application-server, User und Port 8081 ausgewählt. Wählen Sie Private report und senden Sie eine Anfrage. Erwarten Sie Connected · 200 mit dem Bericht:

period,total
Q1,320

Wählen Sie Unrelated private object und senden Sie eine weitere Anfrage. Erwarten Sie Connected · 403 und Access denied. Die Anwendung kann ihren eigenen Bericht lesen, während private.csv außerhalb der Berechtigung bleibt. Dieser 403 ist ein tatsächliches S3-Autorisierungsergebnis, das von der erreichten Anwendung zurückgegeben wird, und keine fehlgeschlagene Netzwerkverbindung.

Wechseln Sie zurück zu Workload identity und senden Sie erneut. Der ARN muss weiterhin die Anwendungsrolle kennzeichnen. Bestätigen Sie den übereinstimmenden Zustand:

terraform plan

Erwarten Sie No changes.

Die Berechtigung widerrufen und die tatsächliche Wirkung testen

In diesem Schritt entfernen Sie ausschließlich die Leserichtlinie und weisen nach, dass eine laufende Anwendung mit gültiger Rollenidentität keinen Berichtszugriff mehr hat.

Das Entfernen einer Berechtigung unterscheidet sich vom Trennen des Profils oder Stoppen der Instanz. Lassen Sie Rolle und Profil bestehen, entfernen Sie die Konfiguration der Richtlinienressource und prüfen Sie anschließend die Löschung:

rm permissions.tf
terraform plan

Erwarten Sie die Löschung der Leserichtlinie ohne Ersetzung der Instanz. Wenden Sie die Änderung an und geben Sie yes ein:

terraform apply

Lesen Sie die Namen der verbleibenden Inline-Richtlinien unabhängig davon aus:

aws iam \
  list-role-policies \
  --role-name tf-report-reader \
  --query PolicyNames

Erwarten Sie []. Senden Sie in AWS View eine Workload identity-Anfrage für die Anwendung. Sie liefert weiterhin Connected · 200 mit demselben Rollennamen zurück. Senden Sie anschließend Anfragen für Private report und Unrelated private object. Beide müssen Connected · 403 und Access denied zurückgeben. Der verweigerte Lesezugriff beweist, dass das Entfernen der Berechtigung tatsächliche Anwendungsanfragen beeinflusst, obwohl die Anwendung und ihre Rollenzuordnung weiterhin existieren.

terraform plan

Erwarten Sie No changes.

Verwaltete Ressourcen entfernen und bereitgestellte Daten erhalten

In diesem Schritt entfernen Sie die verwaltete Instanz, das Profil und die Rolle und erhalten dabei den externen Berichts-Bucket, dessen Objekte und die Referenzumgebung.

Die Richtlinie wurde bereits entfernt. Prüfen Sie den verbleibenden Löschumfang:

terraform plan -destroy

Erwarten Sie die drei verwalteten Ressourcen: die Anwendungsinstanz, das Instanzprofil und die IAM-Rolle. Löschen Sie sie anschließend und geben Sie yes ein:

terraform destroy

Dieselbe Instanz muss im nativen Instanzzustand als terminiert erscheinen:

aws ec2 \
  describe-instances \
  --instance-ids "$INSTANCE_ID" \
  --query 'Reservations[].Instances[].{ID:InstanceId,State:State.Name}'
terraform state list

Erwarten Sie terminated und keine verwalteten Ressourcen im State. Fragen Sie Rollen- und Profillisten anhand der exakten Namen ab; erfolgreiche leere Listen belegen das Fehlen, ohne einen Authentifizierungsfehler als Bereinigung zu behandeln:

aws iam list-roles --query "Roles[?RoleName=='tf-report-reader'].RoleName"
aws iam list-instance-profiles --query "InstanceProfiles[?InstanceProfileName=='tf-report-reader'].InstanceProfileName"

Beide geben [] zurück. Der Bucket wurde außerhalb dieses States bereitgestellt. Verwenden Sie die verwaltende Identität in Terminal, um beide erhaltenen Objekte zu lesen und ihre Bytes zu prüfen. Diese Lesezugriffe prüfen den Datenerhalt; der begrenzte Anwendungszugriff wurde separat über ihre Rolle getestet.

aws s3api get-object --bucket "$REPORT_BUCKET" --key report.csv /tmp/retained-report.csv
cat /tmp/retained-report.csv
aws s3api get-object --bucket "$REPORT_BUCKET" --key private.csv /tmp/retained-private.csv
cat /tmp/retained-private.csv

Der Bericht bleibt period,total / Q1,320; das unabhängige Objekt bleibt private,retained. Wählen Sie in AWS View reference-server, User, Application · 8081 und Health aus und senden Sie eine Anfrage. Erwarten Sie Connected · 200 und Reference application.

Behalten Sie die Terraform-Dateien zur Durchsicht bei. Ein späterer gewöhnlicher Plan würde die Neuerstellung der verbleibenden Konfiguration vorschlagen; eine erfolgreiche Löschung erfordert nicht, diese Konfiguration zu entfernen.

Zusammenfassung

Sie haben die Instanz einer Anwendung über Terraform-Referenzen mit einer Rolle verbunden, Rollenidentität von Objektberechtigung unterschieden und sowohl einen erfolgreichen Lesezugriff auf einen privaten Bericht als auch die Verweigerung eines unabhängigen Objekts getestet. Anschließend haben Sie die Berechtigung widerrufen, den tatsächlichen Autorisierungsfehler beobachtet und verwaltete Ressourcen entfernt, während bereitgestellte Daten und die Referenzanwendung erhalten blieben.