Aller au contenu principal

AWS : CLI et Toolkit VS Code

· 8 minutes de lecture

Une opération effectuée dans la console web AWS ne se scripte pas, ne se rejoue pas et ne s'intègre pas à un pipeline. L'AWS CLI (Command Line Interface) fournit un accès en ligne de commande aux services AWS, utilisable dans des scripts comme en CI/CD, à condition de maîtriser la résolution des identifiants qu'elle utilise. L'extension AWS Toolkit pour Visual Studio Code propose une intégration complémentaire permettant de naviguer dans les ressources, de tester et de déployer des fonctions depuis l'éditeur.

Installation​

Les distributions officielles de l'AWS CLI v2 sont disponibles pour Linux, macOS et Windows. Choisir l'onglet correspondant au système d'exploitation pour l'instruction d'installation.

Sur Linux (exemple Debian/Ubuntu) :

# Remplacer x86_64 par aarch64 sur une machine ARM
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install          # installe dans /usr/local/aws-cli, lien dans /usr/local/bin
aws --version

# Mise à jour ultérieure d'une installation existante
sudo ./aws/install --update

L'installeur officiel embarque son propre interpréteur Python, indépendant de celui du système. Les paquets des distributions (apt install awscli) fournissent souvent encore la v1 ou une v2 en retard de plusieurs versions.

Configuration initiale​

La commande aws configure permet d'initialiser un profil par défaut : clé d'accès, clé secrète, région et format de sortie.

aws configure

Pour gérer plusieurs comptes ou rôles, utiliser des profils nommés :

aws configure --profile dev
aws --profile dev s3 ls

# Ou pour toute la session shell
export AWS_PROFILE=dev

Les identifiants sont écrits dans ~/.aws/credentials et les autres paramètres (région, format, rôles, SSO) dans ~/.aws/config, où les profils nommés s'écrivent [profile dev] (et [dev] dans le fichier credentials).

