TP : RBAC et NetworkPolicy

Ce que vous allez apprendre dans ce TP

• Donner un accès en lecture seule
• Vérifier les droits avec can-i
• Isoler des applications

RBAC #

Ce que vous allez apprendre dans cette section

• Donner un accès en lecture seule
• Vérifier les droits avec can-i
• Isoler des applications

Contexte. Par défaut, tout pod peut parler à tous les autres et le compte de service par défaut peut avoir plus de droits que nécessaire. Appliquer le moindre privilège (RBAC) et la segmentation réseau (NetworkPolicy) limite les dégâts en cas de compromission.

Prérequis : Cluster avec CNI compatible (Calico ou Cilium), kubectl  ·  Durée estimée : 50 min

Moindre privilège avec un ServiceAccount.

1. 1. Créer namespace et ServiceAccount

   Pourquoi ? Un ServiceAccount dédié permet de donner à une application uniquement les droits dont elle a besoin, au lieu du compte par défaut.

   Un namespace prod et un compte lecteur.

2. 2. Donner la lecture des pods

   Pourquoi ? can-i prouve concrètement ce qui est autorisé ou refusé : on vérifie le principe du moindre privilège au lieu de le supposer.

   Créez un Role et un RoleBinding, puis testez avec can-i.

NetworkPolicy #

Interdire par défaut puis autoriser.

1. 3. Tout interdire

   Pourquoi ? Une politique « tout interdire » est le point de départ d'une segmentation : on autorise ensuite uniquement ce qui est nécessaire.

   Appliquez une politique deny-all (CNI compatible : Calico ou Cilium).

2. 4. Autoriser uniquement un client

   Pourquoi ? Autoriser un seul client puis tester les deux cas (autorisé, refusé) prouve que la règle est bien appliquée par le CNI.

   Autorisez les pods role=client à joindre web.

Niveau de difficulté : ●●●○○ (3/5)