Utiliser AWS en ligne de commande

Lorsqu'on débute dans l'utilisation de l'infonuagique on commence généralement par utiliser la console. Riche, remplie de fonctionnalités, c'est un bon moyen de se perdre pendant de nombreuses heures en cherchant a comprendre ce qui se cache derrière chaque nom de service.

Pourtant, rapidement on en vient a vouloir gagner en efficacité et en constance. Démarrer une instance dans la console c'est facile, mais en démarrer 100 de manière strictement identique est quasiment impossible, l'erreur humaine venant inévitablement s'insérer…

Pour cela, il est possible, et recommandé, d'utiliser l'interface par programmation d'AWS. Que ce soit avec les différentes APIs ou via la ligne de commande avec l'utilitaire awscli, l'automatisation est un incontournable pour exploiter pleinement les avantages du Cloud. Cet article aborde les fonctionnalités et la configuration de l'utilitaire awscli.

Installation

Deux versions existent de awscli, la version 1 et 2. Si la 1 est toujours disponible elle n'est plus recommandée et ne devrait pas être utilisée si vous n'avez pas la contrainte de maintenir de vieux scripts.
La documentation d'installation se trouve ici. Quelque soit votre système (Windows, Linux, Mac, et même Docker!) vous devez télécharger l'exécutable directement du site d'Amazon, il n'est pas conseillé d'utiliser un paquet fourni avec votre distribution.

Une fois l'installation effectuée, vous pouvez confirmer le bon fonctionnement en tapant :

aws --version

Pour utiliser awscli, il est nécessaire d'être authentifié sur AWS. Si vous n'êtes pas authentifié, vous ne pourrez pas interagir avec des ressources. Pour obtenir un authentifiant, il existe en réalité plusieurs moyens. Commençons par le plus simple, c'est à dire via un utilisateur IAM qui a été créé pour nous.

Configurer son accès IAM

Lorsqu'un utilisateur IAM est créé, il est possible de lui accorder soit un accès console, soit un accès par programmation, soit les 2. Dans le cadre de notre exemple, il est nécessaire que votre utilisateur se soit vu octroyé un accès par programmation et que votre administrateur vous ait délivré votre ACCESS KEY ainsi que votre SECRET ACCESS KEY.

Le plus simple pour configurer son accès, une fois en possession de ces informations, est d'utiliser l'utilitaire awscli directement en tapant :

aws configure

À ce moment, l'utilitaire va vous demander vos clés, votre région par défaut ainsi que le format de sortie.

Si vos clés sont corrects et reliées à un utilisateur possédant les droits suffisants, vous pouvez commencer à interagir avec vos ressources AWS en ligne de commande, comme par exemple lister les buckets S3 existants dans le compte :

aws s3 ls

À noter, qu'en utilisant la commande aws configure, l'utilitaire awscli a automatiquement créé 2 fichiers sous l'emplacement $HOME/.aws. Ces fichiers sont "credentials" qui contient les clés d'accès ainsi que "config" qui contient les paramètres de connexion (comme la région). Si vous jetez un coup d'oeil dans ces fichiers, vous pourrez constater que awscli a renseigné ces informations après une ligne contenant [default]. C'est la façon d'awscli de préciser le nom du profil par défaut.

Le fait est que vous pouvez configurer plusieurs profils dans le fichier credentials, pour configurer plusieurs accès reliés à des utilisateurs IAM différents par exemple. Pour chaque accès, vous devrez préciser un nom de profil différent entre crochets.
Pour utiliser ensuite un profil qui ne soit pas le profil par défaut, il vous suffit de préciser dans votre commande aws l'option --profile :

aws s3 ls --profile usertest

Configurer son accès SSO

Dans le cadre d'une organisation possédant de nombreux comptes AWS et afin de répondre aux bonnes pratiques en termes de gestion des accès, il est possible que vous n'ayez pas à disposition d'utilisateur IAM mais accès à des utilisateurs SSO.
Ces utilisateurs sont déclarés dans une solution nommée AWS SSO, qui permet de relier votre environnement AWS à un fournisseur d'identité externe, comme Azure AD par exemple. Ainsi, lorsque vous voulez vous connecter à AWS, c'est en utilisant votre compte Azure AD que vous pouvez vous authentifier.

Une grande différence avec un utilisateur IAM, est que l'accès que vous obtenez via un utilisateur SSO est temporaire. Par défaut, il ne dure qu'une heure, et ce autant pour les accès console que par programmation (cette durée peut être étendue au maximum à 12 heures). Par conséquent, vous n'avez pas d'ACCESS KEY et de SECRET ACCESS KEY permanentes. Vous devez les récupérer régulièrement.

