Différences

Ci-dessous, les différences entre deux révisions de la page.

--- eadl:bloc4:fm4:td1 [2026/04/14 20:38] – [8. Déploiement] jcheron
+++ eadl:bloc4:fm4:td1 [2026/06/08 18:12] (Version actuelle) – [Challenge final] jcheron
@@ Ligne 1: / Ligne 1: @@
-====== Déploiement AWS avec Terraform (EC2 + SSH) ======
+====== TD1 – Conception d’une stratégie IAM sécurisée ======
-===== Objectif =====
-Mettre en place une instance EC2 sur AWS avec :
-  * Terraform
+===== Objectifs =====
-  * Une clé SSH
-  * Un Security Group (port 22)
-  * Connexion SSH fonctionnelle
+  * Concevoir une stratégie IAM cohérente
+  * Appliquer le principe du moindre privilège
+  * Comprendre les différences entre users, groupes et rôles
+  * Industrialiser IAM avec Terraform
-===== Prérequis =====
+===== Contexte =====
-  * Compte AWS
+Vous intervenez comme ingénieur Cloud dans une startup.
-  * Terraform installé
-  * AWS CLI configuré
-  * Une paire de clés SSH
+L’infrastructure AWS existe déjà, mais aucun cadre de sécurité IAM n’a été défini.
-===== 1. Configuration du provider =====
+Chaque développeur dispose actuellement de droits administrateur.
-Fichier ''main.tf'' :
-<sxh json>
+Un audit de sécurité impose :
+  * une refonte complète des accès
+  * une gestion par rôles
+  * une limitation stricte des permissions
+===== Objectif technique =====
+Mettre en place une architecture IAM sécurisée pour :
+  * les administrateurs
+  * les développeurs
+  * les analystes
+Le tout doit être :
+  * reproductible
+  * versionné
+  * automatisé avec Terraform
+===== Contraintes =====
+Vous devez respecter les règles suivantes :
+  * Aucun utilisateur ne doit avoir de droits administrateur globaux
+  * Le principe du moindre privilège est obligatoire
+  * Les permissions doivent être mutualisées (pas de duplication inutile)
+  * Les accès doivent être compréhensibles et maintenables
+  * Toute la configuration doit être réalisée avec Terraform
+===== Infrastructure existante =====
+Une première tentative de mise en place IAM a été réalisée.
+Fichier : `iam/main.tf`
+<sxh js>
 provider "aws" {
-  region = "eu-west-3"
+  region = "eu-west-1"
 }
