← Retour

Architecture Kubernetes — Composants internes & Infrastructure Cloud sécurisée

Plutôt qu'un long catalogue de définitions théoriques, abordons Kubernetes (K8s) par la modélisation visuelle :

  1. Comment fonctionne l'orchestrateur de l'intérieur (anatomie des composants du Control Plane et des Worker Nodes).
  2. Comment déployer un cluster Kubernetes en production dans un réseau privé sécurisé, exposé au web avec protection WAF/DDoS, et relié à une base de données isolée et chiffrée.

⚙️ 1. Anatomie interne : Les composants de Kubernetes

Le cluster est structuré en deux plans fondamentaux :

📐 Schéma des composants et flux de contrôle

Composants internes de Kubernetes : Control Plane & Worker Nodes 🧠 Control Plane (Cerveau du Cluster) kube-apiserver • Seul point d'entrée REST • AuthN, AuthZ (RBAC), Admission • Orchestre tous les composants ▶ Clé de voûte de toute communication etcd (Base clé-valeur) • État complet du cluster • Consensus Raft distribué • Chiffré au repos (Secrets) Accessible SEULEMENT via l'API mTLS / gRPC kube-controller-manager • Boucle de réconciliation (Desired State) • Node, Deployment, ReplicaSet, Endpoints kube-scheduler • Évalue CPU / RAM / Affinités • Assigne les Pods aux meilleurs Workers 👤 kubectl / Helm (HTTPS) 💻 Worker Node 1 kubelet (Agent) • Reçoit ordres de l'API • Pilote le Container Runtime • Probes & Health checks kube-proxy / CNI • iptables / IPVS / eBPF • Routage des Services • Équilibrage vers les Pods Container Runtime • containerd / CRI-O • Pull d'images sécurisé • Isole cgroups & namespaces Pod: Order (Rep 1) order-api:v1.4 IP: 10.244.1.14 CPU 500m / 512Mi Secret injecté Port: 8080 Readiness OK ✅ Pod: Catalog (Rep 1) catalog-api:v2.1 IP: 10.244.1.18 CPU 250m / 256Mi Cache Redis local Port: 8081 Readiness OK ✅ Pod: Cart (Rep 1) cart-service:v2.0 IP: 10.244.1.15 CPU 250m / 256Mi Session Cart Port: 8082 Readiness OK ✅ 💻 Worker Node 2 kubelet (Agent) • Reçoit ordres de l'API • Pilote le Container Runtime • Probes & Health checks kube-proxy / CNI • iptables / IPVS / eBPF • Routage des Services • Équilibrage vers les Pods Container Runtime • containerd / CRI-O • Pull d'images sécurisé • Isole cgroups & namespaces Pod: Order (Rep 2) order-api:v1.4 IP: 10.244.2.19 Anti-Affinité Node 2 Tolère panne Node 1 Port: 8080 Haute Dispo ✅ Pod: Catalog (Rep 2) catalog-api:v2.1 IP: 10.244.2.22 Anti-Affinité Node 2 Tolère panne Node 1 Port: 8081 Haute Dispo ✅ Pod: Ingress nginx / cilium IP: 10.244.2.08 Terminaison TLS Routage HTTP / API NetPol restrictive Passerelle ✅ Canal mTLS sécurisé (Certificats Node)

🛡️ 2. Architecture Kubernetes sécurisée en réseau privé (VPC Cloud)

En production bancaire ou e-commerce, les Worker Nodes ne doivent jamais avoir d'adresses IP publiques directes. Ils résident dans des sous-réseaux privés étanches au sein d'un VPC (Virtual Private Cloud).

🔍 Les principes de sécurité appliqués :

  1. Accès Internet entrant strictement filtré : Les utilisateurs accèdent via un domaine HTTPS protégé par un WAF (Cloudflare / AWS CloudFront / AWS WAF), qui transfère le trafic filtré à un Load Balancer public, puis à l'Ingress Controller du cluster.
  2. Cluster 100% privé : Les Worker Nodes ont uniquement des adresses IP privées (10.0.x.x). La sortie vers Internet (pour télécharger une image ou appeler une API externe) passe obligatoirement par une NAT Gateway avec IP Egress fixe.
  3. Control Plane privé / restreint : Le endpoint de l'API Kubernetes (kube-apiserver) n'est accessible que depuis un réseau d'administration (VPN WireGuard / Tailscale ou Bastion SSH).
  4. Gestion de la Base de Données (DB) :
    • Jamais dans un conteneur éphémère : on utilise un service managé cloud (AWS RDS / Cloud SQL PostgreSQL) multi-AZ avec réplica synchrone et basculement automatique (< 60s).
    • Isolation réseau maximale : La base se situe dans un sous-réseau privé dédié (Subnet Données), inaccessible depuis Internet.
    • Sécurité et Chiffrement : Chiffrement KMS au repos (at-rest), TLS 1.3 en transit, et authentification sans mot de passe en dur via rôles IAM temporaires (AWS IRSA / Workload Identity) ou secrets Vault tournants.
    • Séparation des charges (Commandes & Catalogue) : Les écritures transactionnelles (Commandes) ciblent l'instance Primaire, tandis que les lectures massives (Catalogue produits) s'orientent vers le Read-Replica ou le cache distribué.
  5. Cloisonnement Est-Ouest (NetworkPolicies) : Même si un conteneur web est compromis, des NetworkPolicies (CNI Cilium / Calico) interdisent au Pod d'attaquer directement la DB ou d'autres namespaces.

