Sécuriser un cluster Kubernetes : les fondamentaux souvent négligés

Un cluster Kubernetes fraîchement installé n’est pas sécurisé par défaut. Les configurations par défaut privilégient l’accessibilité. Voici les mesures fondamentales qui s’appliquent à tous les clusters de production.

Network Policies : isoler les namespaces

Par défaut, tous les pods d’un cluster peuvent communiquer entre eux. Une compromission d’un pod peut donc se propager latéralement.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress: []  # Bloque tout le trafic entrant par défaut

Commencez par une politique “deny all” par namespace, puis autorisez explicitement les communications nécessaires.

Pod Security Standards

Les Pod Security Standards remplacent les PodSecurityPolicies (dépréciées depuis K8s 1.21). Activez le profil restricted pour vos workloads de production :

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/warn: restricted

Le profil restricted interdit notamment : l’exécution en root, les capabilities Linux dangereuses, l’accès au système de fichiers hôte.

RBAC : le principe de moindre privilège

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: app-reader
rules:
- apiGroups: [""]
  resources: ["pods", "services"]
  verbs: ["get", "list", "watch"]

Ne donnez jamais de ClusterRole quand un Role namespace suffit. Évitez verbs: ["*"] ou resources: ["*"].

Secrets chiffrés au repos

Par défaut, les Kubernetes Secrets sont encodés en base64 — pas chiffrés. Un accès en lecture à etcd révèle tous les secrets en clair.

# encryption-config.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <base64-encoded-32-byte-key>
      - identity: {}

Audit logs : tracer qui fait quoi

Activez les audit logs de l’API server pour enregistrer chaque appel à l’API Kubernetes. En cas d’incident, c’est votre seule source de vérité sur ce qui s’est passé.

Scan des images avec Trivy

trivy image --exit-code 1 --severity HIGH,CRITICAL mon-image:latest

Intégrez ce scan dans votre pipeline CI/CD. Un job qui échoue si l’image contient des CVE HIGH/CRITICAL avant de permettre le déploiement.

Notre formation Kubernetes inclut un module sécurité avec des ateliers sur cluster réel.