# Fichier: python_cheats/cheatsheets/IAM.txt
# Cheatsheet AWS IAM - Guide Complet pour Débutants


═══════════════════════════════════════════════════════════════════════════════
[OK] IAM (IDENTITY AND ACCESS MANAGEMENT) - GESTION DES ACCÈS
═══════════════════════════════════════════════════════════════════════════════

# [REFLEXION] QU'EST-CE QUE IAM?
IAM = système qui contrôle QUI peut faire QUOI sur vos ressources AWS.
C'est le système de sécurité et de permissions de AWS.

[IDEE] Analogie: IAM = système de badges et portes sécurisées dans une entreprise
- Certaines personnes ont badge pour accéder au parking
- D'autres ont badge pour accéder aux bureaux
- Le PDG a accès partout
- Le stagiaire a accès limité

# [OBJECTIF] CONCEPTS FONDAMENTAUX (BIEN COMPRENDRE)

## 1. Users (Utilisateurs)
= Une personne ou une application qui a besoin d'accéder à AWS
Exemple: Jean, développeur dans votre équipe

## 2. Groups (Groupes)
= Collection d'utilisateurs avec permissions similaires
Exemple: Groupe "Developers" avec tous les développeurs
Avantage: Gérer permissions par groupe plutôt que utilisateur par utilisateur

## 3. Roles (Rôles)
= Ensemble de permissions qu'un SERVICE AWS peut utiliser
Exemple: Permettre à EC2 d'accéder à S3
[ATTENTION] IMPORTANT: Roles ≠ Users
- Users = pour personnes
- Roles = pour services AWS (EC2, Lambda, etc.)

## 4. Policies (Politiques)
= Document JSON qui définit les permissions
Exemple: "Peut lire S3 mais pas supprimer"

# [GRAPHIQUE] HIÉRARCHIE IAM (Comment tout s'organise)

Compte AWS Root ([ROUGE] DANGEREUX - NE PAS UTILISER!)
    │
    ├─── Utilisateur IAM (Jean)
    │    └─── Policies attachées directement
    │
    ├─── Groupe IAM (Developers)
    │    ├─── Jean (membre)
    │    ├─── Marie (membre)
    │    └─── Policies du groupe (tous les membres héritent)
    │
    └─── Role IAM (EC2-S3-Access)
         ├─── Trust Policy (qui peut assumer ce role?)
         └─── Permissions Policy (que peut faire ce role?)

# === USERS (UTILISATEURS) ===

# [NOTE] EXPLICATION: Un utilisateur = une identité permanente dans AWS
# Utilisé pour: des personnes qui ont besoin d'accéder à AWS

# Créer utilisateur
aws iam create-user --user-name john

# [IDEE] Ce que ça fait:
# - Crée un compte "john" dans votre compte AWS
# - Par défaut, john n'a AUCUNE permission (principe du moindre privilège)
# - john ne peut PAS encore se connecter (pas de mot de passe ni clés)

# Output:
# {
#     "User": {
#         "UserName": "john",
#         "UserId": "AIDAJEXAMPLE",
#         "Arn": "arn:aws:iam::123456789012:user/john",
#         "CreateDate": "2024-01-15T10:30:00Z"
#     }
# }

# Créer avec tags (pour organisation)
aws iam create-user --user-name john \
  --tags Key=Department,Value=Engineering Key=Team,Value=Backend

# [IDEE] Tags = étiquettes pour organiser ressources
# Utiles pour: facturation, organisation, recherche
# Exemple: "Montrer tous les utilisateurs du département Engineering"

# Lister tous les utilisateurs
aws iam list-users

# Output:
# {
#     "Users": [
#         {
#             "UserName": "john",
#             "UserId": "AIDAJEXAMPLE",
#             "Arn": "arn:aws:iam::123456789012:user/john",
#             "CreateDate": "2024-01-15T10:30:00Z"
#         },
#         {
#             "UserName": "marie",
#             "UserId": "AIDAIEXAMPLE2",
#             "Arn": "arn:aws:iam::123456789012:user/marie",
#             "CreateDate": "2024-01-14T09:20:00Z"
#         }
#     ]
# }

# Lister avec format table (plus lisible)
aws iam list-users --output table

# Obtenir info utilisateur spécifique
aws iam get-user --user-name john

# Obtenir info sur MOI (utilisateur actuel)
aws iam get-user
# [IDEE] Utile pour vérifier quel utilisateur vous utilisez

# Supprimer utilisateur
aws iam delete-user --user-name john

# [ATTENTION] ATTENTION: Vous devez d'abord:
# 1. Supprimer toutes les clés d'accès
# 2. Détacher toutes les policies
# 3. Retirer des groupes
# Sinon vous aurez une erreur!

# === ACCESS KEYS (CLÉS D'ACCÈS) ===

# [NOTE] EXPLICATION: Access Keys = identifiants pour AWS CLI/SDK/API
# Composées de 2 parties:
# - Access Key ID = identifiant public (comme nom d'utilisateur)
# - Secret Access Key = mot de passe secret (à garder secret!)

# Créer clé d'accès pour un utilisateur
aws iam create-access-key --user-name john

