Sécurité Kubernetes sur AWS, Azure et GCP : guide complet 2026

Kubernetes est devenu le standard de facto pour orchestrer les conteneurs en production. Mais sa flexibilité et sa complexité en font aussi une surface d'attaque considérable. Des clusters Kubernetes mal configurés sont régulièrement compromis : escalade de privilèges via le service account, accès à l'API server non protégé, images compromises injectées dans le pipeline CI/CD. Ce guide vous donne les clés pour sécuriser votre cluster Kubernetes, qu'il soit sur EKS (AWS), AKS (Azure) ou GKE (Google Cloud).

Les 5 vecteurs d'attaque Kubernetes les plus fréquents

• API server exposé publiquement : Le kube-apiserver accessible sans authentification forte est la première porte d'entrée des attaquants (bots scannent en permanence le port 6443/443). Des milliers de clusters sont accessibles publiquement sur Internet sans MFA.
• RBAC trop permissif : Service accounts avec des permissions cluster-admin, role bindings "wildcard" (*), workloads en production avec des droits de modification des secrets ou des ConfigMaps sensibles.
• Images conteneurs non vérifiées : Images issues de registres publics non scanées (DockerHub), utilisation de tags :latest (pas de versionnement), images avec des CVE critiques non patchées.
• Pods en mode privilégié : Pods avec securityContext.privileged: true, capabilities Linux non restreintes (CAP_NET_ADMIN, CAP_SYS_ADMIN), accès au système de fichiers de l'hôte (hostPath).
• Secrets mal gérés : Secrets Kubernetes stockés en base64 non chiffrés dans etcd, secrets hardcodés dans les manifestes YAML ou les variables d'environnement, pas de rotation.

Sécurité de l'API Server et authentification

Authentification forte

L'API server Kubernetes supporte plusieurs mécanismes d'authentification. Sur les clusters managés (EKS, AKS, GKE), l'authentification est intégrée au IAM cloud provider :

• EKS (AWS) : aws-auth ConfigMap ou EKS Access Entries pour mapper les rôles IAM aux groupes RBAC Kubernetes. Activer l'authentification EKS avec aws eks update-cluster-config --enable-access-entries.
• AKS (Azure) : Intégration Azure Active Directory (Entra ID) pour l'authentification. Activer --enable-azure-rbac pour utiliser les rôles Azure directement dans Kubernetes.
• GKE (Google Cloud) : Workload Identity Federation pour les service accounts applicatifs, Google Groups RBAC pour les équipes humaines. Désactiver les legacy credentials.

Accès à l'API server

• Limiter les IP autorisées à accéder à l'API server via les authorized networks (toutes les offres cloud le proposent)
• Désactiver l'accès public à l'API server pour les clusters de production — utiliser un VPN ou un bastion pour l'administration
• Activer le audit logging de l'API server : logs toutes les requêtes (who, what, when) pour la détection d'anomalies
• Désactiver l'anonymous access : --anonymous-auth=false (désactivé par défaut sur les clusters managés modernes)

RBAC : le principe du moindre privilège

Le RBAC (Role-Based Access Control) est le mécanisme de contrôle d'accès principal de Kubernetes. Une mauvaise configuration RBAC est la première cause d'escalade de privilèges.

Règles fondamentales RBAC

• Pas de cluster-admin pour les applications : Les workloads applicatifs ne doivent jamais avoir le rôle cluster-admin. Créer des Roles (namespace) ou ClusterRoles avec les permissions minimales nécessaires.
• Service accounts dédiés : Chaque application doit avoir son propre ServiceAccount avec uniquement les permissions dont elle a besoin. Ne pas utiliser le ServiceAccount default.
• Audit régulier des RBAC : Utiliser des outils comme rbac-audit, KubiScan ou kubectl-who-can pour identifier les permissions excessives.
• Pas de wildcards dans les verbs : Eviter verbs: ["*"]. Lister explicitement get, list, watch selon le besoin.
• Désactiver l'auto-mount des ServiceAccount tokens : automountServiceAccountToken: false dans les pods qui n'utilisent pas l'API Kubernetes.

Workload Identity : l'IAM pour les applications Kubernetes

