IAM on The Cloud Optimist

Comment et pourquoi configurer AWS IAM Identity Center sur votre compte AWS

Wed, 19 Nov 2025 07:30:00 +0200

Introduction

Si vous jonglez avec plusieurs comptes AWS, ou même un seul compte avec différents utilisateurs, vous savez à quel point la gestion des accès peut devenir un véritable casse-tête. Créer des utilisateurs IAM individuels dans chaque compte, gérer leurs permissions, s’assurer que tout le monde utilise le MFA… Ouf, rien que d’y penser, ça peut donner des sueurs froides ! Et si je vous disais qu’il existe une solution élégante, centralisée et bien plus sécurisée pour gérer tout ça ? Mesdames et Messieurs, laissez-moi vous présenter IAM Identity Center !

Depuis que j’ai découvert et mis en place IAM Identity Center (que certains connaissent peut-être sous son ancien nom, AWS Single Sign-On ou AWS SSO), ma vie d’administrateur Cloud a radicalement changé. C’est le genre d’outil qui, une fois adopté, vous fait vous demander comment vous avez pu vivre sans.

Alors, qu’est-ce que c’est exactement, et pourquoi est-ce si génial ? C’est ce qu’on va voir ensemble.

IAM Identity Center : Késako ?

En termes simples, IAM Identity Center est un service AWS qui vous permet de gérer de manière centralisée l’accès à tous vos comptes AWS et à vos applications Cloud. Que vous ayez une poignée de comptes ou une organisation AWS tentaculaire avec des dizaines, voire des centaines de comptes, IAM Identity Center est là pour vous simplifier la tâche.

Il vous offre un point d’entrée unique (un portail d’accès web) pour vos utilisateurs, leur permettant d’accéder aux rôles et aux comptes auxquels ils ont droit, le tout avec une seule authentification.

Les avantages d’IAM Identity Center

Si je suis aussi enthousiaste, c’est parce que les bénéfices sont nombreux et significatifs. Pour vous citer les plus importants :

Single Sign-On (SSO) : Vos utilisateurs se connectent une seule fois via le portail AWS (ou via votre fournisseur d’identité existant si vous en avez un) et accèdent ensuite à tous les comptes et rôles qui leur sont assignés, sans avoir à se ré-authentifier pour chaque compte.
Gestion Centralisée : Vous gérez tous vos utilisateurs, groupes et leurs permissions (via des Permission Sets) depuis un seul endroit, même s’ils doivent accéder à des dizaines de comptes AWS différents.
Identifiants Temporaires : C’est l’un des points les plus importants ! Lorsque les utilisateurs accèdent à un compte via IAM Identity Center, ils obtiennent des identifiants temporaires à durée de vie limitée. Adieu les Access Keys IAM qui traînent et qui représentent un risque de sécurité majeur.
MFA (Multi-Factor Authentication) : Vous pouvez (et devriez !) imposer l’utilisation du MFA directement au niveau de la connexion à IAM Identity Center.

Si j’ai piqué votre curiosité et que vous souhaitez en savoir plus, je vous laisse consulter la documentation AWS sur IAM Identity Center. Pour ceux qui sont déjà convaincus, continuons ensemble !

Se Lancer avec IAM Identity Center

Mettre en place IAM Identity Center est étonnamment simple, surtout si vous utilisez l’annuaire intégré d’Identity Center comme source d’identité. Voici les étapes clés pour démarrer :

