Quand Kubernetes devient la plateforme par défaut, le risque n’est plus seulement « faire tourner des pods » : c’est la dérive de configuration, les accès trop larges, la facture des nœuds sous-utilisés, et les interfaces (réseau, stockage, secrets) qui explosent avec le nombre de contributeurs. Les équipes SRE et plateforme doivent traiter le cluster comme un produit interne soumis aux mêmes exigences de sécurité, conformité et FinOps que les applications métier. Voici une check-list enrichie pour sécuriser l’exploitation avant d’ajouter des clusters ou des namespaces sans fin.
RBAC : le minimum viable et les rôles par équipe
Évitez les cluster-admin partagés ; préférez des Roles limités par namespace et des ClusterRoles pour les opérateurs plateforme uniquement. Documentez qui peut créer des NetworkPolicies, Ingress, PersistentVolumes, ou CRD — ce sont souvent les leviers qui ouvrent la surface d’attaque ou qui figent des dépendances. Révisez les bindings à chaque arrivée de produit : les droits hérités d’un POC ont la vie dure. Pour les audits, conservez un inventaire des ServiceAccounts utilisés par les CI et les opérateurs ; les comptes « techniques » oubliés sont des vecteurs classiques.
Quotas et limites : éviter le « bruit des voisins » et le gaspillage
Sans ResourceQuota et LimitRange, un namespace peut monopoliser le planificateur ou saturer le stockage partagé. Fixez des defaults de CPU/mémoire et des plafonds par équipe ; alignez-les sur la capacité réelle du cluster et sur des objectifs FinOps (éviter les requests gonflées « par précaution »). Les PriorityClasses doivent rester rares et justifiées — sinon tout le monde devient « prioritaire » et la priorisation perd son sens opérationnel.
Pod Security et admission : au-delà du « ça marche »
Adoptez Pod Security Standards (restricted baseline privileged) et renforcez avec Kyverno ou OPA pour interdire privileged, hostNetwork, montages hostPath risqués, ou images sans digest éprouvé. Ces règles réduisent les incidents de fuite de conteneur et simplifient les échanges avec les équipes sécurité et audit. Versionnez les politiques comme du code applicatif : PR, tests, rollback.
Réseau : NetworkPolicies par défaut deny progressive
Le modèle « tout ouvert par défaut » de Kubernetes est pratique en lab, dangereux en production. Introduisez progressivement des politiques par namespace (ingress/egress explicites), en commençant par les charges sensibles (données personnelles, secrets, paiements). Couplez avec DNS contrôlé et service mesh seulement si le coût opérationnel (mTLS, observabilité) est assumé — sinon vous payez en complexité et en formation.
Données d’état : sauvegardes, etcd et applications
Les StatefulSets et bases opérées sur le cluster exigent une stratégie de snapshot (CSI), backup applicatif, ou outils type Velero selon le périmètre — pas seulement la sauvegarde etcd pour la cohérence du plan de contrôle. Jouez des restaurations sur un environnement de drill ; le RTO/RPO se mesure au chrono, pas au PDF. Documentez qui déclenche la reprise, comment valider l’intégrité, et quand basculer vers un plan B réglementaire (continuité d’activité).
Observabilité, coût et astreinte
Centralisez logs, métriques et traces avec des labels cohérents ; imposez des annotations de version/owner sur les déploiements critiques. Les admission controllers aident à rejeter les manifests dangereux — investissez avant que la dette ne devienne politique. Pour le FinOps, exposez par namespace la consommation CPU/mémoire réelle vs requests ; c’est la base d’un chargeback ou d’une conversation saine avec les produits.
Multi-cluster : gouvernance sans proliferation incontrôlée
Multi-cluster résout l’isolement et la résilience, mais multiplie les surfaces à patcher et les versions d’add-ons. Standardisez les versions supportées, les politiques réseau de base, et les patterns GitOps ou équivalent. Sinon chaque cluster devient un snowflake coûteux à exploiter.
Images, registres et supply chain
Verrouillez les registries autorisées et imposez des scans de vulnérabilités dans la CI ; en runtime, des politiques d’admission peuvent refuser les tags :latest en production. Pour la conformité, conservez la provenance des images (signatures cosign, politiques admission). Cela réduit les incidents de compromission de chaîne et clarifie les responsabilités entre sécurité et produits.
Mises à jour, fenêtres et dette de version
Planifiez les mises à niveau du plan de contrôle et des nœuds avec des fenêtres communiquées ; la dette de version devient vite un risque de CVE non patchables. Documentez la politique de support (N-1, N-2) et les exceptions temporaires avec date de fin. Le coût de rester en retard se paie en incidents et en ingénierie d’urgence.
FAQ
Faut-il un cluster par équipe ? Pas systématiquement : namespaces forts avec quotas et RBAC suffisent souvent ; multi-cluster se justifie par l’isolement, la réglementation, ou la latence.
Comment prouver la conformité ? Gardez des preuves : politiques versionnées, journaux d’admission, revues RBAC périodiques, drills de restauration.
En synthèse
Kubernetes reste un excellent socle — à condition d’être gouverné comme un produit interne : RBAC serré, quotas clairs, réseau explicite, sauvegardes prouvées, admission active, et visibilité coût/usage. Scaler les équipes sans ces garde-fous, c’est scaler le chaos — et la facture.
Vous industrialisez ou durcissez une plateforme conteneurs ? Découvrez les services ou écrivez via le formulaire de contact.