Nous l'avons vu précédemment, AWS permet de créer des policies qui vont positionner des autorisations.

Maintenant comment "connecte-t-on" ces dernières à quelque chose de concret, d'utilisable, comme un utilisateur.

Il faut savoir qu'AWS fait un distinguo entre deux types d'utilisations:

  • Les utilisateurs
  • Les rôles (et instance profile dont je ne parlerais pas maintenant)

Les utilisateurs

Les utilisateurs sont comme leur nom l'indique ... des utilisateurs, c'est vous et moi. Ce sont nos logins AWS par exemple.

Le compte root dont nous avons parlé précédemment est un des utilisateurs AWS.

Un utilisateur peut se connecter de deux manières distinctes :

  • Via la console web, comme nous le faisons depuis le début de ce tutoriel
  • Via la ligne de commande, l'API ou les différents SDK AWS, on parle ici d'accès programmatique.

Il est possible de restreindre l'utilisateur pour n'utiliser que la console, ou que la partie programmatique  par exemple.

Les utilisateurs peuvent ensuite avoir des autorisations de positionnées :

  • Soit en attachant les policies à l'utilisateur
  • Soit en créant un groupe sur lequel on positionnera les policies, et en attachant l'utilisateur au groupe

La seconde démarche est conseillée car elle permet de factoriser facilement les autorisations, pour par exemple gérer une équipe complète avec les même droits.

Les rôles

Les rôles sont des utilisateurs particuliers. En effet, il est impossible de se connecter directement sur un rôle, pourtant ces derniers utilisent des policies de la même manière que les utilisateurs.

Les rôles permettent néanmoins de faire plusieurs actions :

  • Un utilisateur peut utiliser un rôle, on parlera d'assumer un rôle, ce qui lui permet d'avoir directement les droits du rôle. La portée des rôles est dite cross-account, c'est-à-dire qu'elle est utilisable entre plusieurs comptes AWS. Cela permet par exemple de créer un compte "landing zone" et de permettre aux utilisateurs de passer sur l'ensemble des comptes de l'entreprise, ce qui permet de créer un point d'entrée unique
  • Les rôles peuvent être utilisés par certains services AWS, ce qui permet de ne pas avoir à gérer de clé API sur les applications, et donc par extension de ne pas avoir à faire une gestion de ces secrets. Les rôles donnant des autorisations sur l'infrastructure, cette gestion serait de fait critique.

Je ne vais pas m'attarder sur les rôles actuellement, car nous allons en utiliser plus tard dans ce tutoriel.

Page suivante : Créons nos utilisateurs