Pour accéder aux services cloud (S3, RDS, GCS, Azure Blob) depuis un pod Kubernetes, évitez les credentials statiques (access keys) dans les Secrets. Utilisez les mécanismes d'identité Workload :

• AWS : IRSA (IAM Roles for Service Accounts) — associer un rôle IAM à un ServiceAccount Kubernetes via OIDC
• Azure : Azure Workload Identity — lier un ServiceAccount Kubernetes à une Azure Managed Identity
• GCP : Workload Identity Federation — lier un ServiceAccount Kubernetes à un Service Account Google Cloud

Pod Security : durcir les workloads

Pod Security Admission (PSA)

Depuis Kubernetes 1.25, le Pod Security Admission Controller remplace les PodSecurityPolicies (PSP). Il enforce 3 profils de sécurité au niveau namespace :

• privileged : Aucune restriction (réservé aux namespaces système : kube-system, monitoring)
• baseline : Empêche les configurations les plus dangereuses (pas de privileged, pas de hostNetwork)
• restricted : Profil le plus strict : pas de root, capabilities réduites au minimum, read-only root filesystem recommandé

Labéliser les namespaces de production avec le profil restricted. Exemple : kubectl label namespace production pod-security.kubernetes.io/enforce=restricted

Security Context des pods

Configurer le securityContext à la fois au niveau du pod et du conteneur :

• runAsNonRoot: true — Ne pas exécuter le conteneur en tant que root
• runAsUser: 1000 — Spécifier un UID non-root
• allowPrivilegeEscalation: false — Empêcher le setuid/setgid
• readOnlyRootFilesystem: true — Système de fichiers racine en lecture seule
• capabilities.drop: ["ALL"] — Supprimer toutes les capabilities Linux, n'ajouter que celles nécessaires
• seccompProfile: RuntimeDefault — Activer le profil seccomp par défaut (bloque 300+ syscalls dangereux)

Network Policies : segmentation réseau dans Kubernetes

Par défaut, tous les pods d'un cluster Kubernetes peuvent communiquer entre eux (flat network). Les Network Policies permettent de segmenter le trafic.

• Politique par défaut deny-all : Commencer par une politique qui bloque tout le trafic entrant et sortant au sein d'un namespace, puis ajouter des exceptions explicites.
• Egress contrôlé : Limiter les sorties réseau des pods aux services dont ils ont besoin (base de données, API externes). Bloquer l'accès Internet direct depuis les pods de production.
• DNS autorisé : Toujours autoriser le trafic UDP/TCP port 53 vers le DNS du cluster (CoreDNS)
• CNI compatible : Les Network Policies nécessitent un CNI qui les supporte (Calico, Cilium, Weave Net). Flannel seul ne les supporte pas.

Les solutions CNI avancées comme Cilium permettent des Network Policies L7 (basées sur les DNS, les URL, les headers HTTP) et offrent des capacités d'observabilité réseau (Hubble).

Secrets Management : ne pas stocker les secrets dans Kubernetes

Les Secrets Kubernetes sont encodés en base64 mais stockés en clair dans etcd par défaut. Pour les environnements de production, utiliser des solutions de secrets management externes :

• AWS Secrets Manager + AWS Secrets Store CSI Driver : Injecter les secrets AWS dans les pods via le CSI driver sans les stocker dans les Secrets Kubernetes
• Azure Key Vault + CSI Driver : Même approche pour Azure, avec intégration Azure Workload Identity
• GCP Secret Manager + Workload Identity : Accès aux secrets GCP depuis les pods via le Workload Identity sans credentials statiques
• HashiCorp Vault : Solution multi-cloud avec Vault Agent Injector ou le Vault Secrets Operator pour injecter les secrets en tant que variables d'environnement ou fichiers
• External Secrets Operator : Opérateur Kubernetes qui synchronise les secrets depuis AWS/Azure/GCP/Vault vers les Secrets Kubernetes, avec rotation automatique

Si vous devez utiliser les Secrets Kubernetes natifs : activer le chiffrement at-rest d'etcd (EncryptionConfig avec une KMS key AWS/Azure/GCP).

Sécurité de la supply chain : images conteneurs

