Quelles sont les bases de la sécurité Kubernetes (RBAC et politiques réseau) ?
Réponse courte
Le RBAC contrôle ce que les identités peuvent faire sur l'API Kubernetes — les Roles et ClusterRoles accordent des verbes sur des ressources, liés à des sujets via des RoleBindings — et doit suivre le moindre privilège, en évitant cluster-admin et les wildcards. Les politiques réseau contrôlent le trafic pod-à-pod, qui est autorisé par défaut jusqu'à ce que vous appliquiez un default-deny puis permettiez explicitement les flux requis. Ensemble, ils limitent le rayon d'impact si un pod ou un jeton est compromis.
Kubernetes est ouvert par défaut — permissions larges et réseau plat — donc la sécurité est quelque chose que vous devez ajouter. Les deux contrôles fondamentaux sont le RBAC et les politiques réseau, et une bonne réponse explique à la fois le mécanisme et le comportement par défaut qui piège les gens.
RBAC : qui peut toucher à l'API
Tout dans Kubernetes passe par le serveur d'API, donc contrôler l'accès à l'API est primordial.
- Roles / ClusterRoles définissent un ensemble de verbes autorisés (
get,list,create,delete) sur des ressources (pods, secrets). Les Roles sont limités à un namespace ; les ClusterRoles s'appliquent à tout le cluster. - RoleBindings / ClusterRoleBindings attachent ces rôles à des sujets — utilisateurs, groupes ou comptes de service.
- Moindre privilège : évitez de lier quoi que ce soit à
cluster-admin, évitez les verbes/ressources avec wildcard, et donnez au compte de service de chaque charge de travail uniquement ce dont il a besoin. Un pod qui peut lire tous lessecretsest un chemin d'élévation sérieux s'il est compromis.
Politiques réseau : qui peut parler à qui
Par défaut, n'importe quel pod peut joindre n'importe quel autre pod — un réseau plat, tout-autorisé. Un pod compromis peut scanner et pivoter librement.
- Appliquez une politique default-deny dans un namespace, puis ajoutez des règles ingress/egress explicites n'autorisant que les flux dont votre application a réellement besoin (par ex. frontend vers backend sur un port).
- Avertissement crucial : les politiques réseau sont appliquées par le plugin CNI. Si votre CNI ne les prend pas en charge (ou si vous supposez qu'un default no-op le fait), la politique ne fait silencieusement rien — une raison courante pour qu'une règle « deny » paraisse ignorée.
Ce que recherchent les recruteurs
Séparer le RBAC (autorisation API) des politiques réseau (segmentation du trafic), connaître les deux comportements par défaut (RBAC large, réseau tout-autorisé), et la dépendance au CNI qui rend les politiques réseau inopérantes sans prise en charge.
Questions de suivi probables
- Pourquoi le trafic pod-à-pod est-il autorisé par défaut, et comment le basculer en default-deny ?
- Quel est le risque de lier un compte de service à cluster-admin ?
- Pourquoi une NetworkPolicy que vous avez appliquée pourrait-elle n'avoir aucun effet ?