IAM User vs IAM Role AWS : Quelle différence et quand utiliser chacun ?

Sur un projet en production, un développeur configure des credentials AWS directement dans le code d'une application EC2 pour accéder à S3. Six mois plus tard, ces credentials fuient dans un dépôt Git public — scénario classique, évitable, et directement lié à une confusion fondamentale entre IAM User et IAM Role.

TL;DR — IAM User vs IAM Role

Critère IAM User IAM Role
Identité Personne physique ou service externe Entité assumable par un service, compte ou fédération
Credentials Access Key ID + Secret (long terme) Credentials temporaires via STS
Rotation Manuelle, souvent oubliée Automatique (gérée par AWS)
Application sur EC2 Déconseillé — risque de fuite Recommandé — Instance Profile
Cross-account Non natif Natif via AssumeRole
Cas d'usage principal Accès humain à la console / CLI locale Services AWS, automatisation, fédération

Comment fonctionnent IAM User et IAM Role

Un IAM User est une identité permanente attachée à un compte AWS. Il possède des credentials à long terme : un Access Key ID et un Secret Access Key. Ces credentials ne changent pas sauf rotation manuelle explicite. C'est adapté pour un opérateur humain qui se connecte à la console ou utilise la CLI depuis son poste de travail.

Un IAM Role ne possède pas de credentials propres. Il définit un ensemble de permissions et une politique de confiance (trust policy) qui spécifie qui peut l'assumer. Quand une entité assume un rôle via AWS STS (Security Token Service), elle reçoit des credentials temporaires — Access Key, Secret Key, et Session Token — avec une durée de vie limitée. À expiration, ces credentials deviennent invalides automatiquement.

graph LR U["IAM User
Credentials statiques"] -->|"Access Key + Secret"| API["AWS API"] TP["Trust Policy
Qui peut assumer ?"] --> R["IAM Role"] R -->|"sts:AssumeRole"| STS["AWS STS"] STS -->|"Credentials temporaires
(Key + Secret + Token)"| E["Entité appelante
(EC2, Lambda...)"]
  1. IAM User : identité permanente avec credentials statiques stockés côté client.
  2. Trust Policy : définit quelle entité (service, compte, utilisateur fédéré) peut appeler AssumeRole.
  3. STS AssumeRole : AWS STS émet des credentials temporaires valables de 15 minutes à 12 heures selon la configuration.
  4. IAM Role : les permissions effectives sont celles attachées au rôle, pas à l'appelant.
  5. Instance Metadata Service (IMDS) : sur EC2, le SDK AWS récupère automatiquement les credentials temporaires depuis http://169.254.169.254/latest/meta-data/iam/security-credentials/.

IAM User — Quand c'est le bon choix

L'IAM User reste pertinent dans des cas précis et limités. Un développeur qui accède à la console AWS ou utilise la CLI depuis son poste local a besoin d'une identité persistante. De même, certains outils tiers qui ne supportent pas AssumeRole nécessitent des credentials statiques.

Mais même dans ces cas, la bonne pratique est d'activer MFA, de ne jamais créer de credentials pour le compte root, et de mettre en place une rotation régulière des access keys.

# Lister les access keys d'un utilisateur IAM
aws iam list-access-keys \
  --user-name nom-utilisateur

# Vérifier la date de création et le statut
aws iam get-access-key-last-used \
  --access-key-id AKIAIOSFODNN7EXAMPLE

Si la date de création dépasse 90 jours sans rotation, c'est un signal d'alerte opérationnel immédiat.

IAM Role sur EC2 — La bonne approche pour accéder à S3

Pour une application tournant sur EC2 qui doit accéder à S3, la réponse est sans ambiguïté : utilisez un IAM Role via un Instance Profile. Ne stockez jamais d'access keys dans le code, les variables d'environnement de l'instance, ou les fichiers de configuration.

Penser à un IAM Role comme à un badge d'accès temporaire remis à l'entrée et récupéré à la sortie — l'instance n'en est jamais propriétaire, elle l'emprunte le temps nécessaire.

Le mécanisme est le suivant : vous attachez un Instance Profile (qui encapsule un IAM Role) à l'instance EC2. Le SDK AWS installé sur l'instance interroge automatiquement l'IMDS pour obtenir des credentials temporaires. La rotation est transparente — vous n'avez rien à gérer.

sequenceDiagram participant App as Application EC2 participant SDK as AWS SDK participant IMDS as IMDS (169.254.x.x) participant STS as AWS STS participant S3 as Amazon S3 App->>SDK: Appel S3 (ex: GetObject) SDK->>IMDS: GET /iam/security-credentials/RoleName IMDS-->>SDK: Credentials temporaires (Key+Secret+Token) SDK->>S3: Requête signée avec credentials temporaires S3-->>App: Réponse (objet ou erreur IAM)
  1. L'application appelle le SDK AWS (boto3, AWS SDK Java, etc.).
  2. Le SDK interroge l'IMDS sur l'adresse de lien local 169.254.169.254.
  3. L'IMDS retourne les credentials temporaires associés au rôle attaché à l'instance.
  4. Le SDK utilise ces credentials pour signer la requête S3.
  5. IAM valide les permissions du rôle avant d'autoriser l'accès au bucket.

Étape 1 — Créer le IAM Role avec la politique de confiance EC2

La trust policy déclare que le service EC2 est autorisé à assumer ce rôle. Sans cette déclaration, même un administrateur ne peut pas attacher le rôle à une instance.

# Créer le fichier de trust policy
cat > trust-policy.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
EOF

# Créer le rôle IAM
aws iam create-role \
  --role-name AppEC2S3ReadRole \
  --assume-role-policy-document file://trust-policy.json

Étape 2 — Attacher une politique de permissions S3 au rôle

Appliquez le principe du moindre privilège : accordez uniquement les actions nécessaires sur le bucket concerné, pas sur l'ensemble de S3.

🔽 Voir la politique IAM S3 (moindre privilège) 
cat > s3-read-policy.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::mon-bucket-applicatif",
        "arn:aws:s3:::mon-bucket-applicatif/*"
      ]
    }
  ]
}
EOF

