Max GUILBERT
TP Les Rôles
Gestion des Rôles
Test des Rôles
Tout d'abord, pour tester les rôles, on va commencer par créer une
instance.
Max GUILBERT
Notre instance est donc bien créée et lancée. On va maintenant s'y
connecter via PuTTY.
Max GUILBERT
Nous sommes bien connectés à l'instance, qui va nous permettre de gérer
les rôles.
Max GUILBERT
Nous allons configurer l'accès à AWS de l'instance. Pour cela, nous allons
attribuer un rôle IAM à l'instance EC2, avec des permissions en lecture
seule sur S3, afin de respecter les bonnes pratiques de sécurité.
On créez un rôle nommé EC2toS3-test-Max et on lui attribue les privilèges
S3 Read-Only.
Max GUILBERT
Une fois le rôle créé, on l'ajoute à l'instance EC2 :
Le rôle a bien été attribué :
L'instance EC2 dispose d'un accès en lecture seule à S3. Cet accès est
limité dans le temps (1 heure), selon les permissions définies dans la
politique attachée au rôle.
Terminez l'instance pour minimiser la consommation des ressources
gratuites de l'EC2 de type [Link].
Max GUILBERT
Dans cette partie, on va essayer d'accéder aux informations AWS via
une EC2, autrement que par des rôles, mais en utilisant AWS
configure.
Tout d'abord, on recrée une instance de test comme précédemment, sur
laquelle nous essayerons de nous connecter à AWS CLI :
Max GUILBERT
Une fois l'instance créée, on s'y connecte avec PuTTY
Une fois bien connecté à l'instance que l'on vient de créer, on se rend
compte, lorsqu'on tape les commandes AWS pour lister les buckets S3,
que l'on n'y a pas accès.
Max GUILBERT
Pour ce faire, nous allons créer un nouvel utilisateur nommé Max1 et
l'affecter au groupe admin.
On crée un Access Key ID et une Secret Access Key pour l'utilisateur
récemment ajouté pour aws configure.
Max GUILBERT
Une fois les identifiants créés, on peut accéder à AWS CLI. On entre les
identifiants dans notre EC2 avec "aws configure"
Puis, comme on peut le voir, on a accès à nos informations AWS, comme
sur la console
Nous avons actuellement accès à S3, mais en utilisant les paramètres de
Max1, qui est administrateur (aucun rôle avec le principe du moindre
privilège). De plus, ces paramètres sont en clair : si quelqu’un parvient à
accéder à cette VM, il aura accès aux paramètres d’authentification API
administrateur d’AWS.
Nous allons attribuer les mêmes droits à l’instance EC2, mais de manière
plus sécurisée et conforme aux recommandations d’AWS. Commençons
par supprimer les paramètres d’authentification actuels de l’instance EC2.
Max GUILBERT
Ensuite, on va donc créer un rôle pour notre EC2, "S3Readonly-Max",
comme précédemment.
Max GUILBERT
Notre rôle est bien créé. On va donc l'attacher à notre EC2 pour lister les
buckets S3 de la bonne manière.
Comme on peut le voir, on peut maintenant lister les buckets S3 de la
bonne manière.
Comme on peut le constater, nous avons accès à EC2 grâce à STS
AssumeRole, en appliquant le principe du moindre privilège. De plus, les
clés d'accès (Access Key ID et Secret Access Key) de l'utilisateur ne sont
pas exposées.
Max GUILBERT
Maintenant, au lieu d'attribuer un rôle à une EC2, on va l'attribuer
directement à un utilisateur de la console AWS.
Comme on peut le voir, nous sommes connectés sur notre compte
administrateur et nous n'avons pas de message d'erreur sur la partie EC2
de la console AWS.
Max GUILBERT
On va essayer de limiter cet accès. Pour cela, on va créer un rôle appelé
S3Readonly-Max-TP6-Part3.
Max GUILBERT
Le rôle est bien créé. On va maintenant vérifier sa configuration
Pour cela, on utilise le lien généré lors de la création du rôle pour se
connecter à la console.
Max GUILBERT
Nous avons bien effectué le changement de rôle. Bien que nous soyons
toujours connectés en tant qu'utilisateur administrateur, le changement de
rôle nous donne actuellement uniquement un accès en lecture seule à S3.
Comme on peut le voir, nous n'avons plus accès aux services EC2 ni IAM :
Max GUILBERT
Enfin,on va vérifier que nous avons un accès en lecture seule sur S3.
Il n’y a pas de message d’erreur, et nous avons accès à S3, mais
uniquement en lecture seule
Essayons de créer un deuxième bucket et vérifions que nous n'avons pas
l'accès.
Max GUILBERT
Il n'est effectivement pas possible de créer de bucket, car nous sommes
bien en lecture seule (read-only).
Max GUILBERT
Maintenant que nous avons bien configuré notre rôle, nous allons
l'attacher à un utilisateur.
Créez un utilisateur test-Max-Role et attribuez-lui uniquement les droits
d'accès à la console
On se connecte avec ce nouvel utilisateur pour confirmer que nous n'avons
pas accès à la lecture de S3 :
Max GUILBERT
On va donc appliquer le read-only à cet utilisateur afin qu'il puisse avoir les
droits de lecture sur S3. Pour cela, on retourne sur notre compte admin et
on copie l'ARN du rôle S3ReadOnly-Max-TP6-part3
puis on vas le coller dans les permission de l’utilisateur test-Max-Role que
l’on a créé :
Max GUILBERT
Puis, on met l'ARN du rôle dans les permissions de l'utilisateur au format
JSON.
Puis on créé le rôle :
Max GUILBERT
On va effectuer un test pour assumer le rôle avec l'utilisateur test-Max-Role
On change donc de rôle pour le test
Max GUILBERT
Comme on peut le voir nous avons l’accès en lecture seule à S3 en
utilisant la politique "sts:AssumeRole"