Pour cela, il est nécessaire de se connecter à votre portail SSO, et de cliquer sur le profil d'accès que vous souhaitez utiliser, dans le lien "Command line or programmatic access".

Dans l'écran qui s'affiche alors, je vous recommande de cliquer sur la deuxième boite (option 2) qui permet de copier tout le bloc nécessaire à insérer dans votre fichier credentials.

Une fois les informations récupérées, vous pouvez alors modifier manuellement le fichier $HOME/.aws/credentials qui contient vos informations de profil, en précisant votre ACCESS KEY, SECRET ACCESS KEY, mais également votre SESSION TOKEN.
Si vous collez directement le bloc copié, cela va ajouter un nouveau profil portant le nom [numéro-de-compte_nom-du-profil]. Rien ne vous empêche évidemment de le renommer comme bon vous semble (default par exemple…).

Configurer un accès lié a un role assumé

Imaginons maintenant que vous ayez un compte d'accès à un compte vous appartenant et que celui ci soit configuré sur votre poste, mais que vous devez accéder temporairement à un compte ne vous appartenant pas pour, par exemple, effectuer un audit de sécurité pour un client.

La bonne pratique n'est pas de créer un utilisateur IAM dans le compte invité pour vous, et la création d'un compte SSO relié à un référentiel d'identité dans lequel vous n'êtes pas connu peut se révéler complexe. La bonne façon de procéder est de permettre à votre propre compte AWS d'assumer un rôle dans le compte AWS de votre client. Je ne décrirais pas dans ce poste la création du rôle mais vous trouverez facilement des références pour cela.

L'utilitaire awscli à prévu un moyen simple pour assumer un rôle existant dans un autre compte au travers d'une configuration dans le fichier $HOME/.aws/config.
En effet, vous pouvez dans ce fichier non seulement préciser les paramètres de configuration d'un profil existant dans $HOME/.aws/credentials mais aussi définir un profil assumable par un profil existant dans credentials :

[profile roleaudit] 
role_arn = arn:aws:iam::123456789012:role/roleaudit 
source_profile = default

source_profile représente ici le profil utilisé pour exécuter l'action d' "assume role", ce profil devant bien sûr exister et être configuré. Le role_arn représente lui le fameux rôle qui a été créé dans le compte du client que notre utilisateur défini dans le profile défault doit avoir le droit d'assumer.

Une fois cette configuration effectuée, dès l'instant ou ma configuration avec le profil default fonctionne, je n'ai plus qu'à préciser l'option --profile roleaudit avec awscli pour exécuter des actions dans le compte du client en fonction des droits associés au rôle.

Cette façon de faire vous permet d'éviter à avoir exécuter la commande aws sts assume-role, à récupérer les tokens et à les configurer dans votre fichier credentials. C'est donc un bon moyen de gagner du temps, awscli se chargeant à votre place d'effectuer toutes ces opérations en mémoire !

Utiliser un logiciel pour gérer ses connexions

Gérer manuellement ses accès en ligne de commande présente plusieurs inconvénients. Tout d'abord avec les accès liés à AWS SSO, c'est plusieurs fois par jour que vous serez obligés de modifier votre fichier credentials ce qui peut se révéler rapidement frustrant.
Ensuite, si vous utilisez un accès IAM, vous allez devoir configurer dans votre répertoire $HOME/.aws toutes les informations nécessaires pour accéder de manière permanente à votre compte, sans possibilité de protection ou chiffrement.

Si jamais le contenu de votre laptop ou serveur se retrouve entre de mauvaises mains, il est certain que ce répertoire risque d'être balayé pour récupérer vos accès. On assiste d'ailleurs à l'apparition de botnets spécialisés dans le vol de ces accès AWS.

Par conséquent, l'utilisation d'AWS SSO est clairement le meilleur choix malgré l'inconvénient de la rotation des accès. Pour diminuer l'impact de cette rotation, je vous recommande l'utilisation d'un outil formidable que j'utilise maintenant depuis plusieurs mois qui se nomme Leapp.
Cet outil vous permet de gérer de façon très simple et unifiée l'ensemble de vos comptes d'accès Cloud. Fini les fichiers texte comprenant les accès key qui trainent sur votre disque. Tout est géré et sécurisé par Leapp qui se charge pour les accès SSO du renouvellement automatique de la clé. Ainsi, vous pouvez travailler une journée entière sans avoir à vous soucier de sa rotation.

Si jamais vous travaillez à journée longue dans des environnements Cloud et manipulez de nombreux accès, cet outil est absolument indispensable !