L’utilisation d’identifiants permanents est une pratique extrêmement courante avec AWS. Injecter les valeurs de AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY dans les variables d’environnement est une solution simple et rassurante pour la majorité des développeurs. Cependant, du point de vue de la sécurité, cette pratique est loin d’être idéale. Avec le temps, ces valeurs sensibles peuvent fuiter, et il devient difficile d’encadrer leur utilisation.

La bonne nouvelle, c’est qu’il existe de meilleures alternatives ! Nous allons d’abord aborder comment bloquer leur création, puis expliquer les solutions de remplacement pour les trois domaines suivants : les accès développeurs, les services AWS, et les pipelines DevOps.

Restreindre l’utilisation

Avant même de discuter des alternatives aux identifiants permanents, il est primordial de restreindre leur utilisation. Pour ce faire, la meilleure approche est l’utilisation d’une SCP. Une Service Control Policy est une politique IAM pouvant être appliquée à tous les comptes AWS d’une organisation.

Bien que courte, cette politique est extrêmement puissante ! Elle interdit la création d’identifiants à long terme et d’utilisateurs IAM. La force d’une SCP réside dans le fait que même l’utilisateur racine d’un compte ne peut la contourner, assurant ainsi une conformité dans tous les projets de Thirdbridge.

Gestion des accès développeurs

Le premier défi à résoudre est la gestion des accès développeurs. Habituellement, un utilisateur IAM est créé pour chaque développeur. Celui-ci peut ensuite générer ses identifiants permanents pour, par exemple, exécuter un projet localement. L’alternative à ce cas d’utilisation est d’utiliser IAM Identity Center et AWS Organizations.

AWS offre le concept d’Organisation. Résumé simplement, une Organisation est un regroupement de comptes AWS distincts pouvant être organisés en unités organisationnelles (OU). Chez Thirdbridge, un projet client est représenté par une OU. Chaque OU contient deux comptes AWS : un pour les environnements inférieurs (dev, uat, staging, etc.) et un pour la production.

La force d’IAM Identity Center réside dans le fait que ce service permet de créer un profil unique pour chaque développeur, puis de leur assigner les accès nécessaires selon leur rôle et leur mandat actuel.

Donc, même si un développeur travaille sur 10 projets différents, il n’a qu’un seul compte. Lorsqu’il se connecte à la console web d’AWS, c’est au travers d’un rôle géré par IAM Identity Center. Finalement, si un développeur a besoin d’un AWS_ACCESS_KEY_ID et d’un AWS_SECRET_ACCESS_KEY pour exécuter un projet localement, IAM Identity Center fournit des identifiants temporaires pouvant être utilisés.

Exécution d’un service AWS

Une erreur fréquente consiste à injecter manuellement les variables AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY dans un service AWS. En réalité, les différents services d’AWS disposent d’un rôle IAM associé à leur exécution. Que ce soit ECS, Lambda ou EC2, il faut toujours utiliser le rôle attribué au service plutôt que d’injecter des identifiants.

Déploiement continue

Retirer les identifiants permanents des pipelines de déploiement continu est habituellement la partie qui effraie le plus les développeurs. Injecter les clés AWS via le mécanisme de gestion des secrets offert par les plateformes DevOps comme GitLab et GitHub est une pratique extrêmement répandue.

Cependant, l’approche recommandée consiste plutôt à utiliser le protocole OIDC pour établir une relation de confiance entre la plateforme DevOps et AWS. Non seulement cette méthode élimine le besoin d’utiliser des identifiants permanents, mais elle permet également de restreindre beaucoup plus précisément les permissions. Il est par exemple possible d’assigner un rôle IAM à une branche Git spécifique, respectant ainsi le principe du moindre privilège.

La mise en place pouvant parfois être un frein à l’adoption d’OIDC, nous avons préparé un guide pour GitHub et un autre pour GitLab expliquant de manière détaillée les différentes étapes nécessaires.

🔗 Gitlab OIDC

🔗 GitHub OIDC

Conclusion

Restreindre l’utilisation des identifiants permanents dans AWS est une pratique de sécurité essentielle pour toute entreprise souhaitant offrir un haut niveau de conformité. Bien que limiter leur utilisation soit simple à mettre en place à l’aide d’une SCP, mettre en œuvre leurs alternatives peut parfois s’avérer plus complexe.

Nous espérons que ce petit guide sera utile à d’autres entreprises souhaitant élever leurs pratiques opérationnelles avec AWS. Nous sommes restés à un niveau général pour alléger la lecture, mais n’hésitez pas à nous contacter pour toute question plus pointue 🙂