# Output ([ATTENTION] TRÈS IMPORTANT - Sauvegarder immédiatement!):
# {
#     "AccessKey": {
#         "UserName": "john",
#         "AccessKeyId": "AKIAI44QH8DHBEXAMPLE",
#         "Status": "Active",
#         "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
#         "CreateDate": "2024-01-15T10:30:00Z"
#     }
# }

# [ATTENTION] CRITIQUE: C'est la SEULE fois où vous verrez le SecretAccessKey!
# - Copiez-le immédiatement dans un endroit sûr
# - Si vous le perdez, vous devrez créer une nouvelle clé
# - Ne JAMAIS partager ces clés
# - Ne JAMAIS les commiter dans Git

# [IDEE] Donner ces clés à john pour qu'il configure AWS CLI:
# john $ aws configure
# AWS Access Key ID: AKIAI44QH8DHBEXAMPLE
# AWS Secret Access Key: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
# ...

# Lister toutes les clés d'un utilisateur
aws iam list-access-keys --user-name john

# Output:
# {
#     "AccessKeyMetadata": [
#         {
#             "UserName": "john",
#             "AccessKeyId": "AKIAI44QH8DHBEXAMPLE",
#             "Status": "Active",
#             "CreateDate": "2024-01-15T10:30:00Z"
#         }
#     ]
# }

# [IDEE] Note: Vous ne voyez PAS le SecretAccessKey (c'est normal, c'est secret!)

# Désactiver clé (sans la supprimer)
aws iam update-access-key \
  --user-name john \
  --access-key-id AKIAI44QH8DHBEXAMPLE \
  --status Inactive

# [IDEE] Quand l'utiliser?
# - Vous suspectez que la clé a été compromise
# - Vous voulez temporairement empêcher l'accès
# - Test de rotation de clés
# Avantage: Vous pouvez la réactiver plus tard

# Réactiver clé
aws iam update-access-key \
  --user-name john \
  --access-key-id AKIAI44QH8DHBEXAMPLE \
  --status Active

# Supprimer clé (DÉFINITIF)
aws iam delete-access-key \
  --user-name john \
  --access-key-id AKIAI44QH8DHBEXAMPLE

# [IDEE] Après suppression, john ne pourra plus utiliser cette clé
# Il devra en créer une nouvelle

# [VERROUILLE] BONNES PRATIQUES POUR LES CLÉS:
# [OK] Rotation régulière (tous les 90 jours)
# [OK] Une clé par utilisateur (pas de partage!)
# [OK] Désactiver/supprimer clés inutilisées
# [OK] Utiliser IAM Roles au lieu de clés quand possible (EC2, Lambda)
# [X] Ne JAMAIS hardcoder dans le code
# [X] Ne JAMAIS commiter dans Git
# [X] Ne JAMAIS partager par email/Slack

# === GROUPS (GROUPES) ===

# [NOTE] EXPLICATION: Groupe = collection d'utilisateurs
# Au lieu de donner permissions à chaque utilisateur individuellement,
# vous créez un groupe avec permissions et ajoutez utilisateurs dedans.

# [IDEE] Exemple d'organisation type:
# - Groupe "Admins" -> Permissions complètes
# - Groupe "Developers" -> Accès EC2, S3, RDS
# - Groupe "ReadOnly" -> Lecture seule partout
# - Groupe "Billing" -> Voir les coûts

# Créer groupe
aws iam create-group --group-name Developers

# Output:
# {
#     "Group": {
#         "GroupName": "Developers",
#         "GroupId": "AGPAJEXAMPLE",
#         "Arn": "arn:aws:iam::123456789012:group/Developers",
#         "CreateDate": "2024-01-15T10:30:00Z"
#     }
# }

# Créer plusieurs groupes
aws iam create-group --group-name Admins
aws iam create-group --group-name ReadOnly
aws iam create-group --group-name Billing

# Lister tous les groupes
aws iam list-groups

# Output:
# {
#     "Groups": [
#         {
#             "GroupName": "Developers",
#             "GroupId": "AGPAJEXAMPLE",
#             "Arn": "arn:aws:iam::123456789012:group/Developers",
#             "CreateDate": "2024-01-15T10:30:00Z"
#         },
#         {
#             "GroupName": "Admins",
#             ...
#         }
#     ]
# }

# Ajouter utilisateur à un groupe
aws iam add-user-to-group \
  --user-name john \
  --group-name Developers

# [IDEE] Ce que ça fait:
# - john hérite maintenant de TOUTES les permissions du groupe Developers
# - Si vous ajoutez une permission au groupe, john l'obtient automatiquement
# - john peut être dans plusieurs groupes (exemple: Developers + Billing)

# Ajouter john à plusieurs groupes
aws iam add-user-to-group --user-name john --group-name Developers
aws iam add-user-to-group --user-name john --group-name Billing

# Retirer utilisateur d'un groupe
aws iam remove-user-from-group \
  --user-name john \
  --group-name Developers

# [IDEE] john perd les permissions du groupe Developers

# Lister tous les utilisateurs d'un groupe
aws iam get-group --group-name Developers

