Role Manager automatise la création des rôles IAM sur six services AWS
Disponible depuis le 12 août 2026, Role Manager crée ou réutilise automatiquement les rôles IAM dont les services AWS ont besoin, d’AWS Lambda à Amazon EventBridge. Le gain de temps est réel, mais le rôle par défaut n’est pas un rôle minimal : voici comment l’utiliser sans dégrader votre moindre privilège.
12 août 2026. AWS met en disponibilité générale Role Manager, une fonction d’AWS Identity and Access Management (IAM) qui crée et configure automatiquement les rôles dont les services ont besoin. Au lancement, elle couvre six consoles de services, dont AWS Lambda et Amazon EventBridge. Pour un ingénieur cloud, la promesse est directe : ne plus jamais interrompre la création d’une ressource pour fabriquer un rôle à la main.
L’enjeu est plus subtil qu’un simple gain de temps. Role Manager résout le problème du « rôle par défaut » en le rendant explicite et traçable — mais il introduit aussi un compromis que l’équipe sécurité doit regarder en face : le rôle qu’il attache à une fonction Lambda embarque par défaut la politique gérée PowerUserAccess, qui est loin d’être minimale.
Ce que fait Role Manager, précisément
Role Manager fonctionne en deux états, activé et désactivé. On l’active dans la console IAM, sous Paramètres du compte. Dans une organisation, un administrateur peut verrouiller son usage avec une service control policy (SCP) qui décide quels comptes membres ont le droit de l’activer ou de l’utiliser.
Sous le capot, la console appelle une nouvelle API, AcquireRole. Elle cherche le modèle de rôle géré AWS qui correspond à la tâche, provisionne le rôle à partir de ce modèle, puis le retourne au service. Selon le cas, AcquireRole crée un nouveau rôle ou réutilise un rôle existant qui correspond déjà aux permissions requises — un compte ne se remplit donc pas de doublons pour la même tâche.
Trois propriétés rendent la chose défendable en production :
- Les rôles sont des rôles IAM ordinaires. Vous les voyez, les modifiez et les supprimez comme n’importe quel rôle que vous auriez écrit vous-même.
- Chaque rôle garde la trace de son modèle. Les API GetRole et ListRoles renvoient la référence du modèle d’origine, et AWS CloudTrail enregistre chaque création.
- Les permissions restent les vôtres. Role Manager crée le rôle avec vos propres droits IAM, pas avec une permission séparée. Pour provisionner un nouveau rôle, il faut au minimum les droits de création et d’attachement ; pour réutiliser un rôle existant, iam:GetRole et iam:GetRoleTemplateVersion suffisent.
Le cas d’usage le plus parlant est la règle EventBridge. Sans Role Manager, créer une règle qui invoque une file SQS suppose de s’arrêter pour écrire le rôle, sa politique de confiance et ses permissions, puis de revenir finir la règle. Avec Role Manager, on définit la règle et sa cible, on clique sur Créer, et le rôle est provisionné et attaché dans le même flux — sans jamais ouvrir le formulaire de création de rôle.
Les six consoles couvertes au lancement — Lambda, EventBridge et quatre autres — donnent la mesure de l’ambition : couvrir d’abord les flux les plus courants, puis étendre la couverture aux autres services au fil des versions. Pour l’instant, un service non couvert continue de fonctionner exactement comme avant, avec sa création de rôle manuelle ou intégrée.
Le point de tension : PowerUserAccess par défaut
Tout ne se vaut pas. Quand la tâche consiste à exécuter votre propre code — le cas d’une fonction Lambda — AWS ne peut pas deviner quels services ce code va appeler. Role Manager attache alors à la fonction un rôle d’exécution muni de la politique gérée PowerUserAccess.
Ce choix mérite qu’on s’y arrête. PowerUserAccess autorise l’accès à l’ensemble des services AWS, à l’exception de la gestion d’IAM, d’AWS Organizations et des paramètres du compte. C’est, de loin, la politique la plus large qu’une fonction fraîchement créée puisse recevoir. Le modèle configure bien le rôle pour ne faire confiance qu’au service Lambda, mais à l’intérieur de cette frontière, la fonction peut appeler à peu près tout.
Autrement dit, Role Manager déplace le problème de l’IAM d’un endroit à un autre. Il supprime la friction du « créer le rôle » au prix d’un « resserrer le rôle » différé. Ce n’est pas un défaut de conception — c’est un compromis assumé, et AWS le documente noir sur blanc. Mais c’est un compromis que les équipes doivent comprendre, pas subir.
Pourquoi l’IAM reste le maillon faible
Le sujet n’est pas académique. L’IAM est, depuis plusieurs années, le premier vecteur de compromission du cloud — pas le zero-day. L’intrusion dans le compte AWS de la Commission européenne, début août 2026, avec plus de 350 Go exfiltrés, s’est appuyée sur un défaut de gestion des identités côté client, pas sur une faille de l’infrastructure d’AWS, comme nous l’avons documenté.
Dans ce contexte, un outil qui crée des rôles à votre place est une arme à double tranchant. D’un côté, il élimine le réflexe toxique du « copier-coller une politique trop large parce que c’est plus rapide ». De l’autre, il institutionnalise une forme de sur-permission par défaut — exactement ce contre quoi le principe de moindre privilège est censé lutter. La différence se joue sur ce qu’on fait après.
Le chemin de sortie : Access Analyzer et le resserrement
La bonne nouvelle, c’est que la sortie est prévue. AWS propose un parcours explicite en deux temps :
- Pendant le développement, on laisse Role Manager activé : on monte le service en minutes, on itère, on ne bloque pas sur l’IAM.
- Quand la charge arrive à maturité, on désactive Role Manager et on lance IAM Access Analyzer, dont l’analyse des accès inutilisés est offerte 90 jours sans surcoût. L’outil examine l’usage réel de chaque rôle et recommande une politique réduite aux seules permissions nécessaires.
Désactiver Role Manager ne casse rien : les ressources conservent leurs rôles, qui restent dans le compte jusqu’à modification, et on reprend l’écriture manuelle des rôles comme avant. Pour resserrer un seul rôle plutôt que tout le compte, il suffit de l’éditer : il sort alors du contrôle de Role Manager et devient un rôle géré par le client, vos changements étant préservés.
La consigne d’AWS elle-même trace la frontière, sans ambiguïté : gardez Role Manager activé dans les comptes de développement et de sandbox ; dans les comptes de production, désactivez-le et resserrez les rôles créés avant la mise en service.
Une réserve vaut pour les équipes qui provisionnent tout en code : Role Manager est une commodité de console, pas une primitive d’IaC. Si vos rôles sont définis en Terraform ou en CloudFormation, il n’y touche pas — et c’est très bien ainsi. Sa valeur est dans le flux « cliquer et construire », pas dans le remplacement d’une définition de rôle revue et versionnée.
Verdict
Role Manager n’est ni une révolution ni un piège — c’est un réglage par défaut, avec les vertus et les risques de tout réglage par défaut. Il abaisse le coût d’entrée de l’IAM au point qu’un développeur sans expérience IAM peut monter un service en minutes, et il le fait sans sacrifier la visibilité : chaque rôle est traçable, ordinaire et documenté.
La recommandation est conditionnelle et précise. Si vous opérez des comptes de développement ou de sandbox, activez Role Manager sans hésiter — le temps gagné est réel, et le risque y est borné par construction. Si vous opérez des comptes de production ou régulés, traitez Role Manager comme un échafaudage : laissez-le bâtir pendant la phase de construction, puis désactivez-le et passez chaque rôle créé au tamis d’Access Analyzer avant la mise en service. Et dans tous les cas, exigez une SCP qui contrôle qui peut l’activer — parce qu’un outil qui crée des rôles à votre place mérite au minimum que vous décidiez qui a le droit de l’allumer.