• Scanning d'images : Intégrer Trivy, Snyk ou AWS ECR scanning dans le pipeline CI/CD. Bloquer le déploiement d'images avec des CVE critiques (CVSS ≥ 9.0) non patchées.
• Image signing : Signer les images avec Cosign (sigstore) et vérifier les signatures avec une Admission Controller (Kyverno ou OPA Gatekeeper) avant le déploiement.
• Registre privé : Ne jamais tirer des images depuis DockerHub public en production. Utiliser ECR, ACR, GCR ou Harbor comme registre privé.
• Images de base minimales : Utiliser des images distroless (Google), scratch, ou Alpine pour réduire la surface d'attaque. Pas d'outils inutiles (curl, wget, shell) dans les images de production.
• Pas de tag :latest : Toujours utiliser des tags immuables (SHA256 digest ou version sémantique). :latest ne garantit pas la reproductibilité.

Admission Controllers : la dernière barrière

Les Admission Controllers interceptent toute requête à l'API server avant la persistance des ressources. Ils permettent de faire respecter des politiques de sécurité via des Webhooks.

• Kyverno : Solution native Kubernetes (politiques en YAML) pour valider, muter et générer des ressources. Exemples : forcer les labels, bloquer les images non signées, imposer les limites de ressources.
• OPA Gatekeeper : Moteur de politiques basé sur le langage Rego. Plus puissant mais plus complexe. Standard dans les grandes entreprises.
• Politiques à implémenter : Bloquer privileged, bloquer hostPath, forcer les limits/requests CPU et mémoire, interdire les images sans digest, forcer le readOnlyRootFilesystem.

Runtime Security : détecter les attaques en temps réel

• Falco : Outil CNCF de runtime security pour Kubernetes. Détecte les comportements anormaux en temps réel : shell spawné dans un conteneur, accès à des fichiers sensibles (/etc/shadow), connexions réseau inattendues, escalade de privilèges.
• Amazon GuardDuty pour EKS : Analyse les audit logs EKS et détecte les activités malveillantes (découverte de credentials, escalade RBAC, miners de crypto).
• Microsoft Defender for Containers : Équivalent Azure avec analyse des images et détection runtime.
• Google Security Command Center : Pour GKE avec détection des configurations risquées et des comportements anormaux.

Conformité NIS2 et Kubernetes

Si votre entreprise est soumise à NIS2 et utilise Kubernetes pour ses services critiques, voici comment les exigences NIS2 se traduisent :

• Article 21.2a — Politiques d'analyse des risques : Inclure l'évaluation des risques Kubernetes dans votre analyse EBIOS RM ou ISO 27005
• Article 21.2b — Gestion des incidents : Pipeline de détection (Falco, GuardDuty/Defender) → alerte SOC → procédure d'isolation des pods compromis
• Article 21.2c — Continuité : Haute disponibilité du control plane (multi-AZ), PodDisruptionBudgets pour les applications critiques, etcd backups automatiques
• Article 21.2h — Chaîne d'approvisionnement : Scanning d'images, signing Cosign, SBOM (Software Bill of Materials) pour les images de production
• Article 21.2i — Chiffrement : Chiffrement etcd at-rest, TLS pour toutes les communications intra-cluster, mTLS avec Istio ou Linkerd (service mesh)

Plan d'action sécurité Kubernetes en 6 étapes

1. Audit de l'existant : kube-bench (CIS Benchmark), kube-score, Kubescape (NSA/CISA Kubernetes Hardening Guide). Identifier les configurations non conformes.
2. RBAC : Auditer tous les RoleBindings et ClusterRoleBindings. Supprimer les permissions excessives. Migrer vers IRSA/Workload Identity pour les applications.
3. Pod Security : Activer Pod Security Admission en mode baseline sur tous les namespaces, restricted sur les namespaces applicatifs.
4. Secrets : Migrer les secrets sensibles vers AWS Secrets Manager/Azure Key Vault/HashiCorp Vault. Activer le chiffrement etcd si nécessaire.
5. Supply chain : Intégrer le scanning d'images dans le CI/CD. Mettre en place le signing Cosign et la vérification via Kyverno.
6. Runtime monitoring : Déployer Falco (ou l'équivalent cloud natif). Configurer les alertes vers le SOC ou un outil comme PagerDuty/OpsGenie.