Sécurisation Kubernetes : plan d’action 30 jours pour PME

Table des matières :

1. Kubernetes en PME : la surface d’attaque qui grandit plus vite que le budget
2. Jours 1–7 : cartographier, verrouiller les accès, activer des preuves (audit logs)
3. Jours 8–15 : supply chain & workloads — images propres, politiques d’admission, secrets chiffrés
4. Jours 16–22 : réseau, exposition et Zero Trust — l’Ingress n’est pas un pare-feu
5. Jours 23–27 : détection et observabilité sécurité — MTTD/MTTR plutôt que “ça a l’air ok”
6. Jours 28–30 : industrialiser — CI/CD, IaC, benchmarks, et MCO/MCS qui tient la route

Kubernetes en PME : la surface d’attaque qui grandit plus vite que le budget

La sécurisation Kubernetes en PME commence par un constat peu glamour : Kubernetes n’est pas « un serveur qui tourne des conteneurs ». C’est une plateforme distribuée avec une API omniprésente, des identités, des contrôleurs, du réseau overlay, du stockage, des webhooks, des registries, et une bonne dose de YAML créatif. Résultat : la surface d’attaque augmente plus vite que la maturité sécu de l’équipe (et souvent plus vite que la ligne « cybersécurité » du budget). Une seule mauvaise pratique — un ClusterRoleBinding en cluster-admin, un Service en LoadBalancer exposé « pour tester », un secret en clair dans Git — et vous venez d’inventer votre propre CTF.

Sur le papier, Kubernetes est « configurable » et « extensible » ; dans la vraie vie, ça veut dire que vous pouvez aussi le configurer de travers à l’infini. Les guides sérieux insistent sur la défense en profondeur : la superposition de contrôles réduit le risque, plutôt que de s’en remettre à une seule barrière (par exemple « cluster privé = cluster sécurisé »).

Et parce que la réalité aime l’ironie, la plupart des incidents Kubernetes « en PME » ne viennent pas d’un 0-day exotique, mais de la supply chain, des identités trop puissantes, et d’une observabilité insuffisante. Bruce Schneier résume bien l’idée (en substance) : la sécurité est un processus continu, pas un achat ponctuel. Source : Bruce Schneier — The Process of Security (essay)
Donc oui : un plan d’action 30 jours est utile… à condition d’être pensé comme le début d’une routine MCO/MCS, pas comme une séance de magie.

Dernier point très “PME France/UE” : si vous traitez des données personnelles (clients, employés, tracking, support…), la sécurité n’est pas qu’une bonne pratique : le RGPD impose des mesures techniques et organisationnelles appropriées (article 32). Référence officielle : Règlement (UE) 2016/679 (RGPD)
Ça ne dicte pas « quelle NetworkPolicy écrire », mais ça renforce un principe : tracer, limiter, et pouvoir démontrer (au minimum) ce qui protège l’accès, la confidentialité, l’intégrité et la disponibilité.

Jours 1–7 : cartographier, verrouiller les accès, activer des preuves (audit logs)

Jour 1, vous faites ce que tout le monde repousse : l’inventaire. Clusters (prod/stage), versions Kubernetes, CNI/CSI, Ingress, registries, namespaces, add-ons, endpoints exposés. Ajoutez une mini threat-model : quels workloads manipulent des données sensibles ? quels services doivent sortir en Internet ? qui a accès à quoi ? Le but n’est pas d’écrire un roman, mais d’obtenir une carte exploitable. Bonus pour les PME e-commerce : identifiez les flux vers PSP, ERP, CRM et la partie « paiement » (souvent la plus réglementée et la moins comprise).

Pour rendre l’inventaire actionnable (et éviter “un tableau Excel qui meurt”), visez un format minimal comme ci-dessous :

Élément	Exemple	Pourquoi c’est critique
Exposition	Ingress public, LoadBalancer, VPN	Point d’entrée principal des attaques
Identités	OIDC, comptes de service, tokens longs	Base du mouvement latéral
Données	namespaces avec PII, configs, secrets	Impact légal + business
Chaîne CI/CD	registry, signatures, droits du runner	Source fréquente d’injections
Add-ons	Ingress controller, cert-manager, metrics-server	Add-ons = API + privilèges

