AWS Identity and Access Management (IAM), comme son nom l’indique, est le service de gestion des identités et des accès d’AWS.
En bref, lorsque vous essayer de réaliser une action quelconque sur AWS, vous devez passer par IAM qui vous identifiera, puis autorisera ou interdira l’action selon les droits qui vous ont été accordés par l’administrateur du compte.
Si vous utilisez AWS, vous utilisez forcément IAM, que vous en soyez conscient ou non.
Par exemple, lorsque vous vous connectez à la console web AWS, c’est IAM qui vérifie votre couple identifiant/mot de passe et vous autorise à accéder à votre compte. Puis, lorsque vous essayer de créer une nouvelle instance EC2, c’est IAM qui va vérifier que les droits nécessaires pour cette action vous ont bien été accordés par l’administrateur du compte.
Il en va de même avec une application qui tente d’accéder à une ressource hébergéesur AWS : IAM va identifier l’application grâce à la clé d’accès fournie puis vérifier que l’action est bien autorisée.
Un compte peut être vu comme un espace AWS propre à une organisation, une équipe ou une unique personne.
Si les mots “compte” et “utilisateur” sont parfois interchangeables dans le langage courant, il convient de ne pas confondre ces deux concepts au sens d'AWS. Si vous avez tendance à confondre les deux termes, rappelez-vous que l'identifiant d'un compte AWS est un nombre à 12 chiffres alors qu’un nom d’utilisateur est une chaîne de caractères quelconques.
Il est courant pour une organisation de posséder plusieurs comptes AWS, afin de séparer ses différents environnements. On pourrait par exemple avoir un compte AWS pour l’environnement de développement, un pour la qualification et un troisième pour la production.
Un utilisateur est une identité AWS associée à une personne physique ou à une application dans le cas d'un compte de service. Un utilisateur possède des informations d'identification comme un mot de passe ou une clé d'accès. Il est possible de les organiser en groupes afin de faciliter l'affectation des droits
À sa création, un compte ne contient qu'un seul utilisateur : le root. Celui-ci devra ensuite créer d'autres utilisateurs au fur et à mesure des besoins de son organisation. On ne pourra jamais souligner assez que le compte root ne doit en aucun cas être utilisé au quotidien ; utilisez-le pour créer d'autres utilisateurs auxquels vous donnerez les autorisations nécessaires.
À noter qu’il existe un autre concept relativement proche de celui d’utilisateur : le rôle. On parlera de ce terme dans la troisième partie de cet article, qui lui est consacrée, afin d’introduire entre-temps d’autres concepts utiles à sa compréhension.
Chaque action AWS, qu'elle soit réalisée sur la console, en ligne de commande ou programmatiquement, donne lieu à une demande (request) envoyée à AWS. C'est en comparant cette demande avec la liste des droits - les stratégies - définie en amont par l'administrateur du compte que le service IAM va répondre favorablement ou non à cette demande. Les trois champs principaux explicités dans une demande sont le mandataire, l'action et la ressource.
"Action" : "ec2:StartInstances"
"Action" : "iam:ChangePassword"
À peu près tout ce qui existe dans AWS. Une instance EC2 est une ressource, aussi bien qu'un rôle, un utilisateur ou le service RDS.
Ex :
|
L’utilisateur Alice du compte 012345678912 |
|
La file d’attente queue1 du compte 012345678912 dans la région eu-west-1 |
NB : Vous remarquerez que le format de ces deux exemples est quelque peu différent :
Gardez en tête que les ARN (Amazon Resource Name) ont pour but d’identifier une ressource de manière unique et non-ambigüe. S’il n’y a pas d'ambiguïté (comme dans le cas des régions pour IAM), il est inutile de surcharger le nom de la ressource.
Une stratégie est une règle régissant l'accès d'un utilisateur, groupe d'utilisateurs ou rôle à une ressource.
Des stratégies standards sont directement disponibles mais il est possible de créer d'autres stratégies pour répondre à un besoin précis. Les stratégies sont rédigées au format JSON.
Une stratégie reprend dans la plupart des cas les champs Action et Resource définis plus haut et y ajoute un champ Effect qui indique si l’action en question est autorisée (Allow) ou refusée (Deny)
Ex :
Cette stratégie autorise toutes les actions EC2.
À noter qu'il est également possible de rencontrer des stratégies spécifiants un champ Principal à la place d'un champ Ressource dans le cadre d'une relation d'approbation
Ex :
Cet exemple permet d'autoriser le service Amazon Directory Service à assigner ce rôle à ces utilisateurs. Il serait également possible d'autoriser les utilisateurs d'un autre compte AWS à utiliser ce rôle.
Une stratégie ne joue un rôle que lorsqu’elle est attachée à une entité IAM : utilisateur, groupe ou rôle. Lorsqu’une stratégie mentionnant un champ ressource est attachée à un utilisateur, il est implicite que celui-ci est le mandataire de l’action. Si au contraire, il est mentionné le champ Principal, on comprend que l’entité à laquelle est attachée la stratégie est la ressource.
Figure 2: Schéma illustrant l’utilisation de stratégies
Sur le schéma ci-dessus :
rds :DescribeDBInstances sur toutes les ressources. Elle essaye cependant de réaliser l’action rds :StartDBInstance pour laquelle est n’a pas d’autorisation. Son appel est donc rejeté.Important : Lorsque une stratégie autorise l'accès tandis qu'une autre le refuse sur une même demande, le refus l'emporte.
Le rôle peut être vu comme une identité AWS semblable à un utilisateur. Le rôle n'est cependant pas associé à une personne physique ou à une application précise. Plusieurs utilisateurs se voient généralement attribuer le droit d'assumer un rôle (profiter temporairement des droits associés à ce rôle). Un rôle, contrairement à un utilisateur ne possède pas de mot de passe ou clé d'accès et utilise des informations d'identification temporaire.
Des rôles standards sont directement disponibles mais il est possible de créer d'autres rôles pour répondre à un besoin précis, comme c'est le cas pour la plupart des objets IAM. Ces rôles standards sont déjà associés à des stratégies standards.
Un rôle peut être utilisé pour autoriser l’accès à un compte ou à des utilisateurs résidant dans un compte AWS différent de celui où résident les ressources.
C’est ce cas pratique que nous allons essayer d’illustrer avec les deux schémas suivants.
Détaillons d’abord le résultat des différentes requêtes exécutées directement de l’utilisateur vers la ressource sans utilisation d’un rôle :
Figure 3: Schéma illustrant l’accès direct à une ressource d’un autre compte
Important : Il faut nécessairement passer par un rôle pour réaliser des actions sur des ressources résidant dans un compte différent du sien.
Voyons maintenant ce qu’il se passe lorsque les utilisateurs utilisent le rôle pour accéder à la ressource :
Figure 4: Schéma illustrant l’accès à une ressource d’un autre compte en passant par un rôle
sts:AssumeRole. Leur appel est donc rejeté.sts:AssumeRole sur un rôle spécifique identifié par son ARN. Son appel est donc accepté, et elle peut ensuite réaliser l’action rds:StartDBInstance en utilisant le rôle qui est autorisé à réaliser cette action.
IAM est une partie essentielle de AWS et, en tant qu’utilisateur, vous y serez forcément confronté.
Ce n’est généralement pas la partie sur laquelle on s’attarde le plus. On voit souvent ce service comme le méchant gendarme qui nous empêche de donner libre cours à nos envies les plus folles dans le monde virtuellement illimité qu’est le cloud.
Mais se donner le temps de comprendre le fonctionnement de IAM, c’est s’éviter de nombreux moments d'énervement devant le message “403: FORBIDDEN” retourné de manière - à première vue - arbitraire à vos requêtes.
N'hésitez pas à nous contacter si vous avez des questions sur AWS IAM ou sur le Cloud.