# Créer la politique inline et l'attacher au rôle
aws iam put-role-policy \
  --role-name AppEC2S3ReadRole \
  --policy-name S3ReadAccess \
  --policy-document file://s3-read-policy.json

Étape 3 — Créer l'Instance Profile et associer le rôle

Un Instance Profile est le conteneur qui permet d'attacher un IAM Role à une instance EC2. Ce n'est pas le rôle lui-même — c'est une distinction que la console AWS masque, mais qui est visible et obligatoire via CLI.

# Créer l'instance profile
aws iam create-instance-profile \
  --instance-profile-name AppEC2S3ReadProfile

# Ajouter le rôle à l'instance profile
aws iam add-role-to-instance-profile \
  --instance-profile-name AppEC2S3ReadProfile \
  --role-name AppEC2S3ReadRole

Étape 4 — Attacher l'Instance Profile à l'instance EC2

Si l'instance est déjà en cours d'exécution, vous pouvez associer le profil sans redémarrage.

# Associer l'instance profile à une instance existante
aws ec2 associate-iam-instance-profile \
  --instance-id i-0abcdef1234567890 \
  --iam-instance-profile Name=AppEC2S3ReadProfile

# Vérifier l'association
aws ec2 describe-iam-instance-profile-associations \
  --filters Name=instance-id,Values=i-0abcdef1234567890

Étape 5 — Vérifier que les credentials temporaires sont disponibles sur l'instance

Depuis l'instance EC2, interrogez directement l'IMDS pour confirmer que le rôle est bien attaché et que les credentials sont accessibles. C'est le test de validation le plus direct — si cette commande échoue, le SDK échouera aussi.

# Depuis l'instance EC2 (IMDSv2)
TOKEN=$(curl -s -X PUT 'http://169.254.169.254/latest/api/token' \
  -H 'X-aws-ec2-metadata-token-ttl-seconds: 21600')

curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Récupérer les credentials du rôle (remplacer AppEC2S3ReadRole par le nom retourné)
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/iam/security-credentials/AppEC2S3ReadRole

La réponse inclut AccessKeyId, SecretAccessKey, Token, et Expiration. Le SDK gère le renouvellement automatiquement avant expiration.

Le piège classique — et pourquoi il persiste

Voici un pattern d'échec observé régulièrement en production : l'application fonctionne en local avec des credentials IAM User configurés dans ~/.aws/credentials. Au déploiement sur EC2, le développeur copie ces credentials dans les variables d'environnement de l'instance pour 'faire vite'. Ça marche. Puis les credentials expirent ou sont révoqués, et l'application tombe à 3h du matin.