Configuration initiale : Rendez-vous dans la console AWS, et cherchez IAM Identity Center. Attention, choisissez bien votre région AWS pour héberger IAM Identity Center dès le départ, car il est actuellement complexe de changer la région d’IAM Identity Center une fois configuré. La configuration initiale est souvent guidée et rapide. Vous choisirez votre source d’identité (l’annuaire Identity Center, AWS Managed Microsoft AD, ou un fournisseur externe).
Création de groupes et d’utilisateurs : Définissez des groupes pertinents pour votre organisation (ex: Developers, Administrators, …). Créez ensuite vos utilisateurs et assignez-les à ces groupes. Si vous utilisez un IdP externe, cette étape consistera plutôt à synchroniser vos utilisateurs et groupes existants.
Création des Permission Sets : Un Permission Set est un ensemble de permissions (similaire à une policy IAM) que vous allez pouvoir réutiliser. Vous pouvez partir de policies managées par AWS (ex: AdministratorAccess ou ReadOnlyAccess) ou créer les vôtres.
Assignation des accès : C’est ici que la magie opère. Vous assignez un groupe (ou un utilisateur) à un ou plusieurs comptes AWS, en leur donnant le droit d’utiliser un Permission Set spécifique sur ces comptes. Par exemple, le groupe Developers peut avoir le Permission Set PowerUserAccess sur les comptes AWS de développement.
Imposer le MFA : Dans les paramètres d’IAM Identity Center, configurez le MFA pour qu’il soit obligatoire pour tous vos utilisateurs.
Partager l’URL d’accès AWS : Chaque configuration IAM Identity Center a une URL unique pour le portail d’accès (ex: d-xxxxxxxxxx.awsapps.com/start). C’est cette URL que vos utilisateurs mettront en favori pour se connecter.

Une fois connectés au portail, les utilisateurs verront la liste des comptes AWS et des rôles (définis par les Permission Sets) auxquels ils ont accès. Un clic, et ils sont dans la console du compte AWS choisi avec les bonnes permissions !

Ils peuvent aussi obtenir des identifiants temporaires pour la CLI. Mais d’ailleurs, comment faire pour se connecter à un compte AWS en CLI via IAM Identity Center ? Voyons ça ensemble !

Configurer les accès CLI

La documentation d’AWS pour configurer l’authentification CLI avec IAM Identity Center est assez claire, mais je vais tout de même vous décrire les étapes. Je pars du principe que vous avez déjà installé votre AWS CLI.

La commande pour initier la configuration est la suivante :

`1`	`aws configure sso`

Ensuite, vous allez devoir rentrer quelques informations propres à votre IAM Identity Center. Le plus important étant le SSO start URL (que vous pouvez trouver dans IAM Identity Center sous le nom de AWS access portal URL, URL qui finit par /start). Il faut ensuite rentrer la région dans laquelle se trouve votre configuration, quant au SSO registration scopes, vous pouvez laisser la valeur par défaut.

SSO session name (Recommended): default
SSO start URL [None]: https://xxxxxxxxxxxx.awsapps.com/start
SSO region [None]: eu-west-1
SSO registration scopes [sso:account:access]:

Si tout se passe bien, une fenêtre devrait s’ouvrir dans votre navigateur pour valider votre identité. Une fois cela fait, retournez dans votre terminal.

Dans mon cas, je ne possède qu’un seul compte AWS, et IAM Identity Center me le sélectionne par défaut. Mais vous aurez peut-être le choix dans le compte AWS à sélectionner. Idem pour le role.

Enfin, choisissez un nom de profil à utiliser pour vos futurs appels API. Je vous conseille d’utiliser default, ce qui vous permettra de ne pas avoir à rajouter --profile my-aws-profile à la fin de chacune de vos commandes.

The only AWS account available to you is: xxxxxxxxxxxx
Using the account ID xxxxxxxxxxxx
The only role available to you is: AdministratorAccess
Using the role name "AdministratorAccess"
Default client Region [None]: eu-west-1
CLI default output format (json if not specified) [None]: json
Profile name [AdministratorAccess-xxxxxxxxxxxx]: default
The AWS CLI is now configured to use the default profile.
Run the following command to verify your configuration:

aws sts get-caller-identity

Et voilà, le tour est joué !

Conclusion

Vous l’aurez compris, je suis un grand fan d’AWS IAM Identity Center. Il apporte une couche de sécurité indispensable tout en simplifiant considérablement la gestion des accès, que ce soit pour les administrateurs ou pour les utilisateurs.

