Menu
Mais Encore

Security musings

GKE — Google Kubernetes Engine en profondeur : Autopilot, Binary Authorization et Security Posture

Catégories

Tags

🔍 Licence d'Utilisation 🔍

Sauf mention contraire, le contenu de ce blog est sous licence CC BY-NC-ND 4.0.

© 2025 à 2042 Sébastien Gioria. Tous droits réservés.

⏱️
Temps de lecture estimé
~18 minutes

Cet article fait partie de la série Kubernetes Managé & Edge. Si tu cherches le guide de choix et le tableau comparatif global, commence par là.

Google a inventé Kubernetes. GKE en est la déclinaison cloud la plus directement liée à cet héritage , c’est la première à supporter les nouvelles features Kubernetes, souvent avant leur merge dans upstream. Ce n’est pas du chauvinisme : c’est une réalité technique que observée à chaque cycle de release.

Ce qui frappe le plus dans GKE en 2025-2026 : c’est la solution avec la posture de sécurité par défaut la plus stricte des trois grands. Autopilot en particulier impose des contraintes qui forcent les équipes à écrire des workloads vraiment sécurisés dès le départ.

GKE Autopilot en une phrase : tu déploies des pods, Google s’occupe du reste et des pods non conformes aux standards de sécurité sont simplement rejetés.

Architecture GKE — Plan de contrôle et modes de déploiement

Plan de contrôle managé (Google)

Comme AKS, Google gère entièrement le plan de contrôle GKE :

  • kube-apiserver multi-zones avec auto-scaling
  • etcd répliqué cross-zone
  • Certificats avec rotation automatique
  • Mises à jour du plan de contrôle en rolling update sans downtime
  • Plan de contrôle gratuit (sauf cluster zonal standard single-zone)

La différence avec AKS : Google offre aussi des release channels (Rapid, Regular, Stable) pour contrôler la cadence des mises à jour du plan de contrôle.

GKE Autopilot vs GKE Standard

C’est le choix le plus structurant sur GKE :

Aspect GKE Standard GKE Autopilot
Gestion nodes Manuelle (node pools) Automatique (Google)
Pods privilégiés Autorisés Bloqués
hostNetwork / hostPID Autorisés Bloqués
securityContext Optionnel Enforced
Tarification Nodes payants Par pod (CPU/mémoire requis)
Accès SSH aux nodes Oui Non
Workload Identity Optionnel Obligatoire
OS nodes Configurable COS (Container-Optimized OS)

En Autopilot, Google applique automatiquement le Restricted Pod Security Standard. Concrètement, un pod qui essaie de démarrer avec securityContext.privileged: true sera refusé par l’admission controller. C’est inconfortable au départ pour les équipes habituées à des clusters permissifs mais c’est la bonne direction.

Node pools et Container-Optimized OS

En GKE Standard, il est recommandé d’utiliser systématiquement Container-Optimized OS (COS) plutôt qu’Ubuntu :

  • Système de fichiers root en lecture seule
  • Surface minimale (pas de gestionnaire de packages, shell limité)
  • Mises à jour atomiques avec rollback
  • Intégration native avec les mécanismes de sécurité GKE
  • Compatible Linux Security Module (AppArmor activé par défaut)

Workload Identity Federation — La gestion d’identité la plus propre

Workload Identity GKE est, à mon avis, l’implémentation la plus élégante des trois clouds. Le principe est le même qu’Azure Workload Identity mais le setup est plus simple.

Fonctionnement

  1. Un pod Kubernetes présente son ServiceAccount token à Google Cloud
  2. Google Cloud valide le token via l’OIDC Issuer URL du cluster GKE
  3. Google Cloud retourne un token avec les permissions du Google Service Account associé

C’est tout. Le pod qui utilise ce ServiceAccount accède automatiquement aux ressources GCP via le metadata server local, sans aucune clé de service account dans les secrets.

Réseau GKE — Dataplane V2 et eBPF

