Meilleures pratiques pour gérer en toute sécurité les identifiants avec l'AWS CLI

Les identifiants AWS CLI peuvent créer, supprimer et exposer des ressources cloud réelles, donc une clé d'accès divulguée n'est pas une petite erreur. La configuration la plus sûre donne aux humains des identifiants de courte durée via IAM Identity Center et donne aux charges de travail des identifiants temporaires via des rôles.

Ces meilleures pratiques pour gérer en toute sécurité les identifiants avec l'AWS CLI expliquent où la CLI recherche les identifiants, quand utiliser les profils et comment éviter les clés statiques à longue durée de vie dans les scripts.

Comprendre l'ordre de chargement des identifiants AWS CLI

L'AWS CLI résout les identifiants via une chaîne de fournisseurs. La chaîne exacte peut varier selon la version de la CLI et la configuration, mais l'ordre pratique que vous dépannerez le plus souvent est :

Variables d'environnement : AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY et éventuellement AWS_SESSION_TOKEN.
Configuration assume-role et web identity : Profils qui demandent à la CLI d'appeler AWS STS pour des identifiants temporaires.
Identifiants IAM Identity Center : Profils créés par aws configure sso ou aws configure sso-session.
Fichier d'identifiants partagé : Généralement ~/.aws/credentials.
Fichier de configuration partagé : Généralement ~/.aws/config, y compris les entrées credential_process.
Identifiants de conteneur : Rôles de tâche ECS et points de terminaison d'identifiants de conteneur compatibles.
Identifiants de profil d'instance EC2 : Identifiants temporaires du service de métadonnées d'instance (IMDS).

L'AWS CLI n'utilise pas les indicateurs de ligne de commande --access-key-id ou --secret-access-key pour les commandes normales. Si vous les voyez dans un script, il s'agit probablement d'une confusion entre le comportement de l'AWS CLI et un autre outil ou SDK.

1. Sécurisation des identifiants dans les fichiers de configuration (`~/.aws/credentials`)

Le fichier d'identifiants partagé, généralement ~/.aws/credentials, est pratique mais devrait être une solution de repli pour les cas où vous ne pouvez pas utiliser IAM Identity Center ou les rôles. Si vous devez y stocker des clés statiques, protégez le fichier et maintenez des permissions restreintes.

Protection du fichier et permissions

Il est essentiel de restreindre l'accès en lecture à ce fichier. Sur les systèmes Linux/macOS, définissez les permissions pour que seul le propriétaire puisse lire ou écrire le fichier :

chmod 600 ~/.aws/credentials

Utilisation de profils pour la ségrégation

L'utilisation de profils distincts vous permet de séparer les identifiants pour différents environnements (par exemple, développement, préproduction, production) ou différents comptes. Cela évite les actions accidentelles entre environnements.

Exemple ~/.aws/credentials :

[default]
aws_access_key_id = AKIAEXAMPLE000000000
aws_secret_access_key = exampleSecretAccessKeyDoNotUse

[production-user]
aws_access_key_id = AKIAEXAMPLE111111111
aws_secret_access_key = anotherExampleSecretDoNotUse

Lorsque vous utilisez un profil nommé, vous devez le spécifier avec l'indicateur --profile :

aws s3 ls --profile production-user

2. Tirer parti des variables d'environnement

Les variables d'environnement fournissent des identifiants au processus en cours et à ses processus enfants sans modifier les fichiers de configuration AWS. Elles sont utiles pour les sessions temporaires et les tâches CI, mais elles peuvent encore fuir via les environnements de processus, les journaux de débogage ou un historique de shell négligent.

Définissez les variables suivantes dans votre session shell :

export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
export AWS_SESSION_TOKEN="temporary-session-token-if-using-sts"
export AWS_DEFAULT_REGION="us-east-1"

Remarque importante sur la priorité : Les identifiants définis via les variables d'environnement remplacent toujours ceux trouvés dans le fichier ~/.aws/credentials, car ils apparaissent plus haut dans la chaîne de chargement des identifiants.