# Output:
# {
#     "Group": {
#         "GroupName": "Developers",
#         ...
#     },
#     "Users": [
#         {
#             "UserName": "john",
#             ...
#         },
#         {
#             "UserName": "marie",
#             ...
#         }
#     ]
# }

# Supprimer groupe
aws iam delete-group --group-name Developers

# [ATTENTION] ATTENTION: Le groupe doit être vide
# 1. Retirer tous les utilisateurs
# 2. Détacher toutes les policies
# 3. Puis supprimer

# === POLICIES (POLITIQUES) ===

# [NOTE] EXPLICATION: Policy = document JSON qui définit les permissions
# Format: "Effect": "Allow" ou "Deny"
#         "Action": Quelles actions? (s3:GetObject, ec2:StartInstances, etc.)
#         "Resource": Sur quelles ressources? (bucket spécifique, toutes les EC2, etc.)

# [OBJECTIF] 2 TYPES DE POLICIES:

# 1⃣ AWS Managed Policies
#    = Policies créées et maintenues par AWS
#    Exemples: AmazonS3ReadOnlyAccess, AmazonEC2FullAccess
#    [OK] Avantages: Prêtes à l'emploi, mises à jour par AWS
#    [OK] Recommandées pour débuter

# 2⃣ Customer Managed Policies
#    = Policies que VOUS créez
#    Pour: besoins spécifiques, contrôle fin

# Lister toutes les policies AWS managées
aws iam list-policies --scope AWS

# [IDEE] Il y en a beaucoup! (plusieurs centaines)
# Filtre utile:
aws iam list-policies --scope AWS --max-items 10

# Lister VOS policies custom
aws iam list-policies --scope Local

# Obtenir détails d'une policy
aws iam get-policy --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

# Output:
# {
#     "Policy": {
#         "PolicyName": "AmazonS3ReadOnlyAccess",
#         "Arn": "arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess",
#         "Description": "Provides read only access to all buckets via the AWS Management Console",
#         "DefaultVersionId": "v1",
#         ...
#     }
# }

# Obtenir le JSON de la policy (voir les permissions exactes)
aws iam get-policy-version \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess \
  --version-id v1

# [IDEE] Voir le contenu JSON pour comprendre exactement ce qui est autorisé

# === EXEMPLES DE POLICIES JSON (COMPRENDRE LA STRUCTURE) ===

# [NOTE] STRUCTURE D'UNE POLICY:

# policy.json - Accès S3 lecture seule sur UN bucket spécifique
{
    "Version": "2012-10-17",              # Version du langage (toujours cette valeur)
    "Statement": [                         # Liste de "règles"
        {
            "Effect": "Allow",             # "Allow" = autoriser, "Deny" = refuser
            "Action": [                    # Quelles actions?
                "s3:GetObject",            # Télécharger fichiers
                "s3:ListBucket"            # Lister fichiers du bucket
            ],
            "Resource": [                  # Sur quelles ressources?
                "arn:aws:s3:::my-bucket",          # Le bucket lui-même
                "arn:aws:s3:::my-bucket/*"         # Tous les objets dans le bucket
            ]
        }
    ]
}

# [IDEE] Explication ligne par ligne:
# - Cette policy AUTORISE ("Allow")
# - 2 actions: télécharger fichiers (GetObject) et lister fichiers (ListBucket)
# - Uniquement sur le bucket "my-bucket" et son contenu
# - Résultat: L'utilisateur peut LIRE le bucket mais pas écrire, supprimer, etc.

# policy-admin-s3.json - Accès S3 COMPLET sur TOUS les buckets
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:*",              # "*" = toutes les actions S3
            "Resource": "*"                # "*" = toutes les ressources
        }
    ]
}

# [IDEE] Explication:
# - "s3:*" = Toutes les actions S3 (lire, écrire, supprimer, etc.)
# - "Resource": "*" = Sur tous les buckets et objets
# - C'est très permissif! Utiliser avec prudence

# policy-ec2-start-stop.json - Démarrer/arrêter instances EC2
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:StartInstances",      # Démarrer instances
                "ec2:StopInstances",       # Arrêter instances
                "ec2:DescribeInstances"    # Voir liste des instances
            ],
            "Resource": "*"                # Sur toutes les instances
        }
    ]
}

# [IDEE] Cas d'usage:
# Pour un utilisateur qui doit pouvoir démarrer/arrêter serveurs
# mais PAS les créer/supprimer

# policy-specific-instances.json - Accès SEULEMENT à certaines instances
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ec2:*",
            "Resource": [
                "arn:aws:ec2:us-east-1:123456789012:instance/i-1234567890abcdef0",
                "arn:aws:ec2:us-east-1:123456789012:instance/i-0987654321fedcba0"
            ]
        },
        {
            "Effect": "Allow",
            "Action": "ec2:Describe*",     # Voir la liste (nécessaire)
            "Resource": "*"
        }
    ]
}

# [IDEE] Explication:
# - Contrôle total sur 2 instances spécifiques seulement
# - Peut voir la liste de toutes les instances (mais pas les modifier)

