Checklist de durcissement Kubernetes : clusters autogérés et EKS, AKS, GKE

Qui contrôle l'API Kubernetes contrôle toutes les applications du cluster, et bien souvent le compte cloud qui est derrière. Les services managés (EKS, AKS, GKE) prennent en charge le plan de contrôle, mais l'identité, les politiques de charge de travail, les règles réseau, les images et la détection restent de votre ressort : la ligne de responsabilité partagée est plus haute que ne le pensent la plupart des équipes. Cette checklist suit le chemin de l'attaquant : l'API, le pod, le réseau, l'image, les secrets, la détection.

Le modèle de menace en un tableau

1. Identité et RBAC

• Les humains s'authentifient via le fournisseur d'identité de l'entreprise : access entries EKS reliées aux rôles IAM Identity Center, AKS avec intégration Entra ID et comptes locaux désactivés, GKE avec Google Groups pour le RBAC. Pas de certificats clients pour les personnes : ils ne sont pas révocables.
• Les charges de travail ont leur propre identité cloud : EKS Pod Identity ou IRSA, AKS Workload Identity, GKE Workload Identity Federation. Jamais le rôle du nœud.
• Un RBAC sans jokers et sans cluster-admin hors comptes de secours. Certains verbes sont des escalades déguisées : escalate, bind, impersonate, create sur les pods (montage de n'importe quel compte de service), get/list sur les secrets, pods/exec, nodes/proxy.
• automountServiceAccountToken: false sur les pods qui n'appellent jamais l'API.

Audit rapide :

# Qui est cluster-admin ?
kubectl get clusterrolebindings -o json \
  | jq -r '.items[] | select(.roleRef.name=="cluster-admin") | .subjects[]?'
# Que peut faire le compte de service web ?
kubectl auth can-i --list --as=system:serviceaccount:shop:web

2. Pod Security Admission

Pod Security Admission (intégré, stable depuis la 1.25) applique trois profils standard par namespace : privileged, baseline, restricted. Visez restricted sur tous les namespaces applicatifs, privileged uniquement pour quelques namespaces système (CNI, stockage, agents de supervision).

kubectl label ns shop \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/warn=restricted \
  pod-security.kubernetes.io/audit=restricted

restricted impose un utilisateur non root, allowPrivilegeEscalation: false, la suppression de toutes les capacités, un profil seccomp RuntimeDefault, et interdit les namespaces de l'hôte et les volumes hostPath. Ajoutez un système de fichiers racine en lecture seule dans la spécification du pod.

3. Politiques réseau

Les namespaces délimitent les noms et le RBAC, pas le réseau : sans politique, chaque pod joint tous les autres. Commencez chaque namespace par un refus par défaut en entrée et en sortie, puis autorisez le DNS et les flux nécessaires. Il faut un CNI qui applique les politiques (Calico, Cilium ou les équivalents managés).

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: shop
spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - {protocol: UDP, port: 53}
        - {protocol: TCP, port: 53}

Bloquez l'adresse de métadonnées cloud (169.254.169.254) depuis les pods et, sur les nœuds EKS, imposez IMDSv2 avec une limite de saut à 1.

4. Chaîne d'approvisionnement des images et contrôle d'admission

Ne faites confiance qu'aux images construites par votre pipeline, analysées et signées :

• images de base minimales (distroless ou slim), épinglées par digest, USER non root ;
• analyse en CI puis à nouveau dans le registre, car de nouvelles CVE apparaissent chaque jour (Trivy, Grype ou le scanner du registre cloud) ;
• signature avec Sigstore cosign en mode keyless et attestation SBOM jointe (voir la sécurité de la CI/CD) ;
• vérification à l'admission : images non signées, registres inconnus et tags latest sont refusés.

Une politique Kyverno qui n'accepte que les images signées par votre workflow de release :

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-signed-images
spec:
  validationFailureAction: Enforce
  rules:
    - name: cosign-keyless
      match:
        any:
          - resources:
              kinds: [Pod]
      verifyImages:
        - imageReferences: ["registry.example.com/*"]
          attestors:
            - entries:
                - keyless:
                    issuer: "https://token.actions.githubusercontent.com"
                    subject: "https://github.com/acme/app/.github/workflows/release.yml@refs/heads/main"

Épinglez exactement l'identité du signataire : une vérification keyless sans sujet ni émetteur accepte n'importe quel compte GitHub. Sur GKE, Binary Authorization remplit le même rôle.

5. Secrets

Les Secrets Kubernetes sont encodés en base64, pas chiffrés. Chiffrez-les au repos avec un fournisseur KMS (activé par défaut ou à un paramètre près sur les services managés), restreignez get/list sur les secrets, et gardez la source de vérité dans un coffre : AWS Secrets Manager, Azure Key Vault, Google Secret Manager ou HashiCorp Vault, synchronisés par External Secrets Operator ou le pilote CSI Secrets Store. Rien dans git, rien en variable d'environnement si un fichier monté convient. Plus de détails dans notre guide de gestion des secrets.

6. Détection à l'exécution et journaux d'audit

• Journaux d'audit : activez l'audit du plan de contrôle (logs du plan de contrôle EKS, paramètres de diagnostic AKS, Cloud Audit Logs GKE) et envoyez-les au SIEM. Alertez sur pods/exec, les lectures de secrets par des comptes de service applicatifs, les modifications RBAC et les nouveaux webhooks.
• Sonde d'exécution : Falco (eBPF) avec ses règles par défaut, par exemple Terminal shell in container et Contact K8S API Server From Container ; alternatives : Tetragon, GuardDuty Runtime Monitoring sur EKS, Defender for Containers sur AKS.
• Réponse : isolez un pod compromis par un label associé à une politique de refus total, mettez le nœud en cordon, préservez les preuves, faites tourner les identifiants du compte de service et du cloud, puis reconstruisez depuis une image signée. Ne jamais supprimer d'abord.

La checklist

P0 = ce mois-ci, P1 = ce trimestre, P2 = sous six mois. Pour la conception de la plateforme dans son ensemble, voir les patterns Kubernetes et l'architecture zero trust.

Notre accompagnement

Le durcissement de Kubernetes et des clusters managés EKS, AKS et GKE est au cœur de l'offre sécurité cloud et DevSecOps de Tadata, du RBAC aux politiques d'admission, en passant par la chaîne d'approvisionnement et les secrets. Voir notre page cybersécurité ; la bibliothèque de fiches contient des fiches sécurité Kubernetes et contrôle d'admission reprenant les commandes ci-dessus.