TP6 - AWS Organizations & Kubernetes

Projet Cloud Native DevOps - ESIEE Paris 2025

👤 Auteurs : Ilyas GHANDAOUI, Cyprien BOSCHER & Lorenzo BAVARD - E4FI

👨‍🏫 Enseignant : Badr TAJINI


Partie 1 - AWS Organizations

AWS Organizations Setup

Organization Structure

Account Configuration

Account Verification

Réflexions et Apprentissages

La mise en place de l’organisation AWS m’a permis de comprendre l’importance d’isoler les environnements pour la sécurité, mais je me suis rapidement heurté à la gestion stricte des identifiants par Amazon.

Défis rencontrés :

  • Unicité des adresses email : Contournement via des alias email
  • Destruction des comptes enfants : AWS interdit la suppression programmatique sans moyen de paiement
  • Gestion de l’existant : Adaptation du code pour éviter la recréation de ressources existantes

Partie 2 - IAM Roles & AssumeRole

IAM User Creation

Administrator Access

Access Keys

Problématique du Compte Root

Nous avons dû créer un nouvel utilisateur IAM avec des droits d’administrateur, car le compte root n’a pas l’autorisation de se “travestir” (AssumeRole).

Après avoir généré et configuré une nouvelle clé d’accès pour cet utilisateur, le déploiement a réussi :

Deployment Success

Role Configuration

Cross-Account Access

Assume Role Test

Credentials Setup

Environment Variables

PowerShell Configuration

Role Assumption

Access Verification

Account Switch

Final Verification

Cross-Account Resources

Resource Access

Deployment Complete

Infrastructure State

Final Configuration

Validation

Leçons Apprises

Cette étape a été marquée par un blocage technique majeur lié aux droits IAM :

Points clés :

  • Le compte root a l’interdiction formelle d’assumer des rôles vers les sous-comptes
  • Nécessité de créer un utilisateur IAM Admin dédié
  • Adaptation de la syntaxe des variables d’environnement pour PowerShell
  • Compréhension approfondie du mécanisme AssumeRole

Partie 3 - Kubernetes Local & Microservices

Kubernetes Setup

Docker Desktop K8s

Service Deployment

Pod Communication

Service Discovery

Orchestration et Communication

Cette dernière partie sur l’orchestration locale a illustré concrètement la communication entre microservices.

Découvertes importantes :

  1. Kubernetes sur Docker Desktop : N’est pas activé par défaut
  2. Isolation réseau : Le Backend est inaccessible depuis l’extérieur (comportement normal)
  3. Service Discovery : Seul le Frontend peut communiquer avec le Backend via les Services Kubernetes
  4. Architecture microservices : Compréhension du modèle de communication interne

Architecture réseau :

Internet → Frontend Service (LoadBalancer/NodePort)
              ↓
          Frontend Pod
              ↓ (ClusterIP)
          Backend Service
              ↓
          Backend Pod

Conclusion

Compétences Acquises

DomaineCompétences
AWS OrganizationsMulti-account strategy, Account isolation, Email alias management
IAMRole assumption, Cross-account access, Root vs IAM user limitations
KubernetesLocal orchestration, Service discovery, Pod communication
MicroservicesNetwork isolation, Service mesh basics, Container networking

Défis Surmontés

  1. ✅ Gestion des contraintes AWS (email, destruction de comptes)
  2. ✅ Compréhension des limitations du compte root
  3. ✅ Configuration IAM pour AssumeRole
  4. ✅ Activation et configuration de Kubernetes sur Docker Desktop
  5. ✅ Compréhension de l’isolation réseau des microservices

0 items under this folder.