# policy-deny-example.json - REFUSER certaines actions
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": "*"
        },
        {
            "Effect": "Deny",              # [ATTENTION] Deny a priorité sur Allow!
            "Action": "s3:DeleteBucket",   # Interdire suppression buckets
            "Resource": "*"
        }
    ]
}

# [IDEE] Explication:
# - Accès complet S3 SAUF la suppression de buckets
# - "Deny" est TOUJOURS prioritaire sur "Allow" (sécurité)
# - Même si autre policy dit "Allow", le "Deny" gagne

# === ATTACHER POLICIES (DONNER PERMISSIONS) ===

# [NOTE] EXPLICATION: Créer policy/groupe/user ne donne PAS automatiquement permissions
# Vous devez "attacher" (lier) la policy à l'utilisateur ou groupe

# [OBJECTIF] 3 FAÇONS D'ATTACHER POLICIES:
# 1. À un utilisateur directement
# 2. À un groupe (tous les membres héritent)
# 3. À un role (pour services AWS)

# Attacher policy managée AWS à un utilisateur
aws iam attach-user-policy \
  --user-name john \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

# [IDEE] Ce que ça fait:
# - john peut maintenant LIRE tous les buckets S3
# - john ne peut PAS écrire/supprimer (ReadOnly)
# - La policy reste attachée jusqu'à ce que vous la détachiez

# Attacher policy managée à un groupe
aws iam attach-group-policy \
  --group-name Developers \
  --policy-arn arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess

# [IDEE] Ce que ça fait:
# - TOUS les membres du groupe Developers peuvent voir les instances EC2
# - Utile pour donner permissions à toute une équipe

# Créer votre propre policy custom
aws iam create-policy \
  --policy-name MyS3ReadPolicy \
  --policy-document file://policy.json

# [IDEE] policy.json doit être dans le dossier actuel
# Output inclut le PolicyArn (vous en aurez besoin après)

# Output:
# {
#     "Policy": {
#         "PolicyName": "MyS3ReadPolicy",
#         "PolicyId": "ANPAJEXAMPLE",
#         "Arn": "arn:aws:iam::123456789012:policy/MyS3ReadPolicy",
#         ...
#     }
# }

# Attacher votre policy custom
aws iam attach-user-policy \
  --user-name john \
  --policy-arn arn:aws:iam::123456789012:policy/MyS3ReadPolicy

# Détacher policy d'un utilisateur
aws iam detach-user-policy \
  --user-name john \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

# [IDEE] john perd immédiatement cette permission

# Lister toutes les policies attachées à un utilisateur
aws iam list-attached-user-policies --user-name john

# Output:
# {
#     "AttachedPolicies": [
#         {
#             "PolicyName": "AmazonS3ReadOnlyAccess",
#             "PolicyArn": "arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess"
#         },
#         {
#             "PolicyName": "MyS3ReadPolicy",
#             "PolicyArn": "arn:aws:iam::123456789012:policy/MyS3ReadPolicy"
#         }
#     ]
# }

# [IDEE] Voir toutes les permissions de john

# Lister policies attachées à un groupe
aws iam list-attached-group-policies --group-name Developers

# === INLINE POLICIES (MÉTHODE ALTERNATIVE - MOINS RECOMMANDÉE) ===

# [NOTE] EXPLICATION: 2 types de policies:
# 1. Managed Policies (ci-dessus) - Réutilisables, recommandées
# 2. Inline Policies - Attachées directement, uniques à cet utilisateur/groupe

# [IDEE] Différence:
# - Managed: Créer UNE policy, l'attacher à plusieurs users/groups
# - Inline: Policy existe UNIQUEMENT pour cet user/group spécifique

# Quand utiliser Inline?
# - Relation 1:1 stricte (policy pour UN seul user)
# - Permissions très spécifiques qui ne seront jamais réutilisées

# Attacher inline policy directement à utilisateur
aws iam put-user-policy \
  --user-name john \
  --policy-name S3Access \
  --policy-document file://policy.json

# [IDEE] Ce que ça fait:
# - Crée ET attache la policy en une seule commande
# - La policy existe seulement pour john
# - Si vous supprimez john, la policy disparaît aussi

# Lister inline policies d'un utilisateur
aws iam list-user-policies --user-name john

# Output:
# {
#     "PolicyNames": [
#         "S3Access"
#     ]
# }

# Obtenir contenu d'une inline policy
aws iam get-user-policy \
  --user-name john \
  --policy-name S3Access

# Supprimer inline policy
aws iam delete-user-policy \
  --user-name john \
  --policy-name S3Access

# [OBJECTIF] MANAGED vs INLINE - Quelle méthode choisir?

# [OK] Utiliser MANAGED Policies (recommandé) quand:
# - Policy sera utilisée par plusieurs users/groups
# - Vous voulez réutiliser
# - Plus facile à gérer à grande échelle

# [OK] Utiliser INLINE Policies quand:
# - Relation 1:1 stricte
# - Permission très spécifique à UN utilisateur
# - Vous voulez que la policy disparaisse avec l'utilisateur

# === ROLES (POUR SERVICES AWS) ===