🌐 Schéma global d'infrastructure : Réseau, Sécurité & Base de Données

Architecture Cloud d'un Cluster Kubernetes Sécurisé en Réseau Privé 🌍 Internet Public & Edge Security 👤 Utilisateurs Web HTTPS / 443 🛡️ WAF & Anti-DDoS Cloudflare / AWS WAF (Filtrage OWASP) 🔐 DevOps & Bastion VPN WireGuard / SSO OIDC / mTLS 🏢 VPC Privé (Virtual Private Cloud) — 10.0.0.0/16 🌐 Subnet Public (DMZ Ingress) — 10.0.1.0/24 Public Application Load Balancer (ALB) Certificat ACM TLS 1.3 • Terminaison SSL Publique 🔄 NAT Gateway (Sortie seule) IP Egress Fixe (Pull images & APIs tiers) Trafic épuré 🔒 Subnet Privé : Cluster Kubernetes (Nœuds sans IP publique) — 10.0.10.0/20 Ingress Controller (Nginx / Envoy / Cilium) • Routage d'URL : /orders, /catalog, /cart • Rate Limiting & mTLS inter-services • NetworkPolicy : Accepte uniquement l'ALB TargetGroup Privé Namespace: prod • Pod: Order-Service Conteneur App (Non-Root, ReadOnlyFS) SecurityContext: drop ALL, seccomp Secrets & Rôles IAM (IRSA) Zéro mot de passe • Token OIDC éphémère NetworkPolicy (Cilium eBPF) Egress UNIQUEMENT vers DB primaire 5432 Namespace: prod • Pod: Catalog-Service Conteneur Catalog (Read-Heavy) Recherche produits, catégories & stocks Cache distribué Redis & Lecture DB Connexion Read-Replica (port 5432) NetworkPolicy restrictive Egress autorisé UNIQUEMENT vers DB / Cache Namespace: prod • Pod: Payment & Cart Conteneur Cart & Outbox Relayer Événements de domaine asynchrones Sortie contrôlée via NAT Gateway Appel sécurisé TLS vers passerelle Stripe NetworkPolicy restrictive Accès interdit aux tables de commande Appels banques via NAT 🗄️ Subnet Données Isolé (Isolated Database Subnet) — 10.0.50.0/24 (ZÉRO ROUTE VERS INTERNET) PostgreSQL RDS Primary (AZ-a) • Chiffrement KMS au repos (AES-256) • Connexions TLS 1.3 obligatoires • Security Group : n'accepte QUE les Pods sur port 5432 • Sauvegardes automatisées & Point-in-time Recovery • IAM DB Authentication (Jetons éphémères de 15 min) Tables : orders, catalog_items, outbox_events PostgreSQL RDS Standby / Read-Replica (AZ-b) • Réplication synchrone Multi-AZ continue • Basculement automatique < 60s en cas de panne • Situé dans un datacenter distinct (Availability Zone B) • Sert de Read-Replica pour le Catalogue • Zéro accès depuis Internet Haute Disponibilité (SLA 99.99%) Sync AZ TCP 5432 Écriture TCP 5432 Lecture Replica TCP 5432 (TLS) ✕ Bloqué : aucune route / passerelle

🔐 3. Synthèse des 5 piliers de sécurisation

🧱 1. Segmentation Réseau en couches (VPC)

Découpage strict en 3 sous-réseaux : Public (DMZ) pour le Load Balancer, Privé pour les Workers K8s sans IP publique, et Isolé pour les bases de données (aucune passerelle Internet).

🛡️ 2. Ingress & Protection de périmètre

Bouclier WAF en amont pour stopper les injections SQL, XSS et attaques DDoS. Les requêtes saines transitent via l'ALB puis l'Ingress Controller qui applique le routage et le TLS.

🗄️ 3. Gestion de la Base de Données (DB)

Base de données managée Cloud (RDS PostgreSQL) en Multi-AZ synchrone. Chiffrement KMS au repos, TLS 1.3 en transit, et authentification sans mot de passe via jetons IAM éphémères (IRSA).

🔒 4. Cloisonnement Pods (NetworkPolicies)

Par défaut, tout le trafic est bloqué. Seuls les Pods ayant le label autorisé peuvent communiquer avec le port 5432 de la base de données. Même si un Pod web est compromis, l'attaquant ne peut pas scanner le réseau interne.

Voir aussi :