Jours 2–4 : verrouillage des accès au control plane. Si l’API server est accessible depuis tout votre VPN « parce que c’est pratique », vous venez de rendre le mouvement latéral trop facile. Réduisez l’exposition réseau (allowlist IP, bastion, SSO), et standardisez l’authentification (OIDC si possible). Côté autorisation, on assume enfin que RBAC (Role-Based Access Control) n’est pas un décor : on supprime le folklore des comptes permanents et on force des rôles par namespace.

Un “test mental” simple : si un poste de dev est compromis, l’attaquant peut-il (a) lister les secrets, (b) exécuter un shell dans un pod en prod, (c) créer un ClusterRoleBinding ? Si oui, vous avez un sujet prioritaire — même si “ça marche bien” aujourd’hui.

En pratique, commencez par une chasse aux droits :

kubectl get clusterrolebinding,rolebinding -A
kubectl auth can-i --list --as=system:serviceaccount:ns:sa

Ajoutez un contrôle très concret : listez et supprimez les “raccourcis” (ex. bindings historiques vers cluster-admin) et remplacez-les par :

• des rôles par namespace (lecture seule, déploiement, debug limité),
• des comptes de service par application (pas “un SA pour tout le namespace”),
• des droits temporaires pour les opérations sensibles (break-glass, avec justification + expiration).

Jours 5–7 : vous activez des preuves. Parce que « on n’a rien vu dans les logs » est souvent vrai… quand il n’y a pas de logs. Activez l’audit logging de l’API Kubernetes avec une policy qui capture au minimum : créations/patch/suppressions, RBAC, secrets, exec/port-forward, et erreurs d’auth. Les logs doivent être centralisés (Loki/Elastic/SIEM), horodatés correctement, et conservés (30 jours en PME, 90+ si exigence).

Le guide officiel Kubernetes rappelle que la sécurité est multi-couches et que l’API est centrale : Guide officiel Kubernetes – sécurité
Sans audit trail, votre « réponse à incident » ressemblera à du théâtre d’impro.

Exemple minimaliste de policy d’audit (à adapter : le but est d’avoir du signal, pas de tout logger en RequestResponse) :

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets", "configmaps"]
  - level: Metadata
    verbs: ["create", "update", "patch", "delete", "deletecollection"]
  - level: Metadata
    resources:
      - group: "rbac.authorization.k8s.io"
        resources: ["rolebindings", "clusterrolebindings", "roles", "clusterroles"]
  - level: Metadata
    resources:
      - group: ""
        resources: ["pods/exec", "pods/portforward"]

Point d’attention “PME réaliste” : les audit logs peuvent contenir des identifiants, noms de ressources, parfois des indices de données sensibles. Traitez-les comme des données de sécurité (accès restreint, rétention maîtrisée, export chiffré si besoin), et évitez d’y capturer des corps de requête sans nécessité.

Jours 8–15 : supply chain & workloads — images propres, politiques d’admission, secrets chiffrés

Jours 8–10 : on s’attaque au problème qui fait mal à l’ego : la supply chain. Une image Docker “trouvée” sur Internet, taguée latest, sans SBOM, c’est l’équivalent cloud d’une clé USB inconnue branchée sur le serveur de prod (mais en automatique). Standard : images minimales (distroless/alpine quand c’est raisonnable), pin par digest, et scan systématique (Trivy/Grype).

Pour éviter le piège “on scanne mais on ne décide jamais”, fixez une règle de décision explicite, par exemple :

• blocage si CVE Critical dans l’OS de base ou dans une lib exposée (serveur web, framework),
• exception possible si (a) pas d’exploit connu, (b) mitigation en place, (c) ticket + date de correction,
• SLA de patch (ex. hebdo pour images de base, mensuel pour dépendances non exposées).