GKE Dataplane V2 — Cilium comme data plane par défaut

C’est la vraie différence réseau de GKE par rapport à AKS et EKS : GKE utilise Cilium/eBPF comme data plane réseau par défaut depuis la version 1.20. Tous les autres clouds le proposent comme option optionnelle.

Cilium sur GKE apporte :

  • NetworkPolicies L3/L4 nativement (sans kube-proxy)
  • Network Policies L7 (HTTP, DNS, gRPC) via CiliumNetworkPolicy
  • Visibilité réseau via Hubble (flows entre pods en temps réel)
  • Performances supérieures grâce à eBPF (bypass du noyau pour le forwarding)

NetworkPolicies L7 avec Cilium

En standard Kubernetes, les NetworkPolicies s’arrêtent à L4 (IP + port). Avec Cilium sur GKE, on peut aller plus loin :

# Autoriser uniquement les requêtes GET sur /api/ depuis le frontend
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: restrict-backend-access
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: backend
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: "GET"
          path: "/api/.*"

Binary Authorization — Sécuriser la supply chain

Binary Authorization est l’une des fonctionnalités les plus différenciantes de GKE. C’est un admission controller qui valide cryptographiquement les images Docker avant leur déploiement dans le cluster (et ca c’est cool pour éviter les attaques par la supply chain, vu que la plupart du temps, de nombreuses équipes ne font pas de scanning d’images ou de contrôle d’accès strict sur les registries).

Principe de fonctionnement

  1. Ton pipeline CI/CD génère une attestation signée cryptographiquement pour chaque image
  2. Binary Authorization valide cette attestation au moment du déploiement
  3. Une image sans attestation valide est refusée par l’API Server
# Créer un Attestor (entité qui peut signer les attestations)
gcloud container binauthz attestors create build-attestor \
  --attestation-authority-note=projects/mon-projet/notes/build-verified \
  --project=mon-projet

# Configurer la politique Binary Authorization
cat > policy.yaml << 'EOF'
globalPolicyEvaluationMode: ENABLE
defaultAdmissionRule:
  evaluationMode: REQUIRE_ATTESTATION
  requireAttestationsBy:
  - projects/mon-projet/attestors/build-attestor
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
clusterAdmissionRules:
  europe-west1.mon-cluster:
    evaluationMode: REQUIRE_ATTESTATION
    requireAttestationsBy:
    - projects/mon-projet/attestors/build-attestor
    enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
EOF

gcloud container binauthz policy import policy.yaml --project=mon-projet

Intégration dans le pipeline CI/CD

# Dans ton pipeline CI/CD : après le build et les tests
# Signer l'image avec l'attestor
DIGEST=$(gcloud container images describe \
  europe-docker.pkg.dev/mon-projet/mon-repo/mon-app:v1.0 \
  --format='get(image_summary.digest)')

gcloud container binauthz attestations sign-and-create \
  --artifact-url="europe-docker.pkg.dev/mon-projet/mon-repo/mon-app@${DIGEST}" \
  --attestor=build-attestor \
  --attestor-project=mon-projet \
  --keyversion=projects/mon-projet/locations/global/keyRings/build-keys/cryptoKeys/attestor-key/cryptoKeyVersions/1

Une fois cette attestation créée, seules les images attestées par ton pipeline peuvent être déployées dans le cluster. Un attaquant qui injecte une image malveillante dans le registry sera bloqué.

GKE Security Posture Dashboard

Disponible depuis GKE 1.27, ce tableau de bord analyse en continu la configuration de sécurité du cluster et des workloads.

Le dashboard couvre :

  • Workload configuration : détecte les pods avec privileged: true, hostNetwork, capabilities dangereuses
  • Vulnerability scanning : CVEs dans les images en cours d’exécution
  • RBAC insights : identifie les permissions trop larges (ServiceAccounts avec cluster-admin, etc.)
  • Network Policy coverage : identifie les pods sans NetworkPolicy

Confidential Computing — Chiffrer la RAM

