Accorder un accès limité à un lecteur de rapport

AWSBeginner
Pratiquer maintenant

Introduction

Un consommateur de rapports a besoin d'un rapport privé, pas de l'ensemble des accès au stockage de l'opérateur. Vous allez accorder un accès à portée limitée à son identité IAM indépendante, tester des requêtes réelles, puis révoquer l'autorisation tout en préservant les données du rapport.

Appuyez-vous sur les références de ressources et les lectures d'objets S3. Vous devez comprendre les éléments IAM Action et Resource ; les relations de confiance des rôles, les profils d'instance et les clés d'accès personnelles ne sont pas nécessaires. Les deux identités CLI sont préparées dans cet environnement neuf.

Liens avec les certifications

Certification Tâche de l'examen Mise en pratique
Cloud Practitioner (CLF-C02) Tâche 2.3 et 3.1 Gérer une stratégie d'identité de moindre privilège à travers une configuration d'infrastructure reproductible.
Developer – Associate (DVA-C02) Tâche 3.3, compétence 3.3.4 S'exercer aux bases du déploiement d'une définition d'infrastructure.
DevOps Engineer – Professional (DOP-C02) Tâche 2.1 S'exercer aux bases de la gestion des ressources à travers une définition IaC.
Solutions Architect – Associate (SAA-C03) Tâche 1.1 S'exercer aux bases de la définition du périmètre d'une stratégie IAM de lecteur et de l'évaluation des accès autorisés et refusés.

Vue conceptuelle des ressources de ce lab et des limites de préservation à respecter.

Préparer le rapport et observer le lecteur

Dans cette étape, vous allez créer le stockage du rapport et observer l'absence initiale d'accès d'un lecteur indépendant valide.

L'identité CLI par défaut gère l'infrastructure. Le profil reader fourni appartient à l'utilisateur IAM indépendant report-reader ; son accès n'est pas emprunté à l'opérateur. Créer un stockage n'autorise pas automatiquement cet utilisateur. Sélectionner un profil change l'identité qui signe une requête AWS, pas la ressource elle-même.

Créez un stockage de rapport dans le répertoire racine préparé :

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

Deux ajouts sont attendus. Appliquez et saisissez yes :

terraform apply

Tentez de lire le rapport avec le lecteur indépendant. || true permet à ce bloc de commandes de continuer après l'échec intentionnel ; cela ne transforme pas la requête en lecture réussie.

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

Le résultat attendu est AccessDenied. L'identité est valide, mais ne possède aucune autorisation correspondante. Gardez l'objet distinct team-reference-reports/keep.txt privé pendant tout le lab. AWS View utilise l'identité de l'opérateur pour inspecter le stockage ; y voir l'aperçu d'un objet ne prouve pas que le lecteur peut y accéder. AWS View après le déploiement : le stockage créé apparaît à côté du rapport de référence conservé.

Autoriser uniquement la lecture du rapport prévu

Dans cette étape, vous allez utiliser des références de ressources pour construire une stratégie d'identité IAM et vérifier les lectures autorisées et interdites.

Une stratégie d'identité intégrée est attachée directement à un utilisateur et lui accorde des actions. s3:GetObject s'applique à un ARN d'objet, pas à un ARN de bucket. jsonencode transforme une valeur Terraform en JSON valide ; vous pouvez donc utiliser les références de ressources HCL ordinaires au lieu de construire manuellement une chaîne JSON avec des caractères d'échappement.

Créez policy.tf. Le nom du lecteur est une donnée fournie ; l'ARN cible de la stratégie combine l'ARN du bucket créé et la clé de l'objet réel.

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

Le plan ajoute une stratégie tout en conservant le bucket et le rapport. Appliquez-la et saisissez yes :

terraform apply

Lisez la cible avec le même profil de lecteur :

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

Le résultat attendu est orders,12. Utilisez maintenant cette même identité pour un objet privé sans lien avec ce rapport :

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

Le résultat attendu est AccessDenied, sans téléchargement des données de référence. Cette stratégie accorde uniquement la lecture du rapport ; elle ne doit pas autoriser son écriture ni sa suppression. Des caractères génériques trop larges sur les actions ou les ressources peuvent créer un accès involontaire même si la lecture de la cible fonctionne. Le contrôle interprète la sémantique native de la stratégie et effectue des lectures réellement autorisées ou interdites ; il n'exige pas une disposition JSON particulière. Des expressions équivalentes sous forme de chaînes ou de listes et un préfixe limité aux rapports peuvent satisfaire cette tâche sans accorder de nouvelles actions.

Révoquer l'autorisation sans supprimer les données

Dans cette étape, vous allez supprimer la stratégie au moyen de Terraform et prouver que l'accès change tandis que le rapport est conservé.

Retirer un bloc de ressource propose la suppression de cette ressource gérée. Supprimez uniquement policy.tf, en laissant la configuration du stockage inchangée :

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

Une destruction de stratégie est attendue, sans suppression de bucket ni d'objet. Appliquez cet artefact enregistré :

terraform apply revoke.tfplan

Réessayez de lire la cible avec le même lecteur :

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

Le résultat attendu est AccessDenied. Une autorisation révoquée ne supprime pas un fichier local déjà téléchargé, et la présence de reader-report.csv ne prouve pas qu'une nouvelle requête est autorisée. Interrogez le rapport stocké avec l'identité d'opérateur par défaut :

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

Le rapport contient toujours orders,12. Vous avez changé la frontière d'autorisation sans modifier les données. Consultez les éléments des stratégies IAM pour distinguer Action et Resource.

Supprimer le stockage de rapport créé

Dans cette étape, vous allez nettoyer le stockage après avoir terminé les contrôles d'accès et de révocation.

Détruisez les ressources restantes de cette configuration racine et saisissez yes :

terraform destroy

Le bucket et l'objet de rapport sont supprimés ; le lecteur fourni et la référence de l'équipe appartiennent à l'environnement préparé et ne figurent pas dans l'état de cette configuration racine. Inspectez la correspondance finale et la référence conservée :

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

La liste de l'état est vide et la référence est conservée. Gardez les deux identités CLI préparées configurées jusqu'à la fin du contrôle final.

Résumé

Vous avez utilisé jsonencode et des références de ressources pour définir une stratégie d'identité IAM, testé des requêtes autorisées et interdites avec un lecteur indépendant, révoqué une autorisation sans supprimer les données du rapport et supprimé uniquement le stockage créé.