Namespaces Kubernetes : une vraie isolation avec RBAC et Network Policy

TL;DR

• Un namespace trace une frontière de noms, pas de sécurité. À lui seul, il n'empêche ni l'accès API inter-namespaces, ni le trafic réseau, ni la contention de ressources.
• RBAC contrôle qui peut agir sur les ressources d'un namespace. Il refuse par défaut : personne n'a accès tant que vous n'accordez pas un Role et ne le liez pas.
• NetworkPolicy contrôle ce qui peut communiquer avec quoi. Kubernetes fait ici l'inverse de RBAC : chaque pod peut joindre tous les autres pods tant qu'aucune policy ne le restreint.
• ResourceQuota et LimitRange plafonnent ce qu'un namespace peut consommer, en compute comme en nombre d'objets, afin qu'un tenant ne puisse pas priver de ressources le reste du cluster ou le control plane.
• Rien de tout cela n'est configuré d'origine. Vous devez ajouter chacun de ces contrôles, namespace par namespace, sinon l'isolation n'existe pas.

Les namespaces donnent une impression d'isolation. Créez-en un pour l'équipe A et un pour l'équipe B : les pods, services et configs des deux équipes se retrouvent dans des compartiments séparés, avec des noms distincts. Mais la frontière s'arrête là. Rien, dans un namespace en soi, n'empêche le service account de l'équipe A de lire les secrets de l'équipe B, n'empêche les pods de l'équipe A d'ouvrir une connexion vers la base de données de l'équipe B, ni n'empêche les workloads de l'équipe A de priver de ressources les pods de l'équipe B sur un nœud partagé.

La multi-tenancy Kubernetes repose sur trois contrôles qui transforment cette frontière de noms en véritable frontière de sécurité et de ressources : RBAC, NetworkPolicy et ResourceQuota. Chacun régit un type d'accès différent, et chacun a un comportement par défaut qui prend les équipes au dépourvu.

RBAC : contrôler qui peut agir

RBAC détermine quels utilisateurs, groupes et service accounts peuvent faire quoi, sur quelles ressources et dans quels namespaces. Son état par défaut joue en votre faveur : un service account ou un utilisateur n'a aucune permission tant qu'un Role ne lui en accorde pas et qu'un RoleBinding ne lui attribue pas ce Role. Aucune fuite accidentelle.

Un Role limité à un namespace restreint la portée de cette autorisation à un seul namespace :

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: team-a
  name: team-a-editor
rules:
  - apiGroups: ["", "apps"]
    resources: ["pods", "deployments", "services"]
    verbs: ["get", "list", "watch", "create", "update", "patch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-a-editor-binding
  namespace: team-a
subjects:
  - kind: Group
    name: team-a-engineers
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: team-a-editor
  apiGroup: rbac.authorization.k8s.io

Trois habitudes évitent que RBAC ne devienne lui-même un risque :

Liez les Roles à des groupes, pas à des utilisateurs individuels. Un RoleBinding rattaché à des utilisateurs nommés devient obsolète dès que quelqu'un change d'équipe ; un binding de groupe se met à jour automatiquement quand l'appartenance aux groupes évolue dans votre fournisseur d'identité.

Méfiez-vous des ClusterRoleBindings accordés par commodité pour un tenant. Un ClusterRole lié à l'échelle du cluster donne accès à tous les namespaces du cluster, ce qui ruine l'intérêt même d'avoir limité un Role à team-a. Ne recourez à un ClusterRole que lorsque vous en avez réellement besoin, et liez-le avec un RoleBinding limité au namespace quand c'est possible.

Passez les bindings en revue à intervalles réguliers. La prolifération RBAC (des dizaines de Roles quasi identiques et des bindings obsolètes pour des personnes qui ont quitté l'équipe) transforme un audit de quelques minutes en plusieurs jours. Une revue trimestrielle détecte les dérives avant qu'elles ne deviennent un incident de sécurité.

RBAC détermine aussi qui peut lire les Kubernetes Secrets et gérer la propriété des ressources au sein d'un namespace : un Role trop large expose donc bien plus qu'un simple accès au compute. Et lorsque RBAC bloque une requête, Kubernetes renvoie une erreur Forbidden plutôt qu'une 404, une distinction utile à connaître lorsque vous déboguez des erreurs de cluster.

NetworkPolicy : contrôler ce qui peut communiquer avec quoi

Inversez le comportement par défaut de RBAC et vous obtenez l'état initial de NetworkPolicy. Kubernetes est livré avec un réseau à plat : n'importe quel pod peut ouvrir une connexion vers n'importe quel autre pod du cluster, tous namespaces confondus, tant que rien ne l'en empêche. Une NetworkPolicy bloque ce trafic dès que vous en ajoutez une ; en attendant, le contrôle d'accès strict de RBAC ne fait rien pour empêcher un pod compromis de franchir les frontières de namespaces par le réseau.

Commencez par une policy default-deny dans chaque namespace :

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

En refusant l'egress, vous bloquez aussi le DNS. CoreDNS tourne normalement dans le namespace kube-system sur le port 53. Sans accès DNS, les pods de team-a ne peuvent plus résoudre les noms de services, et les applications qui dépendent du DNS commencent à échouer. Autorisez le DNS avant d'ajouter d'autres règles egress : apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-dns namespace: team-a spec: podSelector: {} policyTypes: - Egress egress: - to: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: kube-system ports: - protocol: UDP port: 53 - protocol: TCP port: 53

Ajoutez ensuite des autorisations explicites pour ce qui a réellement besoin de communiquer. Celle-ci n'autorise que le trafic provenant d'autres pods du même namespace :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-same-namespace
  namespace: team-a
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: team-a

Un piège attend les équipes qui ne l'ont jamais rencontré : NetworkPolicy ne fonctionne que si votre plugin CNI l'applique. Calico, Cilium et quelques autres implémentent l'API NetworkPolicy ; certains plugins CNI ne le font pas, et sur ceux-là, vos policies soigneusement rédigées sont acceptées par l'API server puis silencieusement ignorées au niveau réseau. Vérifiez que votre CNI applique NetworkPolicy avant de la considérer comme une véritable frontière, pas après.

ResourceQuota et LimitRange : plafonner ce qu'un namespace peut consommer

RBAC et NetworkPolicy bloquent les accès. ResourceQuota bloque la consommation. Sans quota, un namespace peut demander assez de CPU et de mémoire pour ne rien laisser au reste du cluster, ou créer assez d'objets pour ralentir l'API server pour tous les tenants — le même mécanisme qui est à l'œuvre dans le problème du noisy neighbor.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "10"
    requests.memory: 20Gi
    limits.cpu: "20"
    limits.memory: 40Gi
    pods: "50"
    count/deployments.apps: "20"

Cette dernière ligne compte autant que les limites de compute qui la précèdent. Un quota limité au compute laisse un namespace créer des Deployments, ConfigMaps ou Services sans limite, ce qui sature etcd et ralentit le control plane pour tous les autres tenants du cluster. Plafonner le nombre d'objets protège ce que tous les namespaces partagent.

Associez le quota à un LimitRange pour que les pods qui ne déclarent pas leurs propres requests et limits reçoivent des valeurs par défaut raisonnables au lieu d'être rejetés d'emblée, et fixez un maximum par conteneur afin qu'aucun pod ne puisse accaparer tout le budget du namespace. Pour la mécanique complète, y compris comment dimensionner les valeurs à partir de l'usage réel plutôt qu'au jugé, consultez le guide dédié aux ResourceQuotas et LimitRanges.