# [NOTE] EXPLICATION: Role ≠ User!
# 
# User = Pour une PERSONNE
# - A des credentials (clés d'accès)
# - Connexion longue durée
# 
# Role = Pour un SERVICE AWS
# - PAS de credentials permanents
# - Le service "assume" le role temporairement
# - Credentials temporaires (expiration automatique)

# [IDEE] Cas d'usage typiques:
# - Instance EC2 doit accéder à S3
# - Fonction Lambda doit écrire dans DynamoDB
# - Service ECS doit lire secrets dans Secrets Manager

# [OBJECTIF] POURQUOI UTILISER ROLES AU LIEU DE CLÉS?

# [X] Mauvaise méthode (DANGEREUX):
# 1. Créer clés d'accès AWS
# 2. Les mettre dans le code de l'app sur EC2
# Problèmes:
# - Clés hardcodées dans code
# - Risque de fuite si code est publié
# - Rotation difficile
# - Moins sécurisé

# [OK] Bonne méthode (SÉCURISÉ):
# 1. Créer IAM Role avec permissions S3
# 2. Attacher role à EC2
# 3. Code sur EC2 utilise automatiquement le role
# Avantages:
# - Pas de clés dans le code
# - Credentials temporaires auto-renouvelés
# - Rotation automatique
# - Beaucoup plus sécurisé

# === CRÉER UN ROLE (ÉTAPE PAR ÉTAPE) ===

# Étape 1: Créer Trust Policy
# = Document qui dit "QUI peut utiliser ce role"

# trust-policy.json - EC2 peut utiliser ce role
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "ec2.amazonaws.com"    # Le service EC2
            },
            "Action": "sts:AssumeRole"            # Action "assumer le role"
        }
    ]
}

# [IDEE] Explication:
# - "Principal": {"Service": "ec2.amazonaws.com"} = Le service EC2
# - "sts:AssumeRole" = Action d'assumer (prendre) le role
# - Résultat: Les instances EC2 peuvent utiliser ce role

# Étape 2: Créer le role
aws iam create-role \
  --role-name EC2-S3-Access-Role \
  --assume-role-policy-document file://trust-policy.json

# Output:
# {
#     "Role": {
#         "RoleName": "EC2-S3-Access-Role",
#         "RoleId": "AROAJEXAMPLE",
#         "Arn": "arn:aws:iam::123456789012:role/EC2-S3-Access-Role",
#         "AssumeRolePolicyDocument": {...},
#         "CreateDate": "2024-01-15T10:30:00Z"
#     }
# }

# [IDEE] À ce stade, le role existe mais n'a AUCUNE permission!

# Étape 3: Attacher permissions au role
aws iam attach-role-policy \
  --role-name EC2-S3-Access-Role \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

# [IDEE] Maintenant le role peut lire S3
# Toute instance EC2 avec ce role pourra lire S3

# Lister tous les roles
aws iam list-roles

# Obtenir info sur un role spécifique
aws iam get-role --role-name EC2-S3-Access-Role

# Lister policies attachées à un role
aws iam list-attached-role-policies --role-name EC2-S3-Access-Role

# Output:
# {
#     "AttachedPolicies": [
#         {
#             "PolicyName": "AmazonS3ReadOnlyAccess",
#             "PolicyArn": "arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess"
#         }
#     ]
# }

# Supprimer role (détacher policies d'abord!)
# Étape 1: Détacher toutes les policies
aws iam detach-role-policy \
  --role-name EC2-S3-Access-Role \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

# Étape 2: Supprimer le role
aws iam delete-role --role-name EC2-S3-Access-Role

# === INSTANCE PROFILES (POUR ATTACHER ROLE À EC2) ===

# [NOTE] EXPLICATION: Pour utiliser un role avec EC2, il faut un "Instance Profile"
# Instance Profile = conteneur qui contient le role
# C'est une étape technique nécessaire pour EC2

# [IDEE] Analogie: Role = badge, Instance Profile = porte-badge

# Étape 1: Créer instance profile
aws iam create-instance-profile \
  --instance-profile-name EC2-S3-Access-Profile

# Output:
# {
#     "InstanceProfile": {
#         "InstanceProfileName": "EC2-S3-Access-Profile",
#         "InstanceProfileId": "AIPAJEXAMPLE",
#         "Arn": "arn:aws:iam::123456789012:instance-profile/EC2-S3-Access-Profile",
#         "CreateDate": "2024-01-15T10:30:00Z",
#         "Roles": []                              # Vide pour l'instant
#     }
# }

# Étape 2: Ajouter role à instance profile
aws iam add-role-to-instance-profile \
  --instance-profile-name EC2-S3-Access-Profile \
  --role-name EC2-S3-Access-Role

# [IDEE] Maintenant l'instance profile contient le role

# Lister instance profiles
aws iam list-instance-profiles

# Étape 3: Attacher instance profile à instance EC2
aws ec2 associate-iam-instance-profile \
  --instance-id i-1234567890abcdef0 \
  --iam-instance-profile Name=EC2-S3-Access-Profile