-</sxh>
+resource "aws_iam_user" "dev1" {
+  name = "dev1"
+}
-===== 2. Déclaration de la variable SSH =====
+resource "aws_iam_user" "dev2" {
-<sxh json>
+  name = "dev2"
-variable "public_key_path" {
-  description = "Chemin vers la clé publique SSH"
-  type        = string
 }
-</sxh>
+resource "aws_iam_user_policy" "dev_policy" {
+  name = "dev-policy"
+  user = aws_iam_user.dev1.name
-===== 3. Création de la clé AWS =====
+  policy = jsonencode({
-<sxh json>
+    Version = "2012-10-17",
-resource "aws_key_pair" "zerp_key" {
+    Statement = [
-  key_name   = "zerp-key"
+      {
-  public_key = file(var.public_key_path)
+        Effect = "Allow",
+        Action = "*",
+        Resource = "*"
+      }
+    ]
+  })
 }
-</sxh>
+resource "aws_iam_user_policy_attachment" "dev2_admin" {
-===== 4. Security Group (SSH) =====
+  user       = aws_iam_user.dev2.name
-<sxh json>
+  policy_arn = "arn:aws:iam::aws:policy/AdministratorAccess"
-resource "aws_security_group" "zerp_sg" {
-  name = "zerp-sg"
-  ingress {
-    from_port   = 22
-    to_port     = 22
-    protocol    = "tcp"
-    cidr_blocks = ["0.0.0.0/0"]
-  }
-  egress {
-    from_port   = 0
-    to_port     = 0
-    protocol    = "-1"
-    cidr_blocks = ["0.0.0.0/0"]
-  }
 }
 </sxh>
-===== 5. Création de l'instance EC2 =====
+===== Ressources =====
-<sxh json>
-resource "aws_instance" "zerp_ec2" {
-  ami           = "ami-xxxxxxxx"
-  instance_type = "t2.micro"
-  key_name = aws_key_pair.zerp_key.key_name
+Documentation officielle :
-  vpc_security_group_ids = [
-    aws_security_group.zerp_sg.id
-  ]
-  tags = {
-    Name = "zerp-ec2"
-  }
-}
-</sxh>
-===== 6. Fichier terraform.tfvars =====
+  * AWS IAM : concepts (users, groups, roles)
-<sxh json>
+  * AWS IAM Policy JSON
-public_key_path = "C:/Users/ton_user/.ssh/id_rsa.pub"
+  * Bonnes pratiques AWS IAM (least privilege)
-</sxh>
+Commandes utiles :
-===== 7. Initialisation Terraform =====
+Fichier : `commandes/terraform.txt`
 <sxh bash>
 terraform init
+terraform plan
+terraform apply
+terraform destroy
 </sxh>
+===== Travail à réaliser =====
-===== 8. Déploiement =====
+<WRAP round todo>
-<sxh bash>
-terraform apply
-</sxh>
-Valider avec :
+Vous devez produire une configuration Terraform permettant de :
-''yes''
+  - Partir de l’existant et le corriger
+  - Conserver les utilisateurs actuels
+  - Reconcevoir entièrement la gestion des permissions
-===== 9. Récupération de l’IP =====
+  - Créer les entités suivantes :
-<sxh bash>
+    * 1 groupe Admin
-terraform show
+    * 1 groupe Dev
-</sxh>
+    * 1 groupe Analyst
-Chercher :
+  - Définir des policies adaptées :
-<sxh>
+    * Admin : gestion complète de l’infrastructure
-public_ip = "xxx.xxx.xxx.xxx"
+    * Dev : gestion EC2 uniquement
-</sxh>
+    * Analyst : lecture S3 uniquement
+  - Associer correctement :
+    * users → groupes
+    * groupes → policies
-===== 10. Connexion SSH =====
+  - Mettre en place au moins un rôle IAM pour un service AWS
-==== Amazon Linux ====
-<sxh bash;gutter:false>
-ssh -i $HOME/.ssh/id_rsa ec2-user@IP
-</sxh>
-==== Ubuntu ====
+Livrables attendus :
-<sxh bash>
-ssh -i  $ HOME/.ssh/id_rsa ubuntu@IP
-</sxh>
+  * code Terraform fonctionnel
+  * structure claire des fichiers
+  * justification des choix
+</WRAP>
+===== Point d’attention (volontaire) =====
-===== 11. Vérification =====
+Une mauvaise pratique courante consiste à utiliser :
-Si tout fonctionne :
-<sxh bash;gutter:false>
+  * Action: "*"
-[ec2-user@ip-xxx-xxx-xxx-xxx ~] $
+  * Resource: "*"
-</sxh>
+Cette pratique est interdite dans ce TD.
+<WRAP round question>
+Pourquoi cette pratique apparaît-elle souvent dans des projets réels ?
+Dans quels cas peut-elle sembler "pratique" ?
+</WRAP>
+===== Phase d’analyse =====
+<WRAP round question>
+Quels sont les problèmes de sécurité présents dans l’infrastructure fournie ?
+Lesquels sont critiques ? Lesquels sont acceptables temporairement ?
+</WRAP>
+===== Phase de correction =====
+Vous devez revoir votre architecture si :
+  * un utilisateur a trop de droits
+  * une policy est trop large
+  * des permissions sont dupliquées
+===== Extension =====
+Ajouter :
+  * une séparation environnement DEV / PROD
+  * une restriction par ressource (ex : un seul bucket S3)
+===== Challenge final =====
+Un développeur doit pouvoir :
-===== Problèmes courants =====
+  * lancer une instance EC2
-==== Permission denied ====
+  * mais ne pas pouvoir supprimer une instance existante
-Mauvais utilisateur (ec2-user vs ubuntu)
+Implémenter cette contrainte.
-==== Connection timed out ====
+<WRAP round question>
+Pourquoi cette règle est-elle difficile à implémenter proprement en IAM ?
+</WRAP>
-Port 22 non ouvert
+===== Restitution =====
-Security group mal configuré
+Vous devez être capable d’expliquer :
-===== Bonnes pratiques =====
+  * votre architecture IAM
+  * vos choix de policies
+  * les compromis réalisés
-  * Ne pas hardcoder les chemins
-  * Utiliser des variables Terraform
-  * Ne jamais versionner les clés privées
-  * Utiliser terraform.tfvars pour les configs locales