Donner à l’application accès à ses rapports

Introduction

Une application en cours d'exécution doit lire un rapport privé. Vous allez relier un rôle IAM et un profil d'instance par des références Terraform, accorder l'accès à l'objet prévu et tester les requêtes réelles de l'application avant et après la suppression de l'autorisation.

Ce lab suppose la connaissance des références Terraform et du déploiement EC2, ainsi que des relations de confiance des rôles AWS, des profils d'instance et des autorisations S3 à portée limitée. Un environnement neuf fournit l'application en cours d'exécution, son réseau, un bucket de rapports privé et une application de référence indépendante. Vous garderez les données fournies et l'environnement de référence intacts.

Liens avec les certifications

Aperçu du lab

Donner une identité de rôle à l'application en cours d'exécution

Dans cette étape, vous allez définir un rôle EC2 et un profil d'instance, attacher le profil à l'application fournie et observer son identité effective de charge de travail.

AWS View, dans la partie supérieure, affiche les mêmes ressources que celles interrogées dans Terminal. Son sélecteur Request path peut demander l'état de santé de l'application, l'identité de la charge de travail ou l'un des deux objets privés. Terminal utilise l'identité d'opérateur préparée ; l'application utilise son propre rôle d'instance. Une requête réussie de l'opérateur ne prouve pas que l'application possède l'autorisation.

Inspectez la configuration racine préparée et notez l'identifiant de l'instance :

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"

L'état existant gère l'instance d'application. Le réseau, l'AMI, le bucket et l'application de référence ont été fournis séparément. User Data pointe déjà l'application vers report.csv dans le bucket préparé, mais ne contient aucune clé d'accès.

Dans AWS View, sélectionnez application-server, User · 198.51.100.10, Application · 8081 et Health, puis cliquez sur Send request. Les résultats attendus sont Connected · 200 et Report application. Choisissez Private report et envoyez à nouveau une requête. L'application ne peut pas encore le lire et indique Connected · 503 avec Application storage unavailable : l'application HTTP est accessible, mais elle ne possède pas d'identifiants de charge de travail.

La stratégie de confiance d'un rôle IAM contrôle qui peut l'assumer. Un profil d'instance relie le rôle à EC2. Aucun de ces objets n'accorde, à lui seul, l'autorisation de lire un objet S3. Créez ces deux ressources :

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

La commande sed insère l'attribut de profil d'instance après l'attribut existant de groupe de sécurité. Sa référence de ressource relie l'instance en cours d'exécution au profil, qui référence le rôle. Examinez le plan : créer le rôle et le profil et mettre à jour l'association de l'instance existante, sans remplacer l'instance ni modifier User Data.

Appliquez et saisissez yes :

terraform apply

Inspectez l'association native et le 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}'

Dans AWS View, choisissez Workload identity pour application-server et envoyez une requête. Les résultats attendus sont Connected · 200 et un ARN contenant assumed-role/tf-report-reader/. Ce résultat provient de STS à l'intérieur de la machine invitée utilisant des identifiants temporaires de rôle, pas de l'opérateur Terminal.

Choisissez Private report et envoyez à nouveau une requête. Les résultats attendus sont Connected · 403 et Access denied. L'identité de rôle fonctionne maintenant, mais aucune autorisation de lecture d'objet n'existe encore. Il s'agit d'un échec d'autorisation intentionnel.

Accorder l'accès uniquement au rapport prévu

Dans cette étape, vous allez accorder au rôle de l'application une autorisation de lecture d'objet et tester le rapport autorisé ainsi qu'un objet privé indépendant.

La stratégie d'autorisation d'un rôle définit ce que sa session peut faire. Utilisez une stratégie d'identité autorisant s3:GetObject pour l'ARN exact de report.csv. Le nom du bucket provient de l'entrée fournie ; le rôle provient de la référence de ressource. Aucun identifiant statique ne doit figurer dans 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

