IAM AWS : utilisateurs, groupes, rôles et politiques

À la fin de ce tutoriel, vous saurez modéliser les accès IAM pour un lab : groupe plutôt qu’attach direct, politique customer managed en JSON, rôle EC2 avec instance profile, et un assume-role testé en CLI.

Niveau : Débutant → Intermédiaire · Temps estimé : 60–75 min · Versions testées : IAM Console 2026, AWS CLI v2 · Dernière vérification : 2026-09-10

Slug proposé : aws-iam-users-groupes-roles-politiques · Série : AWS Solutions Architect

← Précédent : Démarrer avec AWS (compte, root MFA, admin-lab, budget, CLI)

Prérequis

• Compte AWS lab avec utilisateur IAM admin-lab + MFA (tutoriel précédent)
• AWS CLI v2 configurée (aws sts get-caller-identity --profile lab OK)
• Region de lab notée (ex. eu-west-3 ou ca-central-1)
• Aucune access key sur le root

Coût estimé : 0 € (IAM est gratuit). Les ressources EC2 éventuelles pour tester le rôle sont hors scope ici — on crée le rôle et l’instance profile seulement.

Ce que nous allons construire

Compte AWS
├── Groupe IAM lab-admins
│   └── Politique gérée AWS : ReadOnlyAccess (exemple de groupe)
├── Politique customer managed LabS3ListLabPrefix
│   └── Autorise s3:ListBucket / s3:GetObject sur lab-* seulement
├── Groupe lab-s3-readers (+ user de démo optionnel)
└── Rôle lab-ec2-role
    ├── Trust policy : ec2.amazonaws.com
    ├── Permissions : LabS3ListLabPrefix
    └── Instance profile lab-ec2-profile

(Schéma à remplacer par Excalidraw / draw.io — alt : « IAM users, groups, customer policy et rôle EC2 ».)

Étape 1 — Le modèle IAM en une page

Identité	Qu’est-ce que c’est	Cas d’usage lab
User	Personne ou compte de service avec mot de passe et/ou access keys	Vous (admin-lab), un collègue
Group	Collection de users ; on attache des politiques au groupe	lab-admins, lab-s3-readers
Role	Identité assumable (pas de mot de passe long terme)	EC2, Lambda, accès cross-account
Policy	Document JSON d’autorisations	AdministratorAccess, ou votre JSON custom

Deux familles de politiques à ne pas confondre :

• Identity-based : attachées à user / group / role (« que peut faire cette identité ? »).
• Resource-based : sur la ressource elle-même (ex. bucket policy S3, trust policy d’un rôle). La trust policy d’un rôle dit qui peut l’assumer ; les permissions du rôle disent ce qu’il peut faire une fois assumé.

Types de politiques identity-based :

Type	Qui la gère	Quand l’utiliser
AWS managed	AWS	Démarrer vite (ReadOnlyAccess, AmazonS3ReadOnlyAccess)
Customer managed	Vous	Lab et prod : réutilisable, versionnable, moindre privilège
Inline	Collée à une seule identité	À éviter en lab (difficile à auditer / réutiliser)

Étape 2 — Bonnes pratiques lab (à graver)

1. Jamais le root au quotidien (déjà fait).
2. MFA sur tout user humain.
3. Groupes d’abord : permissions sur le groupe, users membres — pas 15 politiques collées user par user.
4. Customer managed dès que vous sortez du « tout AWS managed ».
5. Access keys : une par usage, rotation, désactivation immédiate si fuite ; préférez SSO / rôles quand vous pourrez.
6. Moindre privilège : commencez ReadOnly, élargissez avec une action précise — pas * « pour plus tard ».

Étape 3 — Créer le groupe lab-admins

Console (connecté en admin-lab) :

1. IAM → User groups → Create group.
2. Nom : lab-admins.
3. Attach policy : ReadOnlyAccess (AWS managed) pour l’exemple « admins de lecture » — ou AdministratorAccess si ce groupe remplace l’attach direct sur admin-lab.
4. Créez le groupe, puis Add users → cochez admin-lab.

Équivalent CLI :

aws iam create-group --group-name lab-admins --profile lab

aws iam attach-group-policy 
  --group-name lab-admins 
  --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess 
  --profile lab