C’est un véritable pilier pour une infrastructure AWS bien gérée et sécurisée. Si vous ne l’utilisez pas encore, je vous encourage vivement à explorer sa mise en place. C’est un investissement en temps minime pour des gains en sécurité et en efficacité énormes.

Votre infrastructure (et vos équipes de sécurité) vous diront merci !

Pourquoi taguer vos ressources AWS est indispensable ?

Tue, 24 Jun 2025 07:30:00 +0200

Introduction

Plus on déploie de services sur AWS, plus on commence à s’y perdre. Au début, on connaît par coeur tous les services qu’on utilise, le nombre de Lambdas ou d’EC2 qui sont lancées. Mais petit à petit, il est facile de ne plus savoir où donner de la tête, surtout lorsque différents projets s’accumulent. Retrouver rapidement quelles ressources appartiennent à quel projet, ou identifier celles qui n’ont pas été correctement nettoyées après un PoC, tout cela peut vite devenir un casse-tête. Et c’est sans parler de la vision des coûts !

Heureusement, il existe une pratique simple mais incroyablement puissante : le tagging.

Dans cet article, j’aimerais vous montrer qu’une bonne stratégie de tags est cruciale pour votre organisation, votre gestion des coûts, et pour la sécurité de votre compte AWS.

À vos marques. Prêts ? Taguez !

Pourquoi les tags sont-ils utiles ?

Imaginez des étiquettes sur des boîtes de déménagement. Sans elles, impossible de savoir ce qu’il y a dedans ou à quelle pièce elles appartiennent. Les tags sur AWS, c’est pareil ! Un tag est une information (sous la forme clé-valeur) que vous assignez à vos ressources (instances EC2, buckets S3, bases de données RDS, etc.).

Une bonne stratégie de tagging vous permet notamment de :

Identifier des ressources orphelines : C’est le grand classique. Une ressource sans tag Project ou Owner ? Il y a de fortes chances qu’elle ait été oubliée et qu’elle consomme des ressources (et donc de l’argent) pour rien. Lister les ressources non taguées (ou mal taguées) est une première étape essentielle pour faire le ménage.
Ventiler les coûts : En taguant vos ressources avec un identifiant de projet, de centre de coût, ou d’équipe, vous pouvez ensuite utiliser AWS Cost Explorer pour filtrer vos dépenses et comprendre précisément quels projets consomment le plus. Indispensable pour la refacturation interne ou simplement pour optimiser votre budget.
Automatiser des actions : Les tags peuvent servir de déclencheurs pour des scripts d’automatisation (par exemple, sauvegarder toutes les instances EC2 avec le tag Backup=Daily).
Gérer les accès et la sécurité : Le service AWS IAM peut utiliser les tags pour accorder des permissions granulaires.

Bref, taguer, c’est la base d’une bonne gouvernance Cloud. Pour plus de détails, je vous invite à consulter le guide de tagging proposé par AWS.

On peut fort heureusement associer plusieurs tags à une même ressource. Mais cela pose la question : combien de tags sont nécessaires ?

Cela va dépendre de votre entreprise et de chaque projet, mais globalement, il y a des tags qui ne font pas de mal, peu importe votre situation :

Project : Le nom du projet lié à la ressource. Généralement, le nom du repository GitHub fait l’affaire
Environment : L’environnement désiré (dev, val, prod, …). Même si vous avez des comptes AWS cloisonnés, cela vous permettra d’identifier si une ressource s’est perdue durant un déploiement
Owner : L’owner de la ressource. Cela pourrait être une personne, mais plus idéalement une équipe (frontend, backend, security, …)

Selon votre usage, vous aurez sûrement d’autres idées de tags, mais avec ceux-ci, ce sera déjà un bon début ! Et dans le doute, n’hésitez pas à consulter les best practices de tagging recommandées par AWS.

Voyons maintenant quelques cas concrets de l’utilité des tags dans AWS.

AWS Cost Explorer : Suivre les coûts grâce aux tags

