Kubernetes offensif (RBAC abuse, : Analyse Technique

Cet article constitue une ressource technique complete sur Kubernetes offensif (RBAC abuse,, couvrant les fondamentaux theoriques, les aspects pratiques d'implementation et les considerations avancees pour les environnements de production. Les professionnels y trouveront des guides etape par etape, des exemples concrets et des recommandations issues de retours d'experience terrain. L'analyse integre les dernieres evolutions du domaine et propose des perspectives sur les tendances a suivre pour les mois a venir. Les bonnes pratiques presentees sont directement applicables et ont ete validees dans des contextes operationnels reels. L'optimisation des infrastructures virtualisees passe par une planification rigoureuse des ressources, une supervision continue des performances et l'application des bonnes pratiques de securite specifiques aux environnements hyperviseurs. La planification de capacite dans les environnements virtualises doit prendre en compte les pics de charge, les besoins de haute disponibilite et les exigences de reprise d'activite pour dimensionner correctement les ressources materielle et logicielles.

Cet article fournit une analyse technique detaillee de Kubernetes offensif (RBAC abuse,, couvrant les aspects fondamentaux de l'architecture, les procedures de configuration et les bonnes pratiques de deploiement en environnement de production. Les administrateurs systemes y trouveront des guides etape par etape, des exemples de configuration et des recommandations issues de retours d'experience terrain en entreprise.

Résumé exécutif

Les clusters Kubernetes d'entreprise combinent une multitude de composants : workloads conteneurisés, contrôleurs réseau, filtres d'admission, secrets stockés dans etcd. Cette complexité accroît les surfaces d'attaque. Les adversaires ciblent les faiblesses RBAC, les validations d'admission, les accès au plan de contrôle et les secrets en clair. Cet article propose une vision offensive-déensive : comprendre comment un attaquant contourne les protections pour obtenir des privilèges élevés, puis construire des défenses basées sur des contrôles réseau, des politiques Kyverno/OPA, la sécurisation des secrets et des audits continus. L'objectif est de fournir un guide technique pour sécuriser les clusters multi-tenant, avec des tactiques de chasse et des playbooks d'investigation. Cet article fournit une analyse technique approfondie et des recommandations pratiques pour les professionnels de la cybersecurite. Les concepts presentes sont issus de retours d'experience terrain et des meilleures pratiques du secteur. Les equipes techniques y trouveront des methodologies eprouvees, des outils recommandes et des strategies de mise en oeuvre adaptees aux environnements de production modernes. La maitrise de ces sujets est devenue incontournable dans le contexte actuel de menaces en constante evolution.

Votre architecture de sécurité repose-t-elle sur une seule couche de défense ?

Architecture Kubernetes et surfaces de menace

Un cluster Kubernetes comprend des nœuds maîtres (API server, etcd, scheduler, controller manager) et des nœuds workers exécutant kubelet et les pods. Les surfaces attaquables incluent : l'API server exposée, les kubelets, les services internes (kube-dns, metrics-server), les objets cluster-wide (ClusterRole, ClusterRoleBinding). Les attaques peuvent provenir d'un container compromis, d'une fuite de kubeconfig, d'une exposition de dashboard, ou d'un mauvais filtrage réseau. Comprendre cette architecture est essentiel pour cartographier les chemins d'escalade : un pod avec la capacité hostPath ou privileged peut accéder à l'hôte ; un accès à etcd permet de récupérer tous les secrets ; une ServiceAccount mal configurée ouvre la porte à des token reuse.

RBAC : principe et failles courantes

Le modèle RBAC associe des rôles (Role, ClusterRole) à des liaisons (RoleBinding, ClusterRoleBinding) et à des sujets (ServiceAccount, User, Group). Les erreurs classiques :

• Utilisation de cluster-admin pour des workloads applicatifs.
• Liaison de system:masters à des comptes externes.
• Attributions wildcard (resources: , verbs: ) inutiles.
• ServiceAccounts partagées entre plusieurs workloads.

Un attaquant, après compromission d'un pod, peut lire le token de la ServiceAccount montée dans /var/run/secrets/kubernetes.io/serviceaccount. Si cette ServiceAccount dispose de privilèges, il peut exécuter des opérations sur le cluster (création de pods, lecture de secrets). La défense repose sur le principe du moindre privilège, l'isolation des namespaces et la rotation des tokens.

Abus RBAC : chemins d'escalade

Les attaques RBAC se déclinent en plusieurs scénarios :

• Une Role autorisant create sur pods/exec permet d'exécuter des conteneurs privilégiés.
• Une Role avec update sur deployments permet d'injecter une image malveillante.
• Une ClusterRole autorisant create sur clusterroles et clusterrolebindings permet de devenir cluster-admin.
• L'accès aux ressources secrets fournit les secrets TLS, tokens, credentials de base de données.

Les adversaires combinent souvent des actions. Exemple : créer un pod monté sur l'hôte (hostPath: /etc/kubernetes) pour récupérer kubeconfig, puis se connecter en kubectl. Certains abus passent par la création de CRD (Custom Resource Definition) pour exécuter du code dans des contrôleurs vulnérables.

Combien de vos contrôles de sécurité ont été testés en conditions réelles cette année ?

Admission Controllers : rôle et dérives

Les Admission Controllers (Mutating, Validating, Dynamic) permettent de contrôler les requêtes à l'API server. Mal configurés, ils peuvent être contournés ou paralysés. Des attaques visent à désactiver un contrôleur en provoquant un crash (DoS) ou en exploitant une faille dans un webhook externe. Certaines organisations oublient de sécuriser le canal TLS du webhook, permettant une attaque Man-in-the-Middle. Les attaquants cherchent aussi à invoquer l'API server directement depuis l'intérieur du cluster via une IP interne, contournant les contrôles d'entrée. Les defenders doivent veiller à ce que les contrôleurs d'admission critiques (NamespaceLifecycle, LimitRanger, ServiceAccount, PodSecurity, ValidatingAdmissionWebhook) soient activés et monitorés.

Secrets Kubernetes : stockage et exposition

Les secrets sont stockés en Base64 dans etcd. Sans chiffrement au repos (--encryption-provider-config), leur lecture offre un accès direct aux credentials. Les secrets montés dans des volumes ou injectés via des variables d'environnement peuvent fuiter dans les logs. Les images conteneur peuvent contenir des secrets codés en dur. Les attaques consistent à lire les secrets via kubectl get secret, via l'API, ou en accédant à etcd. Les defenders doivent chiffrer etcd, restreindre les RBAC sur secrets, opter pour External Secrets (Vault, AWS Secrets Manager), et auditer les montages de volumes sensibles.

Contournement des contrôles réseau

Les CNI (Calico, Cilium, Weave) implémentent des politiques réseau. Les clusters sans Network Policies laissent souvent un trafic est-ouest illimité. Un attaquant peut scanner l'ensemble des services internes, découvrir le kubelet sur 10250, l'API sur 6443, ou un dashboard non authentifié. Même avec des policies, des erreurs (namespace default sans restrictions) persistent. L'utilisation de egress non contrôlés permet d'exfiltrer des données. Les organisations doivent définir des politiques par namespace, segmenter les pods, et appliquer des contrôles egress sortants (vers internet, vers d'autres VPC/VNet). Les CNI avancées offrent des features (DNS policy, L7) utiles pour limiter les flux.

Pod Security : PSP, Kyverno, OPA Gatekeeper

Les anciens PodSecurityPolicies (PSP) étaient difficiles à gérer, mais restaient un rempart. Leur retrait nécessite des alternatives : Kyverno, OPA Gatekeeper, ou les Pod Security Standards intégrés dans Kubernetes 1.24+. Ces outils imposent des contraintes (pas de privileged, pas de hostPath, readOnlyRootFilesystem). Les politiques doivent être versionnées IaC et testées. Kyverno permet d'appliquer des mutate (ajout d'annotations), des validate (refus de pods non conformes) et des generate (injection de sidecars). OPA Gatekeeper, via des Rego policies, impose des règles fines. Les attaquants cherchent à contourner ces contrôles en utilisant des namespaces exemptés ou des labels manquants. Les defenders doivent appliquer les politiques sur tous les namespaces, y compris kube-system, et surveiller les exceptions.

Audit continus et Policy as Code

Un cluster sécurisé s'appuie sur des audits réguliers. Des outils comme kubescape, kube-bench, Popeye, Polaris identifient les dérives RBAC, les pods privilégiés, les secrets exposés. Les rapports sont intégrés dans un pipeline CI/CD. Les organisations adoptent policy-as-code : des règles Gatekeeper/Kyverno versionnées dans Git, validées via des tests automatisés (Conftest). Chaque merge request est validée par des contrôles. Cette discipline réduit l'introduction d'exceptions ad hoc. Les audits incluent des revues manuelles : évaluation des ServiceAccount, des RoleBinding, des NetworkPolicy effectives.

Monitoring et observabilité

La détection passe par la collecte de plusieurs signaux :

• Logs d'audit Kubernetes (auditPolicy.yaml).
• Logs kubelet (/var/log/kubelet.log).
• Logs d'admission webhooks.
• Télémétrie des CNI (Calico flow logs, Cilium Hubble).
• Logs etcd.

Les journaux sont envoyés vers un SIEM (Elastic, Splunk) ou une plateforme (Prometheus, Loki). Les métriques telles que le nombre de requêtes create pod par minute, les erreurs d'admission, les 403 Forbidden contribuent à la détection. Des règles identifient des actions suspectes : kubectl exec répété, création de ClusterRoleBinding, accès à des secrets hors du namespace, pods tournant avec hostNetwork: true.

Hunting : scénarios et requêtes

Les équipes chasseurs définissent des scénarios :

• Un pod default qui crée un ClusterRoleBinding.
• Un ServiceAccount utilisé depuis une IP externe (via un kubeconfig exfiltré).
• Un flux réseau interne vers 169.254.169.254 (metadata) depuis un pod.
• Une élévation de privilège via injection d'un DaemonSet privilégié.

Les requêtes dans Elasticsearch :

{
  "query": {
    "bool": {
      "must": [
        { "term": { "verb": "create" } },
        { "term": { "objectRef.resource": "clusterrolebindings" } },
        { "term": { "sourceIPs.keyword": "10.0.42.17" } }
      ]
    }
  }
}

Cette requête détecte la création de ClusterRoleBinding depuis un pod compromis. Les hunts s'appuient aussi sur des outils open source (ThreatMapper, Falco) analysant en temps réel les comportements conteneurs.

Falco et détection runtime

Falco (CNCF) observe les syscalls et détecte des comportements suspects : écriture dans /etc, ouverture de sockets, exécution de shell. Des règles spécifiques identifient les escalades : création d'un pod privilégié, accès à des secrets, modification d'iptables. On customise les règles Falco pour couvrir les scénarios internes. Falco émet des alertes vers Slack, PagerDuty, ou un SIEM. Les organisations combinent Falco avec Aqua Starboard, Sysdig Secure, ou eBPF (Cilium) pour obtenir des détections runtime renforcées.

Gestion des secrets avec External Secrets Operator

Pour éviter les secrets en clair, on adopte des opérateurs (External Secrets, Sealed Secrets). External Secrets synchronise les secrets de Vault, AWS Secrets Manager, Azure Key Vault. Cela permet de contrôler l'accès via le vault, trace les lectures, et facilite la rotation. Les politiques RBAC doivent restreindre qui peut créer ou modifier les ExternalSecret CRD. Un attaquant qui modifie la ressource peut rediriger vers son propre secret store ; la défense inclut des validations d'admission et des revues des manifests.

Cas pratiques : compromission d'un pod et escalade

Scénario : un pod payments est compromis via une injection SQL. L'attaquant trouve le token ServiceAccount et l'utilise pour lister les RoleBinding. Il découvre une Role avec get sur secrets. Il récupère les secrets de la base de données, puis create un nouveau pod dans le namespace kube-system avec hostPath pour monter /var/lib/kubelet/pki. Il extrait les certificats kubelet et les utilise pour accéder à l'API server. À ce stade, il peut créer un ClusterRoleBinding cluster-admin pour sa propre ServiceAccount. L'absence de NetworkPolicies a permis la communication entre namespaces. Les logs d'audit montrent les opérations, mais aucune alerte n'a été triée. Ce cas démontre l'importance des contrôles RBAC, réseau et de l'observabilité.

Étude de cas : admission webhook contourné

Une organisation utilisait un webhook Kyverno pour interdire les pods privilégiés. En cas de panne du webhook (timeout), le cluster devait refuser la requête (failurePolicy: Fail). Toutefois, pour assurer la disponibilité, l'équipe avait mis Ignore. Un attaquant a saturé le webhook par un flood de requêtes, provoqué des timeouts, puis déployé un DaemonSet privilégié qui a injecté un agent sur chaque nœud. L'agent a exfiltré les secrets etcd. La remédiation a consisté à rétablir failurePolicy: Fail, à mettre en place un autoscaling du webhook et un monitoring Prometheus des latences. Pour approfondir ce sujet, consultez notre article sur les techniques d'evasion de conteneurs Docker et Containerd.

Contrôles réseau avancés : service mesh et egress gateway

L'utilisation d'un service mesh (Istio, Linkerd) offre des contrôles L7, du mTLS, et des politiques d'authentification/autorisation. Les egress gateways contrôlent les sorties vers Internet. En combinant des AuthorizationPolicy (Istio) avec des network policies, on limite les actions d'un pod compromis. Les logs du mesh fournissent une visibilité fine : service A parlant à service B, volume de trafic. Les attaquants doivent alors compromettre le mesh, ce qui exige un niveau d'effort plus élevé. Les defenders doivent surveiller les certificats du mesh, empêcher les workloads de désactiver les sidecars, et auditer les policies. Pour approfondir ce sujet, consultez notre article sur les 10 erreurs critiques de configuration RBAC Kubernetes.

Intégration des contrôles dans la CI/CD

Les manifests Kubernetes passent par la CI/CD. On intègre des scanners (KubeLinter, Conftest, Checkov) pour détecter les privileged, hostPath, absence de runAsNonRoot. Les pipelines refusent tout manifest non conforme. Des tests automatisés appliquent des dry-run pour valider l'admission. On maintient une bibliothèque de chart Helm/IaC sécurisés. Les exceptions passent par un processus formel et sont expurgées après usage. La CI/CD intègre aussi des tests d'intrusion automatisés en environnement de staging (chaos engineering) pour valider les défenses.

Chaîne supply chain : images et registries

Les images conteneur sont une autre surface : une image compromise peut embarquer des binaires d'attaque. Les registries doivent être privés, signés (Cosign/Notary v2), scannés (Trivy, Clair). Les contrôles d'admission vérifient la signature des images. Les pipelines build signent les images, définissent des base images minimalistes. Un attaquant qui parvient à pousser une image modifiée dans le registry peut compromettre des pods. Les defenders imposent des ImagePolicyWebhook, surveillent les imagePullSecrets et isolent les registries. Pour approfondir, consultez SIEM : Correlations Avancees pour Threat Hunting.

Gestion des identités externes et des kubeconfigs

Les kubeconfigs sont souvent partagés. Ils contiennent des tokens ou certs. Les organisations doivent : utiliser OIDC (Dex, auth0, Azure AD) pour authentifier les utilisateurs, activer la rotation des tokens, stocker les kubeconfigs dans des vaults, et activer l'authentification par certificat et RBAC. Les connexions admin doivent passer par un bastion, avec audit. Les accès kubectl sont monitorés via audit log. Les tokens service account doivent être définis comme expirables (BoundServiceAccountTokenVolume), réduisant le risque de réutilisation.

Réponse à incident et forensic Kubernetes

Lors d'un incident, la réponse comprend :

1. Isoler le namespace ou le nœud (NetworkPolicy d'urgence, cordon/drain du nœud). 2. Capturer les logs (pod logs, audit logs, Falco alerts). 3. Geler l'état des pods suspects (snapshot volumes, kubectl get -o yaml). 4. Révoquer les tokens (rotation des secrets, suppression des ServiceAccount compromises). 5. Analyser etcd (snapshot) pour identifier les modifications.

Les équipes forensic utilisent kubectl get events, kubectl describe pour retracer les actions. Des outils comme Sight (Sysdig) ou K8s forensic toolkit documentent les preuves. Les rapports comprennent la timeline, les rôles ciblés, les secrets exfiltrés, et les recommandations.

Gouvernance et formation

La sécurité Kubernetes requiert une gouvernance forte : chartes de namespaces, critères d'acceptation des workloads, comités d'architecture. Les équipes produit suivent des formations sur RBAC, secret management, network policy. Des checklists accompagnent chaque déploiement (RBAC minimal, Pod Security, logs). On organise des ateliers secops/devops pour analyser des incidents. La gouvernance inclut des audits trimestriels, une matrice de responsabilités (RACI) et des revues par les architectes sécurité.

Roadmap de maturité

1. Phase 1 : Audit initial (kubebench, RBAC review), chiffrement etcd, activation audit log. 2. Phase 2 : Déploiement de Network Policies, adoption Kyverno/Gatekeeper, Falco. 3. Phase 3 : Intégration CI/CD, service mesh mTLS, gestion avancée des secrets. 4. Phase 4 : Chasse proactive, ML sur logs, chaos engineering, supply chain signée.

Chaque phase inclut des OKR et une validation. Les clusters multi-cloud (AKS/EKS/GKE) adoptent des standards communs.

Questions frequemment posees

Conclusion

Kubernetes offre agilité et scalabilité, mais une exposition accrue aux attaques. En comprenant les techniques offensives (Abus RBAC, admission controllers, secrets), les defenders peuvent mettre en place des contrôles réseau robustes, des politiques Kyverno, un audit continu et une observabilité avancée. Les organisations doivent combiner gouvernance, automatisation et détection pour rendre le cluster résilient. La maturité se construit par itérations, en alignant SecOps, DevOps et les équipes produit.

Étude de cas : cluster de production compromis par Helm

Un cluster de commerce électronique utilisait Helm pour gérer les déploiements. Un chart tiers contenait une template défaillante créant une ServiceAccount avec cluster-admin. Lors de l'installation, cette ServiceAccount a été liée via ClusterRoleBinding. Quelques semaines plus tard, un attaquant a exploité une vulnérabilité RCE sur un pod exposé. En lisant la configuration du pod, il a découvert la ServiceAccount sur-privilégiée. En l'utilisant, il a déployé un DaemonSet qui exfiltrait les secrets vers un bucket externe. Les logs d'audit ont montré une série d'appels create sur des daemonsets. L'absence de NetworkPolicy a autorisé la communication sortante. L'incident a conduit à l'interdiction des charts non vérifiés, à la mise en œuvre de scanners (Chartmuseum policy), et à des revues de RBAC automatisées.

Étude de cas : fuite de kubeconfig et pivot Azure

Une entreprise multi-cloud a subi la compromission d'un laptop développeur. Le kubeconfig du cluster AKS se trouvait dans ~/.kube/config. L'attaquant a utilisé kubectl pour accéder au cluster, a découvert un secret contenant des clés Azure Storage, puis a pivoté vers l'abonnement Azure, exfiltrant des données sensibles. L'absence d'authentification Azure AD (utilisation de certificats locaux) et de conditional access a facilité l'exploitation. La remédiation a impliqué la rotation des kubeconfigs, l'adoption d'Azure AD et de Azure RBAC for Kubernetes, l'exigence de Device compliance, et la mise en œuvre de Just-In-Time via Azure AD PIM pour les administrateurs.

Approche Purple Team et simulations Kubernetes

Les exercices Purple Team pour Kubernetes simulent :

• Compromission d'un pod et exploitation de RBAC.
• Exfiltration de secrets etcd.
• Contournement de Kyverno.
• Abus d'un admission webhook.

Les équipes Red utilisent des outils comme kube-hunter, Peirates, krane. Les Blue exploitent audit logs, Falco, Prometheus. Chaque exercice documente la timeline, les détections, les lacunes. Les actions correctives incluent la création de nouvelles règles Falco, l'ajout de NetworkPolicies, la modification de RBAC. Les exercices renforcent la coopération SecOps/DevOps.

Sécurisation d'etcd et contrôles d'accès

Etcd contient l'état du cluster. Les contrôles clés :

• Chiffrement au repos avec KMS.
• Accès restreint via TLS client certs.
• Isolation réseau (pas d'exposition Internet, firewall strict).
• Sauvegardes chiffrées et protégées.

Les attaques sur etcd consistent à lire directement la base (etcdctl get --prefix /registry/secrets). Les defenders doivent auditers les logs etcd, limiter les hôtes autorisés et surveiller les sauvegardes. Les clusters managés (EKS, AKS, GKE) externalisent etcd mais exigent tout de même des contrôles (permissions IAM, VPC, RBAC).

Supply chain : contrôleurs et opérateurs

Les opérateurs Kubernetes (ArgoCD, Flux, Istio, Prometheus Operator) introduisent du code qui agit en cluster-admin. Leur compromission équivaut à celle du cluster. Les organisations doivent : utiliser des versions signées, surveiller les webhooks, restreindre les permissions, segmenter leurs namespaces. ArgoCD, par exemple, nécessite que les repositories Git soient en lecture seule, et que les tokens ne permettent pas d'écriture. Les pipelines GitOps doivent être sécurisés (MFA, review). Une attaque sur GitOps peut pousser des manifests malveillants.

Détection des contournements de NetworkPolicy

Les adversaires recherchent des pods sans policy (DefaultDeny manquante). Des scripts (Kubescape, np-viewer) vérifient les coverage. Une stratégie efficace impose un default deny par namespace et autorise explicitement les flux. Les logs CNI (Calico Felix, Cilium Hubble) permettent de détecter des paquets drop. Une augmentation des deny peut indiquer une reconnaissance. Les defenders doivent aussi surveiller l'utilisation de hostNetwork ou de services NodePort exposés.

Hardening des nœuds et du runtime Pour approfondir, consultez Exploitation de l’Infrastructure as Code Terraform et Pulumi.

Les nœuds Kubernetes doivent être durcis :

• Systèmes up-to-date, patch management.
• Activation de seccomp, AppArmor ou SELinux.
• Désactivation des services inutiles.
• Journalisation des accès SSH (idéalement interdits, usage d'image immuable).

Les runtimes (containerd, CRI-O) doivent être configurés pour refuser les images non signées, limiter les capabilities. Les attaquants tentent de prendre le contrôle de l'hôte via privileged. Les defenders utilisent des scanners (Lynis, kube-bench node) et les guides CIS pour durcir.

Alignement avec MITRE ATT&CK pour Containers

L'utilisation de la matrice MITRE ATT&CK for Containers aide à classer les TTP :

• Initial Access : Exposed Dashboard, Compromised Image.
• Execution : Exec into container, Run command via API server.
• Persistence : Malicious daemonset, Backdoor via mutated controller.
• Privilege Escalation : Privileged container, Create ClusterRoleBinding.
• Defense Evasion : Delete audit logs, Modify admission webhook.
• Credential Access : Dump etcd, Read service account tokens.
• Discovery : List pods, services, nodes.
• Lateral Movement : Access other namespaces, call cloud metadata.
• Collection : Copy secrets, capture traffic.
• Exfiltration : Upload via external service.
• Command & Control : Reverse shell, WebSocket.

Chaque tactique est mappée à des détections (Falco, audit logs) et des contrôles (RBAC, Kyverno). Cette approche fournit un langage commun entre défenseurs et auditeurs.

Outils de posture et dashboards

Les plateformes CSPM/CNAPP (Prisma Cloud, Wiz, Aqua, Lacework) offrent des vues centralisées : pods privilégiés, secrets, RBAC drifts, network exposures. Elles fournissent des graphes reliant les workloads aux ressources cloud. Les dashboards internes combinent :

• Nombre de ClusterRoleBinding non conformes.
• Taux de couverture NetworkPolicy.
• Pourcentage de pods running as non-root.
• Score Kyverno (policies pass/fail).
• Alertes Falco par cluster.

Ces KPI guident les plans d'action, priorisent les clusters critiques, et mesurent la maturité.

Gestion multi-cluster et fédération

Les organisations gèrent plusieurs clusters (prod, staging, edge). La fédération multiplie la surface. Les accès kubectl doivent passer par un broker (Teleport, Rancher, Anthos). Les politiques RBAC sont répliquées via GitOps. Les clusters edge sont isolés réseau, les secrets y sont minimisés. Les clusters gérés par des providers (AKS/EKS/GKE) doivent être configurés pour limiter l'accès cloud provider (IAM RBAC). Les logs de chaque cluster convergent vers une plateforme centrale.

Rôle des contrôles cloud (IAM, VPC)

Les clusters dans AWS utilisent IAM pour gérer les nœuds (instance profiles) et l'API. Une IAM mal configurée permet un pivot : un pod accède à l'IMDS, récupère des credentials, et agit sur le compte AWS. Les CNI AWS VPC CNI, Calico s'intègrent au VPC ; des security groups restreignent l'accès. Les clusters GKE utilisent Google IAM et VPC Service Controls ; AKS s'appuie sur Azure AD et NSG. Les security teams doivent aligner les contrôles cloud et Kubernetes pour éviter des gaps (ex : Node security group ouvert).

Traitement des logs et réponse automatisée

L'intégration des logs Kubernetes dans un SOAR permet des réponses automatiques :

• Lorsqu'un ClusterRoleBinding suspect est détecté, un workflow supprime la binding et notifie SecOps.
• Si un pod privilégié apparaît, un script kubectl delete le supprime et bloque l'image.
• En cas d'exfiltration, une NetworkPolicy d'urgence applique un deny all.

Ces automatisations doivent être contrôlées (eviter de casser la prod). Des approbations manuelles (gates) peuvent être requises. Le SOAR interagit avec Kubernetes via une identité dédiée RBAC.

Intégration DevSecOps et formation

Les équipes DevOps doivent intégrer la sécurité : formations sur RBAC, sur la lecture d'audit log, sur la création de NetworkPolicy. Les pipelines incluent des tests de sécurité. Des guildes internes partagent des best practices. Les architectes sécurité valident les designs Kubernetes (ingress, secrets, storage). Un programme de certification interne garantit la compétence. Les équipes SRE maintiennent des runbooks (rotation secrets, restauration etcd, incident response) et veillent à ce que chaque équipe sache les utiliser.

Checklist finale

1. RBAC minimal, revue trimestrielle, interdiction de cluster-admin pour les workloads. 2. Activation et surveillance des Admission Controllers, politiques Kyverno/Gatekeeper couvrant tous les namespaces. 3. Chiffrement et protection d'etcd, rotation des secrets via External Secrets. 4. NetworkPolicies par défaut, service mesh mTLS, egress contrôlé. 5. Intégration Falco, audit logs, CNI telemetry, dashboards centralisés. 6. CI/CD avec scans de manifests, signature d'images, GitOps sécurisé. 7. Hardening des nœuds, activation seccomp/AppArmor, runtime minimal. 8. Exercices Purple Team, chaos engineering, alignement MITRE ATT&CK. 9. Gouvernance forte avec comités, formations, owners par namespace. 10. SOAR et playbooks pour réponse rapide, automations contrôlées.

En appliquant cette checklist, les organisations renforcent la résilience de leurs clusters Kubernetes face aux attaques offensives ciblant RBAC, admission controllers et secrets.

Perspectives futures : Confidential Containers et Zero Trust

L'écosystème évolue vers des solutions renforçant l'isolement : Confidential Containers (Confidential Computing) exécutent des pods dans des enclaves chiffrées, empêchant l'hôte de lire la mémoire. Les contrôles Zero Trust appliquent une authentification mutuelle sur chaque requête API (SPIFFE/SPIRE). Les projets comme KubeArmor, Tetragon utilisent eBPF pour contrôler finement les actions. Les defender doivent anticiper ces évolutions, évaluer leur intégration et adapter les policies. L'objectif est de réduire la surface d'escalade même si un pod est compromis.

Annexes : références et outils

• Guides CIS Kubernetes Benchmark.
• Documentation Kyverno et Gatekeeper.
• Outils open-source : Peirates (offensif), Kube-Hunter (scanning), Falco (détection), Trivy (scan image), Kubescape (audit).
• Blogs : CNCF, Aqua Nautilus, Sysdig Threat Research.
• Talks : KubeCon sessions sur la sécurité RBAC, supply chain, eBPF.

Les équipes sécurité doivent maintenir une veille active, participer aux communautés CNCF, partager les retours d'expérience.

Conclusion enrichie

La défense Kubernetes nécessite une approche holistique : comprendre les chemins offensifs, établir des politiques rigoureuses, surveiller en continu, automatiser la remédiation et former les équipes. Les attaques sur RBAC, les contournements d'admission controllers et le pillage des secrets resteront des vecteurs majeurs. En combinant contrôles réseau, Pod Security (Kyverno, PSP standards), audits permanents et gouvernance, les organisations peuvent opérer Kubernetes en conservant confiance et agilité. L'investissement constant dans les outils, les compétences et la collaboration inter-équipes est la clé d'une posture résiliente.

FAQ opérationnelle

Cette FAQ sert de mémo pour les équipes opérant Kubernetes au quotidien.

Note finale

La modernisation continue des contrôles et la réévaluation périodique des hypothèses de sécurité garantissent que les mécanismes déployés restent efficaces face aux TTP émergentes.

6. Silver Ticket : falsification de tickets de service

6.1 Principe et mécanisme

Un Silver Ticket est un ticket de service forgé sans interaction avec le KDC. Si un attaquant obtient le hash NTLM (ou la clé AES) d'un compte de service, il peut créer des tickets de service valides pour ce service sans que le DC ne soit contacté. Le ticket forgé contient un PAC (Privilege Attribute Certificate) arbitraire, permettant à l'attaquant de s'octroyer n'importe quels privilèges pour le service ciblé.

Contrairement au Golden Ticket qui forge un TGT, le Silver Ticket forge directement un Service Ticket, ce qui le rend plus discret car il ne génère pas d'événement 4768 (demande de TGT) ni 4769 (demande de ST) sur le DC.

6.2 Création et injection de Silver Tickets

# Création d'un Silver Ticket pour le service CIFS
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /target:server01.domain.local /service:cifs /rc4:serviceaccounthash /ptt

# Silver Ticket pour service HTTP (accès web avec IIS/NTLM)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /target:webapp.domain.local /service:http /aes256:serviceaes256key /ptt

# Silver Ticket pour LDAP (accès DC pour DCSync)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /target:dc01.domain.local /service:ldap /rc4:dccomputerhash /ptt

# Silver Ticket pour HOST (WMI/PSRemoting)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /target:server02.domain.local /service:host /rc4:computerhash /ptt

6.3 Cas d'usage spécifiques par service

6.4 Détection des Silver Tickets

# Activer la validation PAC stricte (GPO)
Computer Configuration > Policies > Windows Settings > Security Settings > 
Local Policies > Security Options > 
"Network security: PAC validation" = Enabled

# Script PowerShell pour corréler accès et tickets KDC
$timeframe = (Get-Date).AddHours(-1)
$kdcEvents = Get-WinEvent -FilterHashtable @{LogName='Security';ID=4768,4769;StartTime=$timeframe}
$accessEvents = Get-WinEvent -FilterHashtable @{LogName='Security';ID=4624;StartTime=$timeframe} | 
    Where-Object {$_.Properties[8].Value -eq 3} # Logon type 3 (network)

# Identifier les accès sans ticket KDC correspondant
$accessEvents | ForEach-Object {
    $accessTime = $_.TimeCreated
    $user = $_.Properties[5].Value
    $matchingKDC = $kdcEvents | Where-Object {
        $_.Properties[0].Value -eq $user -and 
        [Math]::Abs(($_.TimeCreated - $accessTime).TotalSeconds) -lt 30
    }
    if (-not $matchingKDC) {
        Write-Warning "Accès suspect sans ticket KDC: $user à $accessTime"
    }
}

7. Golden Ticket : compromission totale du domaine

7.1 Principe et impact

Le Golden Ticket représente l'apex de la compromission Kerberos. En obtenant le hash du compte krbtgt (le compte de service utilisé par le KDC pour signer tous les TGT), un attaquant peut forger des TGT arbitraires pour n'importe quel utilisateur, y compris des comptes inexistants, avec des privilèges et une durée de validité de son choix (jusqu'à 10 ans).

Un Golden Ticket offre une persistance exceptionnelle : même après la réinitialisation de tous les mots de passe du domaine, l'attaquant conserve son accès tant que le compte krbtgt n'est pas réinitialisé (opération délicate nécessitant deux réinitialisations espacées).

Copyright Ayi NEDJIMI Consultants