aws iam add-user-to-group 
  --group-name lab-admins 
  --user-name admin-lab 
  --profile lab

Vérification :

aws iam get-group --group-name lab-admins --profile lab
aws iam list-attached-group-policies --group-name lab-admins --profile lab

Étape 4 — Politique customer managed (S3 préfixe lab-*)

Objectif : autoriser uniquement la liste / lecture sur des buckets dont le nom commence par lab-.

Créez le fichier local lab-s3-list-lab-prefix.json :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListLabBuckets",
      "Effect": "Allow",
      "Action": ["s3:ListAllMyBuckets"],
      "Resource": "*"
    },
    {
      "Sid": "ListBucketIfLabPrefix",
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": "arn:aws:s3:::lab-*"
    },
    {
      "Sid": "ReadObjectsInLabBuckets",
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::lab-*/*"
    }
  ]
}

Notes pédagogiques :

• Version est toujours 2012-10-17 pour les politiques IAM modernes.
• ListAllMyBuckets demande Resource: * (contrainte API S3) — d’où un droit large de liste des noms seulement.
• Les ARN lab-* limitent ListBucket / GetObject au préfixe de nom.

Création + attach à un groupe dédié :

aws iam create-policy 
  --policy-name LabS3ListLabPrefix 
  --policy-document file://lab-s3-list-lab-prefix.json 
  --profile lab

aws iam create-group --group-name lab-s3-readers --profile lab

# Remplacez ACCOUNT_ID par vos 12 chiffres (sts get-caller-identity)
aws iam attach-group-policy 
  --group-name lab-s3-readers 
  --policy-arn arn:aws:iam::ACCOUNT_ID:policy/LabS3ListLabPrefix 
  --profile lab

Pour récupérer l’ARN sans le retaper :

aws iam list-policies --scope Local --query 
  "Policies[?PolicyName=='LabS3ListLabPrefix'].Arn" 
  --output text --profile lab

(Option) Créez un user reader-demo, mot de passe console, MFA, membre de lab-s3-readers seulement — pour vérifier qu’il ne peut pas lancer EC2.

Étape 5 — Rôle EC2 + instance profile

Un rôle EC2 permet à une instance d’appeler AWS sans access key sur le disque.

Trust policy (lab-ec2-trust.json)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "ec2.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }
  ]
}

Créer rôle, permissions, instance profile

aws iam create-role 
  --role-name lab-ec2-role 
  --assume-role-policy-document file://lab-ec2-trust.json 
  --profile lab

POLICY_ARN=$(aws iam list-policies --scope Local --query 
  "Policies[?PolicyName=='LabS3ListLabPrefix'].Arn" 
  --output text --profile lab)

aws iam attach-role-policy 
  --role-name lab-ec2-role 
  --policy-arn "$POLICY_ARN" 
  --profile lab

aws iam create-instance-profile 
  --instance-profile-name lab-ec2-profile 
  --profile lab

aws iam add-role-to-instance-profile 
  --instance-profile-name lab-ec2-profile 
  --role-name lab-ec2-role 
  --profile lab

En console : IAM → Roles → Create role → AWS service → EC2 → attachez LabS3ListLabPrefix → nom lab-ec2-role. L’instance profile du même nom est souvent créé automatiquement via l’UI.

Quand vous lancerez une EC2 (tuto suivant), sélectionnez IAM instance profile = lab-ec2-profile.

Étape 6 — Démo assume-role en CLI (sans EC2)

Pour expérimenter le mécanisme STS sans machine, créez un rôle assumable par votre user (lab uniquement).

Trust policy lab-admin-trust.json (remplacez ACCOUNT_ID et le nom d’user) :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::ACCOUNT_ID:user/admin-lab"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

aws iam create-role 
  --role-name lab-assume-demo 
  --assume-role-policy-document file://lab-admin-trust.json 
  --profile lab

aws iam attach-role-policy 
  --role-name lab-assume-demo 
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess 
  --profile lab

aws sts assume-role 
  --role-arn arn:aws:iam::ACCOUNT_ID:role/lab-assume-demo 
  --role-session-name demo-session 
  --profile lab

La sortie contient AccessKeyId, SecretAccessKey, SessionToken temporaires. Exemple d’usage :

export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...
aws sts get-caller-identity
# Arn doit contenir : assumed-role/lab-assume-demo/demo-session

Sous PowerShell, utilisez $env:AWS_ACCESS_KEY_ID = "..." (idem secret + session). Puis Remove-Item Env:AWS_* quand vous avez fini, et rechargez AWS_PROFILE=lab.

Étape 7 — Access keys : rotation et désactivation (rappel)

Sans refaire tout le hub de démarrage :

# Lister (métadonnées seulement)
aws iam list-access-keys --user-name admin-lab --profile lab

# Désactiver une clé compromise
aws iam update-access-key 
  --user-name admin-lab 
  --access-key-id AKIA...EXAMPLE 
  --status Inactive 
  --profile lab

# Puis supprimer
aws iam delete-access-key 
  --user-name admin-lab 
  --access-key-id AKIA...EXAMPLE 
  --profile lab

Règle lab : au plus une clé active pour admin-lab CLI ; pas de clé dans Git, Discord, captures d’écran.

Étape 8 — Vérification

aws sts get-caller-identity --profile lab
aws iam list-groups-for-user --user-name admin-lab --profile lab
aws iam list-attached-group-policies --group-name lab-s3-readers --profile lab
aws iam get-role --role-name lab-ec2-role --profile lab
aws iam list-instance-profiles-for-role --role-name lab-ec2-role --profile lab

Checklist :

1. admin-lab est membre d’au moins un groupe (plus de permissions « orphelines » si vous avez migré).
2. LabS3ListLabPrefix existe en Customer managed.
3. lab-ec2-role a une trust policy ec2.amazonaws.com + instance profile.
4. assume-role démo renvoie un ARN assumed-role/... (si vous avez fait l’étape 6).

Nettoyage

À garder pour la série : groupes lab-admins / lab-s3-readers, politique LabS3ListLabPrefix, rôle lab-ec2-role + profile (serviront aux labs S3/EC2).

À supprimer si vous voulez un compte nickel après la démo assume-role :

aws iam detach-role-policy 
  --role-name lab-assume-demo 
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess 
  --profile lab

aws iam delete-role --role-name lab-assume-demo --profile lab

Ne laissez pas de credentials temporaires dans votre shell.

Erreurs fréquentes

Symptôme	Cause	Correction
AccessDenied sur sts:AssumeRole	Trust policy : Principal / Account ID faux	Corriger le JSON trust, update-assume-role-policy
AccessDenied sur S3 malgré la policy	Bucket hors lab-*, ou manque ListBucket sur l’ARN bucket	Renommer bucket / ajuster Resource
NoSuchEntity	Nom de rôle/groupe/typo	list-roles / list-groups
MalformedPolicyDocument	JSON invalide, guillemets Windows	Valider JSON ; file:// avec chemin correct
EC2 sans droits AWS	Instance profile non attaché au launch	Associer lab-ec2-profile (ou Attach/Replace en console)
Confusion user vs role	Access keys sur l’AMI	Retirer les clés ; utiliser le rôle

Quiz (3 questions)

1. Pourquoi préfère-t-on attacher une politique à un groupe plutôt qu’à chaque user ?
– A. Les groupes sont facturés moins cher
– B. Un seul point de gestion ; ajouter/retirer un user change ses droits sans retoucher 10 policies
– C. Les users ne supportent pas les politiques gérées

2. Que décrit la trust policy d’un rôle ?
– A. Les actions S3 autorisées
– B. Qui (service ou compte) peut appeler sts:AssumeRole sur ce rôle
– C. Le mot de passe du rôle

3. Une access key IAM apparaît dans un repo Git public. Premier réflexe ?
– A. Changer le nom du user
– B. Désactiver puis supprimer la clé, en créer une nouvelle si besoin, auditer CloudTrail
– C. Attendre la facture du mois

Réponses : 1‑B · 2‑B · 3‑B

Pour aller plus loin

• Doc : IAM best practices, Policies and permissions, Instance profiles
• Plus tard dans le parcours : AWS Organizations, IAM Identity Center (SSO), permissions boundaries — hors scope de ce tuto

Maillage série AWS (P1)

← Précédent	Démarrer avec AWS
→ Suivant	EC2 : lancer, SG, SSM (à rédiger)
Aussi	S3 fondamentaux · VPC intro

---

Retour parcours AWS — hub de la série et leçons sœurs.