# [IDEE] Ce que ça fait:
# - L'instance EC2 peut maintenant utiliser le role
# - Le code sur l'instance peut accéder à S3 sans clés hardcodées
# - AWS SDK détecte automatiquement le role

# Exemple de code Python sur l'instance EC2:
# import boto3
# s3 = boto3.client('s3')  # Pas besoin de credentials!
# s3.list_buckets()        # Fonctionne grâce au role

# Retirer instance profile d'une instance
aws ec2 disassociate-iam-instance-profile \
  --association-id <ASSOCIATION_ID>

# === TRUST POLICIES AVANCÉES ===

# trust-policy-lambda.json - Pour Lambda
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "lambda.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

# trust-policy-multiple-services.json - Plusieurs services
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": [
                    "ec2.amazonaws.com",
                    "lambda.amazonaws.com"
                ]
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

# trust-policy-cross-account.json - Autre compte AWS peut utiliser
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::999999999999:root"  # Autre compte
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

# [IDEE] Cas d'usage: Donner accès à partenaire/client à certaines ressources

# === PASSWORD POLICY (POLITIQUE DE MOTS DE PASSE) ===

# [NOTE] EXPLICATION: Définir règles de sécurité pour mots de passe des utilisateurs IAM
# Important pour sécurité si utilisateurs se connectent via Console Web

# Définir politique stricte de mots de passe
aws iam update-account-password-policy \
  --minimum-password-length 12 \
  --require-symbols \
  --require-numbers \
  --require-uppercase-characters \
  --require-lowercase-characters \
  --allow-users-to-change-password \
  --max-password-age 90 \
  --password-reuse-prevention 5

# [IDEE] Explication de chaque paramètre:
# --minimum-password-length 12
#   -> Minimum 12 caractères (plus sécurisé)
#
# --require-symbols
#   -> Doit contenir caractères spéciaux (!@#$%^&*)
#
# --require-numbers
#   -> Doit contenir au moins un chiffre (0-9)
#
# --require-uppercase-characters
#   -> Doit contenir au moins une majuscule (A-Z)
#
# --require-lowercase-characters
#   -> Doit contenir au moins une minuscule (a-z)
#
# --allow-users-to-change-password
#   -> Utilisateurs peuvent changer leur propre mot de passe
#
# --max-password-age 90
#   -> Mot de passe expire après 90 jours (rotation forcée)
#
# --password-reuse-prevention 5
#   -> Ne peut pas réutiliser les 5 derniers mots de passe

# Obtenir politique actuelle
aws iam get-account-password-policy

# Output:
# {
#     "PasswordPolicy": {
#         "MinimumPasswordLength": 12,
#         "RequireSymbols": true,
#         "RequireNumbers": true,
#         "RequireUppercaseCharacters": true,
#         "RequireLowercaseCharacters": true,
#         "AllowUsersToChangePassword": true,
#         "MaxPasswordAge": 90,
#         "PasswordReusePrevention": 5
#     }
# }

# Supprimer politique (revenir aux défauts)
aws iam delete-account-password-policy

# === MFA (MULTI-FACTOR AUTHENTICATION) ===

# [NOTE] EXPLICATION: MFA = Authentification à deux facteurs
# Même si quelqu'un vole votre mot de passe, il ne peut pas se connecter sans le 2ème facteur

# [OBJECTIF] TYPES DE MFA:
# 1. Virtual MFA (app smartphone) - RECOMMANDÉ pour débuter
#    Apps: Google Authenticator, Authy, Microsoft Authenticator
#
# 2. Hardware MFA (clé physique USB)
#    Exemple: YubiKey
#
# 3. SMS (moins sécurisé, pas recommandé)

# [IDEE] Comment ça marche:
# 1. Vous activez MFA avec une app (Google Authenticator par exemple)
# 2. L'app génère un code qui change toutes les 30 secondes
# 3. À la connexion: mot de passe + code de l'app

# Activer MFA pour un utilisateur (nécessite configuration préalable)
aws iam enable-mfa-device \
  --user-name john \
  --serial-number arn:aws:iam::123456789012:mfa/john \
  --authentication-code-1 123456 \
  --authentication-code-2 789012

# [IDEE] Explication:
# --serial-number: Identifiant du device MFA
# --authentication-code-1: Premier code de l'app
# --authentication-code-2: Code suivant (30 sec après)
# Pourquoi 2 codes? Pour prouver que l'app fonctionne correctement

# [ATTENTION] IMPORTANT: Cette commande CLI est complexe pour débutants
# Il est plus facile d'activer MFA via la Console Web:
# 1. AWS Console -> IAM -> Users -> john
# 2. Security credentials tab
# 3. Assign MFA device
# 4. Scanner QR code avec votre app
# 5. Entrer 2 codes consécutifs

# Lister MFA devices d'un utilisateur
aws iam list-mfa-devices --user-name john

# Output:
# {
#     "MFADevices": [
#         {
#             "UserName": "john",
#             "SerialNumber": "arn:aws:iam::123456789012:mfa/john",
#             "EnableDate": "2024-01-15T10:30:00Z"
#         }
#     ]
# }

