AssumeRole expliqué : l'accès inter-comptes AWS étape par étape

Tôt ou tard, un deuxième compte AWS, un sous-traitant ou un système d’intégration continue (CI) doit travailler dans l’un de vos comptes AWS. Lui remettre des clés d’accès permanentes est risqué, et AssumeRole lui permet plutôt d’emprunter un accès pour une courte durée. Vous créez un rôle IAM dans le compte cible, c’est-à-dire un ensemble de permissions sans mot de passe ni clés qui lui sont propres. AWS STS (Security Token Service) remet ensuite à l’appelant des identifiants temporaires pour ce rôle, valides une heure par défaut.

Deux politiques doivent s’accorder pour que ça fonctionne. La politique de confiance du rôle indique quels comptes ou identités peuvent l’assumer, et une politique d’identité dans le compte source permet à l’appelant d’exécuter sts:AssumeRole sur ce rôle. S’il manque l’une des deux moitiés, vous obtenez la même erreur « not authorized to perform: sts:AssumeRole ». Pour un fournisseur, ajoutez aussi un ID externe : une valeur partagée qu’il doit transmettre, pour que son accès ne puisse pas être détourné contre vous au nom d’un autre client. Plus bas, vous allez vérifier les deux moitiés, tester la prise de rôle et configurer un profil CLI pour que personne ne manipule de jetons de session bruts.

Ce qui se passe

Un rôle est un ensemble de permissions sans identifiants propres et avec deux politiques qui comptent. La politique de confiance (visible dans la console sous l’onglet « Trust relationships » du rôle) est une politique de ressource qui répond à une seule question : quels principaux peuvent appeler sts:AssumeRole sur moi? Pour l’inter-comptes, le patron standard fait confiance à l’ARN racine de l’autre compte — arn:aws:iam::111122223333:root — ce qui ne désigne pas l’utilisateur racine; ça délègue la décision à l’IAM du compte 111122223333, dont les admins choisissent quels principaux reçoivent sts:AssumeRole dans une politique d’identité. Les deux côtés doivent donc permettre l’assumption : la cible fait confiance au compte source, et la source accorde l’action à son principal. Ce double consentement est le design, pas une redondance.

Quand AssumeRole réussit, STS retourne une clé d’accès, une clé secrète et un jeton de session valides une heure par défaut, extensibles jusqu’au MaxSessionDuration du rôle (jusqu’à 12 heures) via --duration-seconds. Une nuance qui surprend : le chaînage de rôles — utiliser des identifiants de rôle assumé pour assumer un autre rôle — plafonne la deuxième session à une heure, peu importe les réglages. Pour des tiers qui assument dans votre compte, ajoutez une condition ExternalId à la politique de confiance; elle protège contre le problème du député confus, où un fournisseur est manipulé pour utiliser son accès au nom du mauvais client. La liste complète des paramètres est dans la documentation IAM, sous la référence de l’API STS.

Quoi vérifier en premier

Les deux moitiés existent. Lisez la politique de confiance sur le rôle cible et la politique d’identité sur le principal source; neuf échecs sur dix sont une moitié manquante.
L’ARN exact du rôle. Une coquille dans l’ID de compte ou la casse du nom de rôle produit la même erreur de refus qu’un vrai trou de permission.
Les conditions dans la politique de confiance. ExternalId, aws:PrincipalOrgID ou des conditions MFA font échouer silencieusement les assumptions qui ne les fournissent pas.
Les demandes de durée de session. Demander --duration-seconds 14400 contre un rôle dont le maximum est encore le défaut de 3600 échoue avec une erreur de validation, pas une erreur d’accès.

Comment vérifier

# Lire la politique de confiance sur le rôle cible (exécuter dans le compte cible)
aws iam get-role --role-name CrossAccountOps \
  --query 'Role.AssumeRolePolicyDocument'

# Tenter l'assumption (exécuter comme principal source)
aws sts assume-role \
  --role-arn arn:aws:iam::222222222222:role/CrossAccountOps \
  --role-session-name horia-ops-check

# Confirmer quelle identité vous détenez maintenant
aws sts get-caller-identity

Un assume-role réussi retourne Credentials et un AssumedRoleUser.Arn comme arn:aws:sts::222222222222:assumed-role/CrossAccountOps/horia-ops-check. Dans le CloudTrail du compte cible, l’assumption apparaît comme un événement AssumeRole sous CloudTrail > Event history, et chaque action subséquente porte le nom de session — c’est pourquoi les noms de session devraient identifier l’humain ou le système, pas être session1.

Le runbook

Créez le rôle dans le compte cible avec une politique de confiance délimitée.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::111122223333:root"},
      "Action": "sts:AssumeRole",
      "Condition": {"StringEquals": {"sts:ExternalId": "acme-7f3b2c"}}
    }
  ]
}

Attachez les permissions que la session devrait avoir — et rien de plus — comme politiques d’identité du rôle. Retirez le bloc Condition pour l’inter-comptes interne; gardez-le obligatoire pour les tiers.

Accordez l’assumption dans le compte source. Sur le rôle, le groupe ou l’utilisateur appelant :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::222222222222:role/CrossAccountOps"
    }
  ]
}

Câblez le profil CLI pour que personne ne manipule des jetons de session bruts. Dans ~/.aws/config :

[profile prod-ops]
role_arn = arn:aws:iam::222222222222:role/CrossAccountOps
source_profile = default
role_session_name = horia
external_id = acme-7f3b2c

Ensuite aws s3 ls --profile prod-ops assume, met en cache et rafraîchit les identifiants automatiquement.

Resserrez la politique de confiance de la racine du compte vers des principaux précis une fois le patron fonctionnel — nommez l’ARN exact du rôle source au lieu de :root quand un seul appelant devrait exister.
Montez MaxSessionDuration seulement où le flux de travail l’exige. De longues sessions de maintenance interactives peuvent justifier 4 heures; l’automatisation ne devrait presque jamais dépasser le défaut d’une heure.

Quand ce n’est pas la bonne approche

Si vous câblez des dizaines de chemins humain-vers-compte, la plomberie AssumeRole artisanale recrée ce qu’IAM Identity Center fait déjà avec les ensembles de permissions — utilisez la version gérée, couverte dans notre guide de migration vers Identity Center. Et pour donner à un service d’un autre compte l’accès à un seul compartiment ou une seule file, une politique de ressource sur le compartiment ou la file est souvent plus simple qu’un aller-retour de rôle.

Erreurs fréquentes

Écrire la politique de confiance mais oublier l’accord sts:AssumeRole côté source — le double consentement mord tout le monde une fois.
Faire confiance à :root en permanence quand un seul rôle nommé devrait être l’unique appelant.
Omettre ExternalId pour l’accès d’un fournisseur, laissant la porte du député confus ouverte.
Des noms de session génériques comme cli-session, qui rendent le CloudTrail du compte cible inattribuable.

Prévention

Gardez chaque politique de confiance dans l’infrastructure-en-code; une modification de confiance est le changement IAM au plus grand rayon d’impact qui soit.
Alertez sur les événements UpdateAssumeRolePolicy — une politique de confiance modifiée est soit un changement planifié, soit un incident.
Auditez les politiques de confiance chaque trimestre pour les ID de comptes inconnus et Principal: "*" (qui ne devrait jamais apparaître).
Ajoutez des conditions aws:PrincipalOrgID sur les rôles inter-comptes internes pour qu’une coquille dans un ID de compte ne puisse pas faire confiance à un étranger.

L’AssumeRole inter-comptes est une serrure à deux clés, et presque tous ses problèmes sont une clé manquante ou une clé taillée trop large. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.