GKE supporte les Confidential Nodes basés sur AMD SEV (Secure Encrypted Virtualization) ou Intel TDX. Cette technologie chiffre la mémoire RAM des nodes au niveau matériel.

Cas d’usage : workloads avec des données ultra-sensibles (santé, finance, données personnelles) où même l’administrateur cloud ne doit pas pouvoir lire les données en RAM.

Note : les Confidential Nodes nécessitent des machines AMD (n2d-*) et ont un surcoût CPU (~10-20%). il faut donc réserver cette option aux workloads qui traitent des données vraiment critiques.

GKE Enterprise et Fleet

GKE Enterprise permet de gérer des flottes de clusters GKE (et même des clusters non-GKE via Connect) avec une gestion centralisée de la configuration, des politiques de sécurité, et des accès.

Config Sync est l’outil Fleet a utiliser pour la gestion de configuration multi-cluster :

Config Sync applique automatiquement les configurations depuis Git, avec détection de drift et réconciliation automatique.

Exemple concret — Attaque par image malveillante sans Binary Authorization

Décrivons un scénario d’attaque classique dans un cluster GKE Standard sans Binary Authorization, pour illustrer l’importance de cette fonctionnalité.

Contexte : Un cluster GKE Standard sans Binary Authorization. Les images sont tirées depuis Artifact Registry. Le pipeline CI/CD utilise un Service Account GCP avec des droits roles/artifactregistry.writer.

Scénario d’attaque :

  1. Un développeur clique sur un lien de phishing. Son poste est compromis.
  2. L’attaquant exfiltre les credentials GCP du poste (souvent dans ~/.config/gcloud/).
  3. Avec ces credentials, l’attaquant liste les images dans Artifact Registry : gcloud artifacts docker images list.
  4. Il crée une image malveillante basée sur une image légitime (ajout d’un reverse shell au entrypoint) avec le même nom et tag :latest.
  5. Il pousse cette image sur Artifact Registry : docker push europe-docker.pkg.dev/projet/repo/app:latest.
  6. Au prochain déploiement (ou redémarrage de pod), l’image malveillante est tirée et exécutée dans le cluster.
  7. Le reverse shell contacte un serveur C2 externe via HTTPS (port 443, souvent autorisé en sortie).

Ce qui aurait évité cette attaque :

  • Binary Authorization : l’image non attestée par le pipeline CI/CD officiel est bloquée
  • Artifact Registry avec immutable tags : impossible d’écraser une image existante sur un tag
  • Workload Identity plutôt que des credentials GCP sur le poste développeur
  • NetworkPolicies Cilium : un pod ne peut pas contacter un serveur C2 externe sur des ports arbitraires
  • Security Posture Dashboard : alertes sur des images non conformes en cours d’exécution

Quelques références pour aller plus loin

✓ À retenir 📌

✓ GKE Autopilot = sécurité restrictive par défaut : pods privilégiés bloqués, hostNetwork interdit, Workload Identity obligatoire, COS imposé. Si tes workloads le supportent, c'est le mode le plus sécurisé sans configuration supplémentaire.

✓ Cilium/eBPF est le data plane par défaut de GKE — une longueur d'avance sur les autres clouds. Utilise les CiliumNetworkPolicy L7 pour une segmentation réseau vraiment fine (par méthode HTTP, par path, etc.).

✓ Binary Authorization est un game-changer pour la supply chain : une image non attestée par ton pipeline CI/CD est simplement refusée. C'est la défense la plus efficace contre l'injection d'images malveillantes.

✓ Le Security Posture Dashboard est ton allié quotidien : il détecte en continu les dérives de configuration (pods privilégiés, permissions RBAC trop larges, images vulnérables) sans nécessiter d'outils tiers.

✓ Container-Optimized OS est l'OS le plus hardened des trois clouds : root en lecture seule, surface minimale, boot vérifié. Ne bascule sur Ubuntu que si tu as une raison absolument impérative.

GKE

LinkedIn Reddit