Côté métrique, une PME e-commerce typique passe souvent de dizaines de CVE “High/Critical” par release à un chiffre quand elle impose : base image contrôlée + patch cadence hebdo + blocage des CVE critiques. (Le point important n’est pas le chiffre exact, mais la mécanique : vous devez pouvoir mesurer et refuser.)

Jours 11–13 : vous passez de “guidelines” à “ça ne déploie pas si c’est hors règle” via les admission controllers. Deux approches dominent : OPA Gatekeeper (Rego) ou Kyverno (YAML). Objectifs minimum :

• interdire privileged (sauf exception documentée),
• bloquer hostPath hors exceptions,
• exiger runAsNonRoot et un filesystem en lecture seule quand possible,
• imposer des resources (requests/limits) pour éviter le “noisy neighbor” et les DoS involontaires,
• empêcher les images non approuvées (registry allowlist) et, si possible, non signées.

Pour la signature, Sigstore/cosign est une voie raisonnable. Oui, ça ajoute des étapes… mais ça réduit fortement le risque de déployer une image “modifiée” entre CI et prod, et ça vous donne un levier simple en incident : qu’est-ce qui a été déployé, par qui, depuis quelle chaîne ?

Mini-scenario (fréquent) : un runner CI a des droits trop larges sur le registry. Une compromission du runner permet de pousser une image “correcte” au même tag. Si vous pinnez au digest et vérifiez la signature au moment de l’admission, l’attaque devient beaucoup plus complexe (et surtout, plus détectable).

Jours 14–15 : Pod Security Standards et secrets. Depuis la dépréciation de PodSecurityPolicy, Kubernetes fournit Pod Security Admission avec les niveaux Privileged / Baseline / Restricted : Pod Security Standards – Kubernetes
En PME, le pattern efficace est : restricted par défaut, exceptions explicitement documentées (namespace dédié + justification). Ne cherchez pas la perfection en 48h : cherchez le point de bascule où “le déploiement dangereux” devient l’exception coûteuse, pas la norme.

Pour les secrets : chiffrement au repos (EncryptionConfiguration), rotation, et idéalement externalisation (Vault/Cloud KMS) si l’orga est prête. Votre objectif n’est pas la pureté cryptographique, mais de rendre « exfiltrer un secret » plus compliqué que « lire un YAML sur le disque ».

Checklist courte “secrets en PME” :

• pas de secrets en clair dans Git (scans de repo + revue),
• pas de secrets dans des ConfigMap,
• rotation au moins pour : DB, API tiers, tokens d’admin, clés de webhook,
• séparation : un secret par application (éviter le “mega-secret”),
• accès secrets limité (RBAC + service accounts dédiés).

Jours 16–22 : réseau, exposition et Zero Trust — l’Ingress n’est pas un pare-feu

Jours 16–18 : réduisez l’exposition. Faites la liste des services exposés (Ingress, LoadBalancer, NodePort) et demandez-vous pourquoi chacun existe. Beaucoup d’expositions “temporaires” deviennent permanentes (c’est fou comme le temporaire survit). Imposez TLS moderne (TLS 1.2+), rotation des certificats, et politiques de headers côté Ingress (HSTS, X-Content-Type-Options). Si vous terminez TLS sur un CDN/WAF, documentez le modèle de confiance et le chemin des logs.

Un piège classique : « on a un Ingress, donc on est protégés ». Non : un Ingress route, il ne “raisonne” pas sur les intentions. Sans rate limiting, WAF, règles applicatives, et segmentation interne, l’Ingress devient juste un bon aiguillage vers la partie sensible.

Jours 19–20 : WAF, anti-bot et règles applicatives. Pour les PME, l’option pragmatique est souvent un WAF managé (Cloudflare, etc.) avec des règles ciblées : limitation de rate sur endpoints sensibles, blocage des patterns d’exploitation, et challenge sur pics anormaux. Si vous utilisez Cloudflare, vous pouvez pousser loin les règles personnalisées ; voir le guide interne : Cloudflare Custom Rules : créer et gérer des règles WAF personnalisées. Et si votre problème c’est « on se prend des floods », évitez de réinventer la roue : Protection DDoS cloud 2026 : comparatif des 12 meilleures solutions.