# Désactiver MFA
aws iam deactivate-mfa-device \
  --user-name john \
  --serial-number arn:aws:iam::123456789012:mfa/john

# [IDEE] Utiliser si: device perdu, changement de téléphone

# [VERROUILLE] POURQUOI MFA EST CRITIQUE:
# [OK] Même si mot de passe est volé, compte reste protégé
# [OK] Protection contre phishing
# [OK] Requis pour accès root account (obligatoire!)
# [OK] Gratuit et facile à mettre en place

# === ACCOUNT ALIAS (ALIAS DE COMPTE) ===

# [NOTE] EXPLICATION: Par défaut, URL de connexion AWS = numéro de compte
# https://123456789012.signin.aws.amazon.com/console
# C'est difficile à retenir!

# Avec un alias, vous pouvez avoir:
# https://mon-entreprise.signin.aws.amazon.com/console

# Créer alias (nom unique dans tout AWS)
aws iam create-account-alias --account-alias mon-entreprise

# [IDEE] Choisir un nom:
# - Unique dans tout AWS (comme nom de domaine)
# - Minuscules, chiffres, tirets seulement
# - Entre 3 et 63 caractères

# Lister alias actuel
aws iam list-account-aliases

# Output:
# {
#     "AccountAliases": [
#         "mon-entreprise"
#     ]
# }

# Supprimer alias
aws iam delete-account-alias --account-alias mon-entreprise

# [IDEE] Revient à l'URL avec numéro de compte

# === RÉSUMÉ: WORKFLOW TYPIQUE POUR NOUVEAU UTILISATEUR ===

# [OBJECTIF] SCÉNARIO: Ajouter Marie, nouvelle développeuse

# Étape 1: Créer utilisateur
aws iam create-user --user-name marie

# Étape 2: Créer clés d'accès
aws iam create-access-key --user-name marie
# [ATTENTION] Sauvegarder les clés et les donner à Marie

# Étape 3: Ajouter à groupe Developers (qui a déjà des permissions)
aws iam add-user-to-group --user-name marie --group-name Developers

# Étape 4: (Optionnel) Permissions additionnelles spécifiques
aws iam attach-user-policy \
  --user-name marie \
  --policy-arn arn:aws:iam::aws:policy/IAMReadOnlyAccess

# Étape 5: (Optionnel) Créer mot de passe pour Console Web
aws iam create-login-profile \
  --user-name marie \
  --password TempPassword123! \
  --password-reset-required

# [IDEE] --password-reset-required force Marie à changer le mot de passe
# à sa première connexion (bonne pratique)

# Étape 6: Informer Marie
# - Clés d'accès (pour AWS CLI)
# - URL de connexion: https://mon-entreprise.signin.aws.amazon.com/console
# - Nom d'utilisateur: marie
# - Mot de passe temporaire: TempPassword123!
# - Lui dire d'activer MFA!

# === RÉSUMÉ: WORKFLOW POUR INSTANCE EC2 + S3 ===

# [OBJECTIF] SCÉNARIO: Instance EC2 doit lire et écrire dans S3

# Étape 1: Créer trust policy
cat > trust-policy.json << EOF
{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Principal": {"Service": "ec2.amazonaws.com"},
        "Action": "sts:AssumeRole"
    }]
}
EOF

# Étape 2: Créer role
aws iam create-role \
  --role-name EC2-S3-FullAccess-Role \
  --assume-role-policy-document file://trust-policy.json

# Étape 3: Attacher permissions S3
aws iam attach-role-policy \
  --role-name EC2-S3-FullAccess-Role \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3FullAccess

# Étape 4: Créer instance profile
aws iam create-instance-profile \
  --instance-profile-name EC2-S3-FullAccess-Profile

# Étape 5: Ajouter role à instance profile
aws iam add-role-to-instance-profile \
  --instance-profile-name EC2-S3-FullAccess-Profile \
  --role-name EC2-S3-FullAccess-Role

# Étape 6: Lancer EC2 avec le profile (ou attacher à existante)
# Voir section EC2 pour commande complète

# Étape 7: Dans votre code sur EC2, utiliser boto3 (Python)
# import boto3
# s3 = boto3.client('s3')  # Credentials automatiques!
# s3.list_buckets()

# === BONNES PRATIQUES IAM (RÈGLES D'OR) ===

# [VERROUILLE] SÉCURITÉ:

# 1⃣ [X] NE JAMAIS utiliser Root Account pour opérations quotidiennes
#    [OK] Créer utilisateur IAM admin et utiliser celui-là
#
# 2⃣ [OK] TOUJOURS activer MFA sur Root Account (OBLIGATOIRE!)
#    [OK] Activer MFA sur tous les utilisateurs avec accès important
#
# 3⃣ [OK] TOUJOURS appliquer principe du moindre privilège
#    Donner UNIQUEMENT les permissions nécessaires, pas plus
#    Exemple: Si besoin lecture S3 -> AmazonS3ReadOnlyAccess
#             PAS AmazonS3FullAccess
#
# 4⃣ [OK] Utiliser Groups pour gérer permissions (pas directement sur users)
#    Plus facile à maintenir quand équipe grandit
#
# 5⃣ [OK] Utiliser Roles pour EC2/Lambda (PAS de clés hardcodées)
#    Plus sécurisé, rotation automatique
#
# 6⃣ [OK] Rotation régulière des clés d'accès (tous les 90 jours)
#    Supprimer clés inutilisées
#
# 7⃣ [OK] Activer CloudTrail pour audit (voir qui fait quoi)
#
# 8⃣ [X] NE JAMAIS partager clés d'accès entre utilisateurs
#    Une personne = un utilisateur IAM
#
# 9⃣ [X] NE JAMAIS commiter credentials dans Git
#    Utiliser .gitignore pour ~/.aws/credentials
#
# [10] [OK] Utiliser AWS Organizations pour multi-comptes
#    Séparer: dev, staging, prod