L’un des avantages les plus concrets du tagging est la visibilité qu’il apporte sur vos dépenses. AWS Cost Explorer est l’outil de prédilection pour cela.

Une fois vos ressources correctement taguées (par exemple, avec le tag Project), vous devez activer ces tags pour l’allocation des coûts dans la console de gestion de la facturation AWS (Billing and Cost Management -> Cost Organization -> Cost Allocation Tags). Attention, il peut y avoir un délai avant que les tags activés n’apparaissent dans Cost Explorer.

Une fois activés, vous pouvez :

Filtrer par tag : Dans Cost Explorer, vous pouvez filtrer vos coûts par la valeur d’un tag spécifique.
Grouper par tag : Vous pouvez également choisir de grouper vos dépenses par tag. Cela vous donnera une vue d’ensemble de la répartition des coûts entre les différents projets, environnements, etc.
Créer des budgets basés sur les tags : Avec AWS Budgets, vous pouvez définir des seuils d’alerte pour les coûts associés à des tags spécifiques, vous aidant à éviter les mauvaises surprises.

Exemple de filtrage par tag pour mon blog : les coûts sont minimes, suis-je un expert FinOps ?

Cette capacité à disséquer votre facture AWS par tags transforme la gestion des coûts d’une corvée obscure en un exercice transparent et contrôlable. C’est un must pour toute organisation soucieuse de son budget Cloud. Vous pourrez désormais rajouter FinOps dans votre bio LinkedIn !

AWS Resource Explorer : Garder un œil sur les ressources déployées

Maintenant que l’on est convaincu de l’utilité des tags, comment fait-on pour lister toutes les ressources qui utilisent un tag précis ? Nous allons le voir ensemble avec une partie dans la console AWS, et une partie qui se passera dans le terminal (pour tous les geeks qui lisent cet article !).

L’exploration visuelle dans la console AWS

Si vous n’êtes pas encore familier avec AWS Resource Explorer, c’est le moment de le découvrir ! Ce service, relativement récent, vous permet de rechercher et de découvrir vos ressources AWS à travers toutes les régions de votre compte, en utilisant une interface simple, un peu comme un moteur de recherche.

L’avantage principal de Resource Explorer est sa capacité à vous donner une vue unifiée. Plus besoin de sauter de région en région. Vous activez l’indexation, et ensuite, vous pouvez rechercher vos ressources par nom, ID, et bien sûr… par tag !

C’est un excellent outil pour :

Avoir une vue d’ensemble rapide.
Explorer visuellement les ressources associées à un tag spécifique.
Identifier rapidement des ressources sans avoir à coder quoi que ce soit.

Pour l’utiliser, activez-le dans les régions souhaitées (ou toutes), laissez-le indexer vos ressources, puis utilisez la barre de recherche avec une syntaxe comme tag.key:Project tag.value:Cloud*.

Exemple de recherche par tag pour mon blog : seulement trois ressources permettent de gérer ce blog !

Une approche plus technique avec AWS CLI

Pour ceux qui, comme moi, aiment avoir la main via la ligne de commande, ou qui ont besoin d’automatiser ces recherches, l’AWS CLI reste une alliée de choix. Plus précisément, c’est le service resourcegroupstaggingapi qui va nous intéresser.

La commande clé est get-resources. Voici un exemple typique pour lister les ARN de toutes les ressources ayant le tag Project avec la valeur “Cloud Antoine Delia” :

1
2
3

aws resourcegroupstaggingapi get-resources \
    --tag-filters "Key=Project,Values=Cloud Antoine Delia" \
    | jq "[.ResourceTagMappingList[].ResourceARN]"

Ce qui nous donne :

1
2
3

[
  "arn:aws:s3:::antoiXXXXXXXXXXXXX"
]

Décortiquons un peu :

