Sécurité Kubernetes : RBAC, NetworkPolicy et bonnes pratiques 2025

Kubernetes n'est pas sécurisé par défaut

Un cluster Kubernetes fraîchement installé avec les options par défaut est loin d'être sécurisé. Pods qui tournent en root, accès à l'API server sans authentification forte, pas de network policies, secrets stockés en base64 non chiffré dans etcd... Les incidents de sécurité Kubernetes sont régulièrement documentés, souvent liés à des clusters mal configurés exposés sur Internet.

RBAC : Role-Based Access Control

RBAC est le mécanisme d'autorisation natif de Kubernetes. Il contrôle qui peut faire quoi sur quelles ressources. Les concepts clés :

• Role / ClusterRole : ensemble de permissions (verbs: get, list, create, delete) sur des resources (pods, deployments, secrets)
• RoleBinding / ClusterRoleBinding : lie un Role à un sujet (User, Group, ServiceAccount)

Exemple de Role pour un développeur en lecture seule :

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer-readonly
  namespace: production
rules:
  - apiGroups: ["", "apps"]
    resources: ["pods", "deployments", "services", "configmaps"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["pods/log"]
    verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-readonly-binding
  namespace: production
subjects:
  - kind: User
    name: alice@company.com
roleRef:
  kind: Role
  name: developer-readonly
  apiGroup: rbac.authorization.k8s.io

Audit des permissions existantes

# Lister les ClusterRoleBindings donnant des droits admin
kubectl get clusterrolebindings -o json | jq '.items[] | select(.roleRef.name=="cluster-admin") | .subjects'

# Outil rbac-audit
kubectl-who-can create pods --namespace production

NetworkPolicy : micro-segmentation réseau

Par défaut, tous les pods d'un cluster peuvent communiquer entre eux. Les NetworkPolicies définissent des règles de trafic autorisé — équivalent des Security Groups AWS mais au niveau des pods.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-network-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes: [Ingress, Egress]
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - port: 8080
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: database
      ports:
        - port: 5432
    - to:  # DNS
        - namespaceSelector: {}
      ports:
        - port: 53
          protocol: UDP

Stratégie recommandée : default-deny dans chaque namespace, puis autoriser explicitement les flux nécessaires.

Pod Security Standards (PSS)

Les PSS remplacent les Pod Security Policies (dépréciées depuis K8s 1.25). Trois niveaux :

• Privileged : aucune restriction (à éviter en production)
• Baseline : prévient les escalades de privilèges évidentes (pas de privileged containers, pas de hostPID/hostNetwork)
• Restricted : best practices maximales (non-root, read-only root filesystem, no privilege escalation)

# Appliquer le niveau restricted sur un namespace
kubectl label namespace production   pod-security.kubernetes.io/enforce=restricted   pod-security.kubernetes.io/enforce-version=latest

Chiffrement des Secrets

Les Secrets Kubernetes sont encodés en base64 dans etcd — pas chiffrés. Pour une vraie protection :

• Encryption at Rest : activer le chiffrement AES-GCM des secrets dans etcd via la configuration EncryptionConfiguration
• External Secrets Operator : intégration avec AWS Secrets Manager, Azure Key Vault, HashiCorp Vault — les secrets ne sont jamais stockés dans Kubernetes, récupérés à la demande
• CSI Secret Store Driver : monte les secrets depuis un provider externe directement comme volume dans le pod

Scanning et conformité continue

Outil	Usage
Trivy	Scan des images Docker (CVE), IaC, SBOM
Falco	Détection d'anomalies runtime (syscalls suspects)
Kube-bench	Audit CIS Kubernetes Benchmark
OPA/Gatekeeper	Policy-as-code : admission controller personnalisable
Kyverno	Alternative OPA, policies YAML natives Kubernetes

Conclusion

Sécuriser Kubernetes est un effort continu qui couvre plusieurs couches : RBAC pour les accès humains et machines, NetworkPolicy pour la segmentation réseau, Pod Security Standards pour le comportement des conteneurs, et chiffrement des secrets. Aucune de ces couches seule ne suffit — la défense en profondeur est la seule approche viable. Un audit régulier avec kube-bench et Trivy est indispensable pour maintenir un cluster conforme dans le temps.