# [GRAPHIQUE] ORGANISATION:

# [OK] Convention de nommage claire:
#    Users: prenom.nom (marie.dupont)
#    Groups: Par fonction (Developers, Admins, ReadOnly)
#    Roles: Par service-usage (EC2-S3-Access, Lambda-DynamoDB-Write)
#
# [OK] Tags sur toutes les ressources:
#    Environment: production/staging/dev
#    Team: backend/frontend/data
#    Owner: email@example.com
#
# [OK] Documentation des policies custom:
#    Description claire de ce que fait la policy
#    Pourquoi elle existe
#    Qui l'utilise

# [OBJECTIF] STRUCTURE D'ÉQUIPE TYPIQUE:

# Groupe "Admins"
# - Permissions: AdministratorAccess (tout)
# - Membres: CTO, Lead DevOps
# - MFA: OBLIGATOIRE

# Groupe "Developers"
# - Permissions: EC2, S3, RDS, Lambda (lecture + écriture)
# - Permissions: Billing (lecture seule)
# - Membres: Tous les développeurs
# - MFA: Recommandé

# Groupe "ReadOnly"
# - Permissions: Tout en lecture seule
# - Membres: Stagiaires, nouveaux arrivants
# - MFA: Recommandé

# Groupe "Billing"
# - Permissions: Voir coûts et factures
# - Membres: Finance, managers
# - MFA: Recommandé

# === VÉRIFIER PERMISSIONS (TROUBLESHOOTING) ===

# [NOTE] EXPLICATION: Comment savoir si un utilisateur a une permission spécifique?

# Méthode 1: Lister toutes les policies de l'utilisateur
aws iam list-attached-user-policies --user-name marie
aws iam list-user-policies --user-name marie  # Inline policies

# Méthode 2: Lister groupes de l'utilisateur
aws iam list-groups-for-user --user-name marie

# Méthode 3: Voir policies des groupes
aws iam list-attached-group-policies --group-name Developers

# Méthode 4: IAM Policy Simulator (via Console Web)
# https://policysim.aws.amazon.com/
# Permet de tester: "Est-ce que marie peut faire s3:PutObject?"

# [RECHERCHE] COMPRENDRE LES ERREURS "ACCESS DENIED":

# Erreur: "User: arn:aws:iam::123456789012:user/marie is not authorized
#          to perform: s3:PutObject on resource: arn:aws:s3:::my-bucket/file.txt"

# [IDEE] Explication:
# - marie essaie de faire: s3:PutObject (upload fichier)
# - Sur: my-bucket/file.txt
# - Résultat: Refusé (pas la permission)

# Solutions possibles:
# 1. Attacher AmazonS3FullAccess à marie ou son groupe
# 2. Créer policy custom pour ce bucket spécifique
# 3. Vérifier si Deny bloque (Deny > Allow)
# 4. Vérifier bucket policy (permissions côté bucket)

# === COMMANDES UTILES POUR DÉBOGAGE ===

# Qui suis-je? (Quel utilisateur/role j'utilise)
aws sts get-caller-identity

# Output:
# {
#     "UserId": "AIDAJEXAMPLE",
#     "Account": "123456789012",
#     "Arn": "arn:aws:iam::123456789012:user/marie"
# }

# [IDEE] Si vous voyez "root" dans l'Arn, vous utilisez le compte root!
# C'EST DANGEREUX! Créez un utilisateur IAM.

# Lister TOUTES les permissions d'un utilisateur (complexe mais complet)
# Nécessite d'aller chercher:
# 1. Policies attachées directement
# 2. Policies inline
# 3. Policies des groupes
# 4. Policies des groupes inline

# Script pour voir toutes les permissions de marie:
echo "=== Policies attachées directement ==="
aws iam list-attached-user-policies --user-name marie

echo "=== Inline policies ==="
aws iam list-user-policies --user-name marie

echo "=== Groupes ==="
aws iam list-groups-for-user --user-name marie

echo "=== Policies des groupes ==="
for group in $(aws iam list-groups-for-user --user-name marie --query 'Groups[*].GroupName' --output text); do
  echo "Groupe: $group"
  aws iam list-attached-group-policies --group-name $group
done"Elastic Beanstalk = PaaS pour déployer applications sans gérer infrastructure
Supporte: Node.js, Python, Ruby, Java, PHP, .NET, Go, Docker