Le plan ajoute une stratégie. Il ne doit pas remplacer l'application ni créer un nouveau bucket. Appliquez et saisissez yes :

terraform apply

Dans AWS View, gardez application-server, User et le port 8081 sélectionnés. Choisissez Private report et envoyez une requête. Le résultat attendu est Connected · 200, avec le rapport :

period,total
Q1,320

Choisissez Unrelated private object et envoyez une autre requête. Les résultats attendus sont Connected · 403 et Access denied. L'application peut lire son propre rapport tandis que private.csv reste en dehors de l'autorisation. Ce 403 est un véritable résultat d'autorisation S3 renvoyé par l'application atteinte, pas un échec de connexion réseau.

Revenez à Workload identity et envoyez à nouveau une requête. Son ARN doit toujours identifier le rôle de la charge de travail. Confirmez la convergence :

terraform plan

Le résultat attendu est No changes.

Révoquer l'autorisation et tester son effet réel

Dans cette étape, vous allez supprimer uniquement la stratégie de lecture et démontrer qu'une application en cours d'exécution avec une identité de rôle valide n'a plus accès au rapport.

Retirer une autorisation diffère du détachement du profil ou de l'arrêt de l'instance. Gardez le rôle et le profil en place, retirez la configuration de ressource de la stratégie, puis examinez la suppression :

rm permissions.tf
terraform plan

La stratégie de lecture doit être détruite, sans remplacement d'instance. Appliquez et saisissez yes :

terraform apply

Lisez indépendamment les noms des stratégies intégrées restantes :

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

Le résultat attendu est []. Dans AWS View, envoyez une requête Workload identity pour l'application. Elle renvoie toujours Connected · 200 avec le même nom de rôle. Envoyez ensuite des requêtes Private report et Unrelated private object. Les deux doivent renvoyer Connected · 403 et Access denied. Le refus de lecture prouve que la suppression de l'autorisation affecte les requêtes réelles de la charge de travail, même si l'application et son association de rôle existent toujours.

terraform plan

Le résultat attendu est No changes.

Supprimer les ressources gérées et garder les données fournies

Dans cette étape, vous allez supprimer l'instance, le profil et le rôle gérés tout en conservant le bucket de rapports externe, ses objets et l'environnement de référence.

La stratégie a déjà été supprimée. Examinez le périmètre de suppression restant :

terraform plan -destroy

Les trois ressources gérées sont attendues : l'instance d'application, le profil d'instance et le rôle IAM. Détruisez-les ensuite et saisissez yes :

terraform destroy

La même instance doit être terminée selon l'API native :

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

Les résultats attendus sont terminated et aucune ressource gérée dans l'état. Interrogez les listes de rôles et de profils avec les noms exacts ; des listes vides obtenues avec succès établissent l'absence sans traiter un échec d'authentification comme un nettoyage réussi :

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

Les deux renvoient []. Le bucket a été fourni en dehors de cet état. Utilisez l'opérateur Terminal pour lire les deux objets conservés et inspecter leurs octets. Ces lectures par l'opérateur contrôlent la préservation ; l'accès restreint de l'application a été testé séparément via son rôle.

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

Le rapport reste period,total / Q1,320 ; l'objet indépendant reste private,retained. Dans AWS View, sélectionnez reference-server, User, Application · 8081 et Health, puis envoyez une requête. Les résultats attendus sont Connected · 200 et Reference application.

Conservez les fichiers Terraform pour examen. Un plan ordinaire ultérieur proposerait de recréer la configuration restante ; une destruction réussie n'exige pas la suppression de cette configuration.

Résumé

Vous avez relié l'instance d'une application à un rôle par des références Terraform, distingué l'identité de rôle de l'autorisation sur un objet et testé une lecture réussie de rapport privé ainsi qu'un refus d'accès à un objet indépendant. Vous avez ensuite révoqué l'autorisation, observé l'échec réel d'autorisation et supprimé les ressources gérées tout en préservant les données fournies et l'application de référence.