Jours 21–22 : réseau interne et egress. La NetworkPolicy n’est pas un sticker “Zero Trust”, c’est un mécanisme concret : par défaut deny, puis allow explicite entre services. Si votre CNI supporte eBPF (Cilium), vous gagnez en visibilité et en enforcement.

Pour démarrer sans “casser la prod”, un pattern PME efficace : 1) appliquer un default deny sur un namespace non critique,
2) ajouter progressivement les flux nécessaires,
3) dupliquer la méthode en prod sur un périmètre maîtrisé (ex. backoffice).

Exemple de default deny (ingress + egress) au niveau namespace :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: mon-namespace
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Ajoutez des contrôles d’egress : DNS autorisé vers résolveurs connus, sorties HTTP(s) limitées par namespace, et blocage des métadatas cloud si vous êtes sur IaaS (sinon SSRF = credentials). Le bénéfice est mesurable : moins de chemins possibles pour l’exfiltration, et des incidents qui restent des incidents locaux plutôt qu’un incendie global.

Jours 23–27 : détection et observabilité sécurité — MTTD/MTTR plutôt que “ça a l’air ok”

Jour 23 : vous définissez ce que vous voulez détecter. Pas “tout”, sinon vous aurez surtout du bruit. Démarrez par : créations de pods anormales, exec dans un pod en prod, escalade RBAC, accès secrets, modifications Ingress, déploiement d’images non conformes, et pics réseau. Ce cadrage colle assez bien à l’esprit NIST (Identify/Protect/Detect/Respond/Recover). La page NIST CSF rappelle les cinq fonctions (Identify, Protect, Detect, Respond, Recover) : NIST CSF

Pour transformer “détecter” en “agir”, associez chaque signal à une action :

• Exec en prod → ticket + notification + justification obligatoire (ou blocage hors fenêtre),
• création d’un ClusterRoleBinding → alerte critique immédiate,
• modification d’Ingress → validation par review + alerte,
• lecture de secrets (API) → corrélation avec déploiement/exec.

Jour 24–25 : métriques et traces. Si vous n’avez pas encore une base solide, commencez simple : Prometheus + Alertmanager, puis enrichissez. Le guide interne Prometheus monitoring : quickstart en 5 minutes et mise en production est une bonne rampe. Pour corréler perf + sécu, OpenTelemetry aide à unifier métriques/traces/logs : OpenTelemetry : unifier métriques, traces et logs pour l’observabilité.

Côté KPI, suivez au minimum MTTD (mean time to detect) et MTTR (mean time to recover) : une PME mature vise souvent < 15 min MTTD sur les alertes critiques (API server, Ingress, auth) et < 60–120 min MTTR sur incidents “contenus”. Pour que ce soit crédible, mesurez sur les incidents et quasi-incidents, pas “sur une semaine calme”.

Jour 26–27 : détection runtime et intégrité. Ajoutez un outil type Falco (syscalls) ou une approche eBPF selon votre stack, et alimentez des règles focalisées : shell interactif, accès /etc/shadow, lancement de binaire inattendu, ouverture de socket sortante anormale. Si vous avez activé l’audit API, corrélez : un exec + un secret lu + un egress vers l’externe doit déclencher un incident.

Réduisez aussi le bruit en excluant explicitement ce qui est “normal” (jobs de maintenance, namespaces système, probes). En PME, une détection efficace, c’est souvent :

• peu de règles,
• bien comprises,
• avec une action claire (qui fait quoi, en combien de temps).

Oui, ça demande de la tuyauterie… mais c’est littéralement ce qui fait la différence entre “on a été compromis” et “on a été compromis, et on l’a su trois semaines après”.

Jours 28–30 : industrialiser — CI/CD, IaC, benchmarks, et MCO/MCS qui tient la route

