Quand utiliseriez-vous un rôle IAM plutôt qu'un utilisateur IAM ?

Utilisez des rôles quasiment tout le temps. Un rôle fournit des identifiants de courte durée qu'un service, une charge de travail ou un humain fédéré assume à la demande, donc il n'y a aucune clé statique à faire fuiter ou à faire tourner. Les utilisateurs IAM impliquent des clés d'accès à longue durée de vie, qu'il faut réserver aux systèmes qui ne peuvent réellement pas se fédérer. Pour les personnes, utilisez le SSO avec assomption de rôle ; pour les systèmes de CI, utilisez la fédération OIDC pour échanger un jeton de job contre un rôle.

Mon défaut, ce sont les rôles pour tout, parce que les identifiants sont temporaires et émis à la demande, donc il n'y a rien qui traîne dans un fichier de config en attendant d'être commité dans un dépôt. Une charge de travail dans le cloud reçoit un rôle attaché à l'instance, à la tâche ou à la fonction et récupère ses identifiants depuis le service de métadonnées. Une personne y arrive par le SSO, en assumant un rôle pour une session avec une expiration. Un pipeline de build hors du cloud utilise la fédération d'identité : le job présente un jeton signé par son fournisseur et l'échange contre un rôle restreint qui dure quelques minutes. C'est ce dernier point qui a supprimé le dernier lot de clés statiques qu'on avait. Les utilisateurs IAM, je les garde pour les cas vraiment récalcitrants, en général une vieille intégration tierce qui ne sait faire qu'une clé et un secret, et ceux-là sont restreints à une action sur une ressource, tournés régulièrement et surveillés. Quand j'hérite d'un compte, une des premières choses que je fais, c'est sortir le rapport d'identifiants et chasser les clés qui ont des années et sont encore actives.