aws resourcegroupstaggingapi get-resources : C’est l’appel à l’API, jusqu’ici, tout va bien.
--tag-filters "Key=Project,Values=Cloud Antoine Delia" : C’est ici qu’on spécifie notre filtre. On cherche le tag Project qui a la valeur “Cloud Antoine Delia”. Vous pouvez ajouter plusieurs filtres.
| jq "[.ResourceTagMappingList[].ResourceARN]" : jq est un outil formidable pour manipuler du JSON en ligne de commande. Ici, on l’utilise pour extraire proprement la liste des ARN des ressources trouvées (vous pouvez vous en passer, mais pourquoi se compliquer la vie ?).

Eh attends une minute ! Dans la console, tu nous montres trois ressources, et là il n’y en a plus qu’une ! Elle est où l’arnaque ?

Habilement remarqué ! Il faut savoir que lorsque vous faites votre appel à l’API, vous utilisez une region par défaut. Or, si vous avez des ressources dans diverses régions, il faudra le spécifier. Ainsi, si l’on ajoute --region us-east-1 juste avant le pipe jq, on obtient bien nos deux ressources manquantes.

[
  "arn:aws:acm:us-east-1:6XXXXXXXXXXX0:certificate/f4ca3b13-XXXXXXXXXXXXX",
  "arn:aws:cloudfront::6XXXXXXXXXXX0:distribution/ERSXXXXXXXXXX"
]

Outre ce détail qu’il ne vous faudra pas oublier, cette commande est extrêmement puissante car vous pouvez l’intégrer dans des scripts pour :

Générer des rapports réguliers sur les ressources par projet.
Détecter automatiquement les ressources qui ne respectent pas votre politique de tagging.
Combiner avec d’autres commandes AWS CLI pour effectuer des actions sur les ressources listées.

Par exemple, vous pourriez ainsi lister toutes vos ressources d’un certain type (ex: toutes vos instances EC2) et de vérifier celles à qui il manque des tags essentiels.

Et si vous vous demandez si AWS n’offre pas déjà un service pour ça… C’est le cas ! Mais nous en parlerons dans un futur article (pour les curieux, je veux parler d’AWS Config).

AWS IAM : Sécuriser l’utilisation de vos ressources

Vos ressources sont déployées dans AWS, et vous souhaitez maintenant donner à une équipe la permission de gérer tout cela.

Seulement voilà, dans votre compte AWS, vous avez aussi des ressources critiques qui ne doivent surtout pas être compromises.

AWS IAM est là pour vous ! À l’aide d’une simple policy, vous pouvez spécifier que seules les ressources comportant un certain tag peuvent être modifiées par un utilisateur ou un groupe.

Prenons par exemple le cas suivant : vous aimeriez la possibilité à une équipe de démarrer ou stopper certaines instances EC2, mais de les empêcher d’accidentellement stopper une instance EC2 critique !

Il vous suffit d’ajouter la policy suivante à vos utilisateurs :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowStartStopEC2IfProjectCloud",
      "Effect": "Allow",
      "Action": [
        "ec2:StartInstances",
        "ec2:StopInstances"
      ],
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Project": "Cloud Antoine Delia"
        }
      }
    },
    {
      "Sid": "AllowDescribeToSeeInstances",
      "Effect": "Allow",
      "Action": "ec2:DescribeInstances",
      "Resource": "*"
    }
  ]
}

Ainsi, vos utilisateurs seront autonomes dans l’utilisation de leurs ressources, sans pour autant avoir la possibilité d’impacter d’autres ressources.

Conclusion

Vous l’aurez compris, une stratégie de tagging rigoureuse n’est pas une option, c’est une nécessité pour opérer sereinement sur AWS. Que ce soit sur le plan organisationnel, financier, ou encore dans la gestion de la sécurité, AWS vous donne les moyens de tirer pleinement parti de vos tags.

Alors, un petit conseil : si ce n’est pas déjà fait, définissez une politique de tagging claire dans votre organisation, appliquez-la, et utilisez ces outils pour vérifier régulièrement que tout est en ordre. Vous m’en remercierez plus tard !