Jour 28 : sécurité dans le pipeline, pas dans un doc Confluence. Si vous déployez Kubernetes proprement, vous avez déjà un GitOps/CI-CD. Branchez-y les contrôles : scan d’images, vérif manifests (kubeconform), policy-as-code, et publication SBOM. Le tuto interne Pipeline CI/CD Kubernetes : GitHub Actions et Argo CD étape par étape donne une base réaliste pour une PME. Pour aller plus loin côté organisation (gates, responsabilités, automatisation), vous pouvez aussi vous inspirer de DevSecOps-as-a-service : intégrer la sécurité au pipeline CI/CD.

Un format simple à viser (sans “usine à gaz”) :

• à la PR : lint + kubeconform + policy (bloquant),
• au build : scan image + génération SBOM,
• avant déploiement : signature + vérif d’admission,
• après déploiement : vérification continue (drift, images, permissions).

Jour 29 : benchmark et “guardrails” d’infra. Passez un audit de configuration aligné sur le CIS Kubernetes Benchmark (kube-bench est l’outil habituel) et traitez les écarts avec pragmatisme (toutes les recommandations ne sont pas applicables, mais elles sont rarement “à ignorer”). Référence CIS : CIS Kubernetes Benchmark.

Deux nuances importantes en PME :

• Sur Kubernetes managé, vous n’aurez pas la main sur tout le control plane : concentrez-vous sur ce que vous contrôlez (nodes, RBAC, policies, réseau, workloads) et documentez ce qui relève du fournisseur.
• Le benchmark sert aussi à prioriser : corrigez d’abord ce qui touche l’auth, l’API, les permissions, et l’exposition.

Si votre cluster est hébergé sur des VM dont le durcissement est approximatif, vous partez déjà avec une jambe en moins ; à ce sujet, le guide interne VPS Linux : guide de déploiement, durcissement et maintenance proactive évite les erreurs classiques.

Jour 30 : vous rendez ça durable avec du MCO/MCS et des exercices. MCO/MCS signifie : patch cadence (OS, kubelet, CNI/CSI), rotation des clés/certs, sauvegardes testées, restauration testée, et runbooks d’incident. Si vous voulez cadrer ce sujet au niveau “management qui signe un budget”, la page MCO/MCS – Maintien en Conditions Opérationnelles / Maintien en Conditions de Sécurité pose les bases.

Et parce qu’un plan sans test reste une croyance :

• testez une restauration (au moins une fois) sur un environnement isolé,
• faites un exercice “perte de secret” (rotation + invalidation + redeploy),
• simulez un scénario simple : compte OIDC compromis → accès API → exec → exfiltration (et mesurez le MTTD/MTTR).

Programmez ensuite un test d’intrusion (ou au minimum un exercice purple-team) — voir aussi : Cybersécurité : l’importance des tests d’intrusion en entreprise.

—

Checkpoint “PME réaliste” : ce que vous devez pouvoir prouver à J+30

• Accès : authent OIDC/SSO (ou équivalent), RBAC minimal, plus de cluster-admin “par défaut”, comptes de service scoppés.
• Traçabilité : audit logs API activés + centralisés + rétention.
• Workloads : Pod Security restricted par défaut, policies d’admission, secrets chiffrés/rotés.
• Supply chain : scan + SBOM + (idéalement) signature d’images.
• Réseau : exposition maîtrisée, NetworkPolicies, egress contrôlé, WAF/DDoS en frontal si Internet.
• Détection : alerting actionnable, MTTD/MTTR suivis, règles runtime ciblées.

Si vous lisez cette liste en vous disant « on n’a pas le temps », c’est normal : la sécurité a toujours “pas le temps”, jusqu’au jour où l’incident trouve miraculeusement une place dans l’agenda. Si vous avez besoin d’un état des lieux rapide (et brutalement honnête), une option est de passer par un audit dédié : Audit Cybersécurité. Et si l’incident est déjà là (oui, ça arrive), autant éviter le déni : Urgence cybersécurité.