📍 Article principal : CKA depuis l’Afrique de l’Ouest. Ce tutoriel maîtrise RBAC et NetworkPolicy en profondeur, deux domaines qui pèsent ensemble près de 35 % du score d’examen CKA.
RBAC et NetworkPolicy sont les piliers de la sécurité Kubernetes. Le RBAC contrôle qui peut faire quoi sur le cluster — quel utilisateur lit quels namespaces, quel ServiceAccount déploie quels manifests, quel groupe administre quels nodes. NetworkPolicy contrôle quels pods peuvent communiquer avec quels autres — isolation réseau fine au niveau du cluster. Ces deux mécanismes apparaissent systématiquement à l’examen via plusieurs tâches concrètes. Ce tutoriel détaille chaque concept avec exemples pratiques, exercices types CKA, et solutions commentées.
Prérequis
- Cluster Kubernetes fonctionnel (voir tutoriel kubeadm Hetzner)
- Notions kubectl de base
- CNI supportant NetworkPolicy (Calico, Cilium recommandés)
- Niveau : avancé
- Temps estimé : 4 à 5 heures
Étape 1 — Comprendre RBAC : Role, ClusterRole, RoleBinding, ClusterRoleBinding
Le RBAC Kubernetes repose sur quatre objets. Role définit un ensemble de permissions limitées à un namespace — par exemple lire les pods et services dans le namespace finance. ClusterRole définit les mêmes permissions mais à l’échelle du cluster — par exemple lire tous les nodes ou tous les namespaces. RoleBinding associe un Role à un sujet (utilisateur, groupe ou ServiceAccount) dans un namespace. ClusterRoleBinding associe un ClusterRole à un sujet à l’échelle du cluster.
La règle pratique pour la CKA : utiliser Role+RoleBinding pour les permissions limitées à un namespace, ClusterRole+ClusterRoleBinding pour les permissions cluster-wide. Combinaison hybride possible mais piège classique : ClusterRole+RoleBinding qui donne les permissions du ClusterRole limitées au namespace du RoleBinding. Cette nuance est testée à l’examen via des questions où il faut limiter un ClusterRole à un seul namespace.
Étape 2 — Créer un Role et un RoleBinding pas à pas
Exercice typique CKA : créer un Role pod-reader dans le namespace finance qui peut uniquement lister les pods, et l’attribuer à un utilisateur jane.
kubectl create role pod-reader \ --verb=get,list,watch --resource=pods \ -n finance --dry-run=client -o yaml > role.yaml kubectl apply -f role.yaml kubectl create rolebinding jane-pod-reader \ --role=pod-reader --user=jane \ -n finance --dry-run=client -o yaml > rb.yaml kubectl apply -f rb.yaml
Vérifier les permissions avec kubectl auth can-i list pods --as=jane -n finance qui doit retourner yes, et kubectl auth can-i list pods --as=jane -n marketing qui doit retourner no. Cette vérification est cruciale : à l’examen, vérifier systématiquement les permissions après création.
Étape 3 — ServiceAccount et automountServiceAccountToken
Pour les pods qui interagissent avec l’API Kubernetes (opérateurs, controllers custom, applications cloud-native), utiliser un ServiceAccount dédié au lieu du ServiceAccount par défaut. Créer le ServiceAccount : kubectl create serviceaccount monitoring -n monitoring. Lui attacher un Role ou ClusterRole via RoleBinding ou ClusterRoleBinding. Référencer ensuite ce ServiceAccount dans le manifeste pod via spec.serviceAccountName: monitoring.
Pour les pods qui n’ont pas besoin d’accéder à l’API, désactiver explicitement l’automount du token avec spec.automountServiceAccountToken: false. Cette pratique réduit la surface d’attaque — un pod compromis ne peut pas utiliser un token Kubernetes pour escalader. Question type CKA : créer un pod avec un ServiceAccount spécifique et désactiver le mount du token sauf si nécessaire.
Étape 4 — NetworkPolicy : isoler un namespace
Les NetworkPolicy contrôlent les communications réseau entre pods via des règles ingress et egress. Par défaut, sans NetworkPolicy, tout pod peut communiquer avec tout autre pod du cluster — politique permissive risquée en production. Créer une NetworkPolicy default-deny dans un namespace bloque tout trafic, puis on ajoute des NetworkPolicy autorisant explicitement les flux nécessaires.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
namespace: finance
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
Cette policy de base bloque tout — aucun trafic n’entre ni ne sort du namespace finance. Tester immédiatement : déployer un pod et essayer un curl vers un autre pod, l’opération échoue. Ajouter ensuite les règles spécifiques : autoriser le trafic depuis le namespace frontend vers les pods avec label tier: backend dans finance, autoriser le DNS vers kube-system.
Étape 5 — NetworkPolicy avec sélecteurs combinés
Question CKA fréquente : autoriser le trafic depuis un pod label spécifique d’un namespace label spécifique vers un pod label spécifique d’un autre namespace. La syntaxe combine podSelector et namespaceSelector dans la même règle from.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-frontend-to-backend
namespace: finance
spec:
podSelector:
matchLabels:
tier: backend
policyTypes: [Ingress]
ingress:
- from:
- namespaceSelector:
matchLabels:
name: frontend
podSelector:
matchLabels:
app: web
ports:
- protocol: TCP
port: 8080
Le piège classique : la combinaison namespaceSelector et podSelector dans la même règle from signifie ET (le pod doit être à la fois dans le namespace ET avoir le label). Si on les met dans des règles from séparées, c’est OU. Cette nuance fait perdre des points à l’examen — bien lire la question pour identifier la sémantique attendue.
Étape 6 — Tests et validation des règles
À l’examen comme en production, valider chaque règle créée. Pour RBAC : kubectl auth can-i <verb> <resource> --as=<user> -n <namespace> teste exhaustivement. Pour NetworkPolicy : déployer un pod test, exécuter kubectl exec -it pod -- curl <service>, vérifier que le résultat correspond à l’attente. Si la règle bloque alors qu’elle devait autoriser, vérifier dans l’ordre : le CNI supporte-t-il NetworkPolicy (Calico oui, Flannel non sans extension), les labels des pods et namespaces correspondent-ils exactement, la syntaxe ET vs OU.
Pour le debug, l’outil cilium connectivity test ou calicoctl proposent des analyses détaillées qui montrent quelles policies s’appliquent à un pod donné. Ces outils ne sont pas disponibles à l’examen mais leur usage en pratique forme l’intuition pour résoudre les problèmes en mode commande pure.
Étape 7 — Patterns courants à mémoriser
Cinq patterns RBAC reviennent fréquemment à l’examen. Premier : utilisateur readonly sur tout le cluster — ClusterRole view existant + ClusterRoleBinding. Deuxième : admin limité à un namespace — Role admin custom + RoleBinding. Troisième : ServiceAccount qui peut créer des Pods uniquement dans son namespace — Role + RoleBinding sur le ServiceAccount. Quatrième : groupe LDAP qui a les droits de lecture cluster-wide — ClusterRole + ClusterRoleBinding sur le groupe. Cinquième : utilisateur qui peut lister les nodes mais pas les modifier — ClusterRole get/list/watch sur nodes + ClusterRoleBinding.
Cinq patterns NetworkPolicy à mémoriser. Premier : default-deny ingress et egress dans un namespace. Deuxième : autoriser uniquement le trafic interne au namespace. Troisième : autoriser depuis un namespace spécifique vers un pod label. Quatrième : autoriser le DNS sortant vers kube-system. Cinquième : autoriser un port spécifique depuis tout le cluster. Pratiquer ces patterns jusqu’à pouvoir écrire le YAML de mémoire — gain de temps massif à l’examen.
Aggregated ClusterRoles et héritage
Une fonctionnalité avancée RBAC à connaître pour la CKA : les ClusterRoles agrégés. Un ClusterRole peut être marqué avec un label spécifique et les ClusterRoles agrégeurs incluent automatiquement les permissions de tous les ClusterRoles avec ce label. Mécanisme utilisé par Kubernetes lui-même pour les rôles standards (admin, edit, view, cluster-admin) qui s’enrichissent automatiquement quand on ajoute un nouveau type de ressource au cluster.
Pour une question CKA type, étendre les permissions du rôle admin standard pour inclure les CustomResourceDefinitions sans modifier directement le rôle système. Créer un nouveau ClusterRole avec le label rbac.authorization.k8s.io/aggregate-to-admin: "true" et les permissions sur le CRD — automatiquement intégré au rôle admin agrégé. Cette technique reste compatible aux upgrades Kubernetes contrairement à la modification directe des rôles système.
Audit et traçabilité RBAC
Au-delà de la création des règles, savoir auditer un cluster existant est précieux. La commande kubectl auth can-i --list --as=<user> -n <namespace> liste toutes les permissions effectives d’un utilisateur dans un namespace. Pour aller plus loin, l’outil rbac-tool de InsightAi génère un rapport visuel complet de la structure RBAC d’un cluster — qui peut faire quoi, quels rôles sont sur-privilégiés, quels comptes ne sont pas utilisés. Cet outil n’est pas testé à l’examen mais sa connaissance fait gagner des heures lors d’audits réels.
Pour la traçabilité des actions effectuées, configurer l’audit logging Kubernetes via une politique d’audit appliquée à l’API server. Chaque appel API est journalisé selon les règles définies — utilisateur, action, ressource, namespace, code retour. Ces logs partent vers fluent-bit puis Loki ou Elasticsearch pour la consultation. Question CKA possible : configurer une policy d’audit pour journaliser les modifications de ConfigMaps en mode RequestResponse.
Erreurs fréquentes
| Erreur | Cause | Solution |
|---|---|---|
| Permission accordée à tort à un namespace | ClusterRole+ClusterRoleBinding au lieu de RoleBinding | Utiliser ClusterRole+RoleBinding pour limiter au namespace |
| NetworkPolicy ignorée | CNI non compatible | Vérifier que Calico ou Cilium est installé |
| Pod non isolé malgré NetworkPolicy | policyTypes: [Ingress] sans Egress | Spécifier les deux types selon le besoin |
| RoleBinding ne fonctionne pas | Mauvais kind dans subjects (User vs ServiceAccount) | Vérifier le kind correspond exactement au type de sujet |
Adaptation au contexte ouest-africain
Pour les ingénieurs ouest-africains qui passent la CKA dans le but de travailler sur des clusters multi-tenants (banques, fintechs, prestataires de services), la maîtrise fine de RBAC et NetworkPolicy devient un argument commercial décisif. Les clients institutionnels exigent des isolations strictes entre équipes et entre environnements. Pouvoir auditer un cluster existant et identifier les failles RBAC ou NetworkPolicy ouvre des missions de conseil bien rémunérées (3 à 8 millions XOF par audit selon la taille). Cette compétence dépasse donc le simple passage de la certification — elle alimente directement la trajectoire commerciale.
Migration depuis Calico vers Cilium
Pour les apprenants qui veulent aller au-delà de la CKA, considérer une migration vers Cilium qui apporte des fonctionnalités modernes basées sur eBPF. Cilium implémente NetworkPolicy avec des performances supérieures à Calico (latence et throughput améliorés de 30 à 50 % sur les benchmarks récents). Cilium ajoute aussi les CiliumNetworkPolicy qui étendent la spec Kubernetes standard avec des règles L7 (HTTP, gRPC, Kafka) — au-delà du simple filtrage L3/L4.
La migration se fait via un opérateur Cilium qui prend le relais une fois Calico désactivé. Procédure : drainer les workers, supprimer les manifests Calico, déployer Cilium via Helm ou manifests, valider la connectivité. Cette migration apparaît rarement à l’examen CKA mais constitue un excellent exercice pour les profils visant CKS ou postes Senior. Pour les déploiements en production réels, Cilium est désormais le choix par défaut sur GKE Dataplane V2 et de nombreux clusters managés modernes.
Pod Security Admission au-delà du RBAC
Depuis Kubernetes 1.25, le Pod Security Admission a remplacé le PodSecurityPolicy déprécié. Trois profils de sécurité sont disponibles : privileged (aucune restriction), baseline (interdit les pratiques connues comme dangereuses), restricted (sécurité maximale, recommandé pour la production). L’application se fait par label sur le namespace : kubectl label ns finance pod-security.kubernetes.io/enforce=restricted. Les pods qui ne respectent pas le profil sont rejetés à la création.
Le Pod Security Admission complète RBAC. RBAC contrôle qui peut faire quoi, le PSA contrôle quels types de pods peuvent être créés indépendamment de l’utilisateur. Combinaison défensive : même un utilisateur cluster-admin ne peut pas créer un pod privileged dans un namespace marqué restricted. Cette défense en profondeur prévient les escalades latérales en cas de compromission d’un compte privilégié. Sujet probable au CKS plus qu’au CKA, mais sa connaissance distingue immédiatement un candidat sérieux.
NetworkPolicy egress et résolution DNS
Une question piège classique sur NetworkPolicy egress : bloquer tout egress empêche aussi la résolution DNS, ce qui casse toutes les communications par nom. Pour autoriser uniquement le DNS sortant, créer une règle egress vers le namespace kube-system port 53 UDP et TCP. Cette règle doit accompagner toute policy egress restrictive. À l’examen, une question piège peut imposer une isolation egress sans casser le DNS — penser systématiquement à autoriser kube-system:53.
Pour aller plus loin, autoriser uniquement le service kube-dns spécifiquement et pas l’ensemble du namespace kube-system, via combinaison namespaceSelector + podSelector pointant vers le pod CoreDNS. Cette précision est testée à l’examen sur les questions de NetworkPolicy avancée et démontre une compréhension fine des sélecteurs.
La maîtrise simultanée de RBAC, NetworkPolicy et Pod Security Admission constitue la trinité sécuritaire moderne de Kubernetes que tout administrateur certifié doit pouvoir mobiliser pour protéger les déploiements de production.
OPA Gatekeeper et Kyverno pour l’avenir
Au-delà des mécanismes natifs Kubernetes, deux outils complètent l’arsenal sécuritaire : Open Policy Agent Gatekeeper et Kyverno. Tous deux implémentent des politiques d’admission qui rejettent les manifests non conformes avant leur création — par exemple interdire les images sans tag spécifique ou imposer des labels obligatoires sur tout pod. OPA Gatekeeper utilise Rego comme langage de politique tandis que Kyverno utilise du YAML natif Kubernetes plus accessible.
Pour les déploiements de production réels, ces outils complètent RBAC et NetworkPolicy avec une couche de validation déclarative. Ils ne sont pas testés à l’examen CKA mais leur connaissance est attendue dans les missions DevOps senior. Investir quelques heures de pratique sur Kyverno après la CKA construit une compétence différenciante précieuse pour les profils ouest-africains qui visent le haut du marché freelance ou les postes de Lead DevOps.
Pour aller plus loin
🔝 Retour à l’article principal : CKA depuis l’Afrique de l’Ouest. Tutoriel précédent : déployer un cluster kubeadm sur Hetzner. Documentation officielle Kubernetes RBAC : kubernetes.io/docs/reference/access-authn-authz/rbac, NetworkPolicy : kubernetes.io/docs/concepts/services-networking/network-policies.
RBAC et NetworkPolicy ne sont pas seulement des sujets d’examen — ce sont les fondations de la sécurité Kubernetes en production. Un cluster sans RBAC propre et sans NetworkPolicy structurée est une bombe à retardement, exposée aux escalades latérales et aux compromissions massives. Maîtriser ces deux mécanismes au-delà de l’examen positionne l’ingénieur certifié comme un opérateur sérieux capable de protéger durablement les actifs numériques de la PME ou de l’organisation qui l’emploie.