Avertissement de sécurité : Soyez prudent lors de l'exportation de variables d'environnement, en particulier dans des terminaux partagés ou des scripts qui pourraient être journalisés. Désactivez-les toujours immédiatement après utilisation :
unset AWS_ACCESS_KEY_ID
unset AWS_SECRET_ACCESS_KEY
unset AWS_SESSION_TOKEN

3. Préférer les rôles IAM pour les charges de travail AWS

Pour les charges de travail s'exécutant sur l'infrastructure AWS, telles que EC2, Lambda, ECS et EKS, évitez les identifiants statiques. Utilisez des rôles IAM afin qu'AWS émette automatiquement des identifiants temporaires.

Sur EC2, un profil d'instance expose des identifiants temporaires via IMDS. Sur ECS, les rôles de tâche exposent des identifiants via le point de terminaison d'identifiants de conteneur. Sur EKS, les rôles IAM pour les comptes de service utilisent des jetons d'identité web. L'AWS CLI et les SDK savent comment utiliser ces fournisseurs sans stocker de clés à longue durée de vie sur le disque.

Comment cela fonctionne :

Une instance EC2 est lancée avec un rôle IAM associé via un profil d'instance.
La CLI s'exécutant sur cette instance interroge le service de métadonnées d'instance (IMDS) pour obtenir des identifiants temporaires.
La CLI utilise ces identifiants temporaires pour tous les appels API ultérieurs.

Cela élimine complètement le risque associé aux clés d'accès à longue durée de vie.

4. Utiliser IAM Identity Center pour l'accès humain

Pour les ingénieurs utilisant l'AWS CLI depuis des ordinateurs portables, IAM Identity Center est généralement plus sûr que les clés d'accès utilisateur IAM. Vous vous connectez via un navigateur, choisissez un compte et un rôle, et la CLI utilise des identifiants de courte durée mis en cache.

Configurez-le avec :

aws configure sso

Connectez-vous ensuite lorsque votre session expire :

aws sso login --profile <nom-du-profil>

IAM Identity Center s'appelait auparavant AWS SSO, vous pouvez donc encore voir sso dans les commandes CLI et les clés de configuration.

5. Utiliser `credential_process` pour les courtiers externes

Vous pouvez configurer la CLI pour appeler un outil externe, tel qu'un agent de coffre-fort ou un courtier d'identifiants d'entreprise, afin de récupérer dynamiquement les identifiants. Cela est spécifié dans ~/.aws/config :

Exemple ~/.aws/config :

[profile my-vault-profile]
region = us-west-2
credential_process = /usr/local/bin/my-vault-cli get-aws-creds --profile my-vault-profile

Cette méthode est cruciale lors de l'intégration avec des outils de gestion des secrets comme HashiCorp Vault.

Résumé des meilleures pratiques et liste de contrôle

Pour maximiser la sécurité de vos opérations AWS CLI, respectez ces principes fondamentaux :

Principe du moindre privilège : Assurez-vous que tous les utilisateurs et rôles IAM n'ont que les permissions strictement nécessaires pour effectuer leur travail.
Préférer les rôles aux clés : Utilisez toujours les rôles IAM (profils d'instance) lorsque vous opérez dans l'infrastructure AWS.
Utiliser IAM Identity Center : Pour une utilisation interactive humaine, utilisez IAM Identity Center pour gérer l'accès à plusieurs comptes.
Ne jamais coder en dur les clés : Évitez de placer les clés d'accès directement dans les scripts, le code source ou l'historique des commandes.
Protéger le fichier d'identifiants : Restreignez les permissions du système de fichiers (chmod 600) sur ~/.aws/credentials.
Rotation régulière des clés : Si des clés statiques doivent être utilisées, imposez un calendrier de rotation strict.

Votre valeur par défaut devrait être les identifiants temporaires : IAM Identity Center pour les personnes, les rôles IAM pour les charges de travail et credential_process pour l'accès d'entreprise courtisé. N'utilisez les clés d'accès statiques que lorsqu'il n'y a pas de meilleure option, puis limitez-les étroitement, faites-les pivoter et supprimez-les dès que la dépendance est levée.