Chaque commande résout ses identifiants en parcourant une chaîne de fournisseurs dans un ordre fixe ; le premier qui fournit des identifiants l'emporte :

  1. options de la ligne de commande (--profile) ;
  2. variables d'environnement (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, ou AWS_PROFILE) ;
  3. fichiers ~/.aws/credentials et ~/.aws/config (profil default à défaut d'un autre) ;
  4. identifiants du conteneur (tâche ECS, EKS Pod Identity) ;
  5. rôle de l'instance EC2, via le service de métadonnées (IMDS).

Cet ordre explique un piège courant : des variables AWS_ACCESS_KEY_ID oubliées dans le shell masquent silencieusement le profil configuré. aws sts get-caller-identity affiche l'identité effectivement utilisée, et aws configure list indique la source de chaque valeur.

Méthodes d'authentification​

  • Clés d'accès (access key/secret) : identifiants permanents d'un utilisateur IAM. Pratiques pour des scripts, mais toute fuite reste exploitable jusqu'à leur révocation.
  • IAM Identity Center (anciennement AWS SSO) : aws sso login ouvre une authentification dans le navigateur, puis la CLI obtient des identifiants temporaires pour un rôle du compte cible. Aucune clé permanente n'est stockée sur le poste.
  • Assume role (STS) : pour exécuter des actions avec un rôle différent, via aws sts assume-role ou, sans appel explicite, un profil qui déclare role_arn et source_profile : la CLI appelle STS et renouvelle les identifiants temporaires automatiquement.
  • Outils tiers : aws-vault chiffre les clés dans le trousseau du système et ne fournit aux commandes que des identifiants temporaires ; saml2aws gère la fédération via un fournisseur SAML.
# ~/.aws/config
[sso-session corp]
sso_start_url = https://corp.awsapps.com/start
sso_region = eu-west-3
sso_registration_scopes = sso:account:access

[profile dev]
sso_session = corp
sso_account_id = 123456789012
sso_role_name = DeveloperAccess
region = eu-west-3

# Rôle assumé à partir du profil dev (accès à un autre compte)
[profile prod-readonly]
role_arn = arn:aws:iam::210987654321:role/ReadOnly
source_profile = dev
region = eu-west-3
aws sso login --sso-session corp
aws --profile prod-readonly s3 ls

Commandes courantes (exemples)​

  • S3 : transférer un fichier
aws s3 cp ./index.html s3://mon-bucket/index.html --profile dev
  • EC2 : lister les instances
aws ec2 describe-instances --query 'Reservations[].Instances[].{ID:InstanceId,State:State.Name,IP:PublicIpAddress}' --output table
  • Lambda : invoquer une fonction
# La CLI v2 attend par défaut un payload encodé en base64 : l'option indique un JSON brut
aws lambda invoke --function-name my-func \
  --cli-binary-format raw-in-base64-out \
  --payload '{"name": "test"}' response.json
cat response.json
  • STS : assumer un rôle
aws sts assume-role --role-arn arn:aws:iam::123456789012:role/RoleName --role-session-name session1

Requêtes complexes et JMESPath​

La CLI prend en charge JMESPath pour filtrer et transformer la sortie JSON via --query. Le filtrage --query s'applique côté client, après réception de la réponse ; l'option --filters, propre à certaines API comme EC2, filtre côté serveur et réduit le volume transféré.

# Filtrage client (JMESPath) : les littéraux s'écrivent entre backticks
aws ec2 describe-instances \
  --query 'Reservations[].Instances[?State.Name==`running`].InstanceId' --output text

# Filtrage serveur, puis projection JMESPath
aws ec2 describe-instances \
  --filters Name=instance-state-name,Values=running Name=tag:Environment,Values=dev \
  --query 'Reservations[].Instances[].[InstanceId, Tags[?Key==`Name`] | [0].Value]' \
  --output table

Bonnes pratiques​

  • Préférer les profils nommés aux variables AWS_ACCESS_KEY_ID exportées, qui masquent les profils (voir la chaîne de résolution ci-dessus).
  • Limiter les permissions des identités utilisées par la CLI au strict nécessaire (moindre privilège).
  • Pour les postes de travail, préférer IAM Identity Center ou aws-vault aux clés permanentes stockées en clair dans ~/.aws/credentials.
  • Passer --region et --profile explicitement dans les scripts pour ne pas dépendre de la configuration de la machine qui les exécute.
  • Toute action effectuée par la CLI est journalisée par CloudTrail avec l'identité appelante, ce qui permet d'auditer les automatisations.

Astuces utiles​

  • Pagination : la CLI enchaîne automatiquement les appels paginés de l'API ; --max-items limite le nombre de résultats renvoyés et --page-size la taille de chaque appel (utile pour éviter les timeouts sur de gros volumes).
  • Pager : la CLI v2 envoie sa sortie dans less par défaut, ce qui bloque les scripts ; --no-cli-pager ou export AWS_PAGER="" désactive ce comportement.
  • Format de sortie : --output json|yaml|table|text ; pour les pipelines, text se découpe facilement avec les outils Unix et json se combine avec jq.
  • Session interactive : aws configure list et aws sts get-caller-identity pour vérifier l'identité active.

AWS dans Visual Studio Code​

L'extension officielle AWS Toolkit for Visual Studio Code facilite le travail avec AWS directement depuis l'éditeur. Principales fonctionnalités :

  • Connexion aux comptes : sélection et gestion des profils AWS (credentials, SSO) depuis l'interface, commande AWS: Connect to AWS.
  • AWS Explorer : navigation dans les ressources (Lambda, S3, DynamoDB, CloudFormation, ECS), déploiement rapide et actions contextuelles.
  • Développement Serverless : intégration avec AWS SAM pour build, debug et déploiement locaux des fonctions Lambda (requiert SAM CLI et Docker pour le debug local).
  • Invocation et logs : exécution et test des fonctions Lambda, visualisation des logs CloudWatch depuis l'éditeur.
  • Déploiement : assistance pour empaqueter et déployer des stacks CloudFormation / SAM, et exécution de commandes sam deploy via l'interface.

Installation et configuration rapide :

  1. Installer l'extension AWS Toolkit depuis le marketplace VS Code.
  2. Configurer un profil AWS (clé/secret ou SSO) dans ~/.aws/credentials / ~/.aws/config ou utiliser le flux d'authentification de l'extension.
  3. Installer awscli, sam-cli et Docker si des tests locaux ou du débogage sont nécessaires.

Conseils pratiques :

  • Pour déboguer une Lambda localement, installer Docker et SAM CLI, puis utiliser la commande Run Local fournie par l'extension.
  • Préférer les profils nommés et SSO pour éviter d'exposer des credentials dans l'éditeur. L'extension prend en charge l'authentification SSO (CLI v2 requise).
  • Utiliser les actions contextuelles dans AWS Explorer pour ouvrir rapidement la console AWS ou copier des ARNs et URL.
  • En équipe, documenter le profil à utiliser et ajouter un fichier devcontainer.json si l'on standardise l'environnement de développement.

Le Toolkit réutilise les profils de ~/.aws/config : la configuration SSO ou de rôle assumé décrite plus haut s'applique donc aussi dans l'éditeur.

Conclusion​

L'AWS CLI rend les opérations AWS scriptables et reproductibles. La chaîne de résolution des identifiants détermine l'identité effectivement utilisée, et les identifiants temporaires (IAM Identity Center, rôles assumés) limitent l'exposition par rapport aux clés permanentes. Le Toolkit VS Code s'appuie sur la même configuration de profils et y ajoute la navigation dans les ressources et le débogage local des fonctions Lambda.

Références rapides​

0%