La mauvaise hypothèse : 'les variables d'environnement sont sécurisées sur l'instance'. La réalité : n'importe quel processus tournant sur l'instance avec les bonnes permissions peut lire /proc/*/environ. Et si l'instance est compromise, les credentials statiques sont exfiltrables et réutilisables indéfiniment.

Avec un Instance Profile, les credentials temporaires expirent en quelques heures. Un attaquant qui les exfiltre dispose d'une fenêtre d'exploitation très limitée — et AWS révoque les sessions STS actives si le rôle est modifié.

graph TD A["Instance EC2 compromise"] --> B{"Type de credentials ?"} B -->|"IAM User
Access Key statique"| C["Credentials valides
indéfiniment"] B -->|"IAM Role
Instance Profile"| D["Credentials expirent
en quelques heures"] C --> E["Risque élevé :
exfiltration réutilisable"] D --> F["Risque limité :
fenêtre d'exploitation courte"]

Politique IAM pour vérifier les configurations existantes

Si vous auditez un compte existant pour détecter des instances EC2 sans Instance Profile attaché, ou des IAM Users avec des access keys actives depuis longtemps, voici les commandes utiles.

# Lister toutes les instances EC2 et leur Instance Profile associé
aws ec2 describe-instances \
  --query 'Reservations[*].Instances[*].{ID:InstanceId,Profile:IamInstanceProfile.Arn,State:State.Name}' \
  --output table

# Générer le rapport d'informations d'identification IAM (inclut âge des access keys)
aws iam generate-credential-report

# Télécharger et afficher le rapport
aws iam get-credential-report \
  --query 'Content' \
  --output text | base64 --decode

Le rapport de credentials IAM est l'outil le plus rapide pour identifier les access keys actives depuis plus de 90 jours — une anomalie de sécurité courante dans les comptes AWS anciens.

Différence entre IAM User et IAM Role — Résumé et prochaines étapes

La règle est simple : IAM User pour les humains, IAM Role pour les machines. Toute application tournant sur un service AWS — EC2, Lambda, ECS, EKS — doit utiliser un rôle, jamais des credentials statiques. La différence entre IAM User et IAM Role n'est pas qu'une question de style architectural : c'est une frontière de sécurité opérationnelle.

Pour aller plus loin, consultez la documentation officielle AWS sur les IAM Roles et les Instance Profiles pour EC2. Activez AWS IAM Access Analyzer pour détecter les permissions excessives dans votre compte.

Glossaire

Terme Définition
IAM User Identité permanente dans un compte AWS, avec credentials à long terme (Access Key + Secret Key).
IAM Role Identité assumable sans credentials propres, émettant des credentials temporaires via STS.
Instance Profile Conteneur IAM qui permet d'attacher un rôle à une instance EC2.
STS (Security Token Service) Service AWS qui émet des credentials temporaires lors d'un AssumeRole.
Trust Policy Politique attachée à un rôle IAM définissant quelle entité est autorisée à l'assumer.
IMDS (Instance Metadata Service) Service local à l'instance EC2 (adresse 169.254.169.254) exposant les métadonnées et credentials du rôle attaché.

Commentaires

Enregistrer un commentaire

Posts les plus consultés de ce blog

Groupes IAM AWS : Pourquoi Attacher les Politiques aux Groupes Plutôt qu'aux Utilisateurs

Vous venez d'intégrer trois nouveaux développeurs dans votre équipe. Vous créez leurs utilisateurs IAM, puis vous commencez à attacher les politiques une par une à chaque compte — et c'est là que le problème commence. Six mois plus tard, un développeur change de rôle, et personne ne sait exactement quelles permissions il possède ni pourquoi. TL;DR — Groupes IAM vs. Politiques Directes Critère Politiques directes sur l'utilisateur Politiques via Groupe IAM Auditabilité Difficile — chaque utilisateur est une île Claire — une politique, un groupe, N utilisateurs Gestion à l'échelle O(N) opérations pour N utilisateurs O(1) — modifier le groupe suffit Risque d'erreur Élevé — oubli fréquent lors des offboardings Faible — retirer l'utilisateur du groupe suffit Conformité (moindre...
Lire la suite

LSI vs GSI dans DynamoDB : choisir le bon index secondaire

Vous avez modélisé votre table DynamoDB autour d'une clé de partition, puis le jour où un nouveau cas d'usage apparaît — filtrer les commandes par statut, rechercher les utilisateurs par email — vous réalisez que la clé primaire ne suffit plus. C'est exactement là que les index secondaires entrent en jeu, et le choix entre un LSI et un GSI a des conséquences directes sur la cohérence des lectures, la capacité de la table et les contraintes de conception. TL;DR — LSI vs GSI dans DynamoDB Critère LSI (Local Secondary Index) GSI (Global Secondary Index) Clé de partition Identique à la table de base N'importe quel attribut Clé de tri Attribut différent de la table N'importe quel attribut (optionnel) Création Uniquement à la création de la table À tout moment Cohérence des lectures Fortement cohérente possible Éventuellement cohérente uniquement Capacité Partagée avec la table de base ...
Lire la suite

NAT Gateway vs NAT Instance : Quelle solution choisir pour vos instances privées ?

Vous venez de déployer vos premières instances EC2 dans un sous-réseau privé et vous réalisez qu'elles ne peuvent pas télécharger les mises à jour système — aucune route vers internet. La question qui suit est systématique : faut-il provisionner un NAT Gateway managé ou lancer une instance EC2 configurée comme NAT Instance ? Ce choix impacte directement la disponibilité, les coûts opérationnels et la charge de maintenance de votre infrastructure. TL;DR — NAT Gateway vs NAT Instance Critère NAT Gateway NAT Instance Gestion Entièrement managé par AWS Vous gérez l'OS, les patches, la HA Disponibilité Haute disponibilité dans une AZ Dépend de votre configuration Bande passante Scalabilité automatique jusqu'aux limites du service Limitée par le type d'instance EC2 Modèle de coût ...
Lire la suite