Introduction
L’authentification Kubernetes identifie l’appelant ; l’autorisation détermine ce que cette identité est habilitée à faire. Le RBAC exprime les autorisations sous forme d’actions appliquées à des ressources de l’API, puis les associe à des utilisateurs, des groupes ou des ServiceAccounts.
Vous allez créer un lecteur limité à un espace de noms, associer son identité aux autorisations correspondantes, puis vérifier, par usurpation d’identité, les limites entre les actions autorisées et celles qui sont refusées.
Le RBAC devient plus simple à comprendre si on le résume en trois questions : Qui ? (ServiceAccount), Que peut-il faire ? (Role) et À qui ces autorisations sont-elles accordées ? (RoleBinding). La création d’un seul ou de deux de ces objets ne suffit pas à établir toute la chaîne d’autorisation.
Créer une identité ServiceAccount
Dans cette étape, créez un ServiceAccount limité à un espace de noms pour un composant applicatif.
Un ServiceAccount est une identité de l’API Kubernetes destinée aux charges de travail et à l’automatisation. Il ne s’agit pas d’un utilisateur Linux à l’intérieur du conteneur. Attribuer à cet exemple une identité dédiée évite qu’il n’hérite du ServiceAccount default de l’espace de noms.
cd /home/labex/project/rbac-access
kubectl create serviceaccount inventory-reader -n practice-rbac
kubectl get serviceaccount inventory-reader -n practice-rbac -o yaml
Son identité complète est system:serviceaccount:practice-rbac:inventory-reader. La création d’une identité seule n’accorde aucune autorisation applicative.
Dans la sortie YAML, les métadonnées confirment l’espace de noms et le nom. Ne vous attendez pas à voir apparaître automatiquement un Secret contenant un jeton longue durée ; les versions modernes de Kubernetes injectent des jetons de courte durée dans les Pods lorsque cela est nécessaire.
L’objet retourné contient le nom et l’espace de noms dédiés, mais aucun Secret de jeton généré automatiquement :
kind: ServiceAccount
metadata:
name: inventory-reader
namespace: practice-rbac
Définir des autorisations limitées à l’espace de noms
Dans cette étape, créez un Role qui autorise uniquement la lecture des Pods et des ConfigMaps dans practice-rbac.
Chaque règle combine des groupes d’API, des ressources et des actions. Pour les ressources du groupe principal, comme les Pods et les ConfigMaps, apiGroups: [""] utilise une chaîne vide. Les actions get, list et watch correspondent respectivement à la lecture d’un objet, à la lecture d’une collection et au suivi des modifications.
cd /home/labex/project/rbac-access
cat <<'EOF' > inventory-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata: {name: inventory-reader, namespace: practice-rbac}
rules:
- apiGroups: [""]
resources: [pods, configmaps]
verbs: [get, list, watch]
EOF
Appliquez le Role, puis affichez sa description. La commande describe présente ses règles de sécurité sous forme de tableau, plus facile à examiner que le YAML brut :
kubectl apply -f inventory-role.yaml
kubectl describe role inventory-reader -n practice-rbac
Le groupe d’API vide sélectionne les ressources du groupe principal. Un Role n’accorde jamais d’accès en dehors de son espace de noms.
Remarquez également ce qui n’apparaît pas : il n’y a aucune action create, update, patch ou delete. Le principe du moindre privilège se définit autant par les autorisations omises que par celles qui sont accordées.
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
configmaps [] [] [get list watch]
pods [] [] [get list watch]
Le tableau développe la règle YAML combinée en une ligne par ressource. Les deux lignes comportent les trois mêmes actions, toutes en lecture seule.
Associer le Role à l’identité
Dans cette étape, reliez le Role au ServiceAccount à l’aide d’un RoleBinding.
La commande impérative est concise, car les deux objets existent déjà. --role désigne la source des autorisations, tandis que --serviceaccount utilise le format namespace:name pour identifier le sujet.
cd /home/labex/project/rbac-access
kubectl create rolebinding inventory-reader -n practice-rbac --role=inventory-reader --serviceaccount=practice-rbac:inventory-reader
kubectl get rolebinding inventory-reader -n practice-rbac -o yaml
roleRef désigne les autorisations ; subjects désigne les identités qui les reçoivent. Dans cet exemple, les deux restent limités à l’espace de noms.
Même si un Role et un ServiceAccount portent le même nom, ils restent indépendants tant que cette association n’existe pas. Les noms servent à s’y retrouver ; le RoleBinding constitue le véritable lien d’autorisation.
Dans le YAML, suivez le lien entre roleRef.name: inventory-reader et le sujet dont le type est ServiceAccount, le nom inventory-reader et l’espace de noms practice-rbac.
Tester les actions autorisées et refusées
Dans cette étape, utilisez kubectl auth can-i avec --as pour usurper l’identité du ServiceAccount.
Tester les autorisations nécessite des cas positifs et négatifs. Une réponse yes confirme que l’action requise est possible, tandis qu’une réponse no prouve que les opérations destructrices et l’accès entre espaces de noms n’ont pas été accordés par inadvertance.
cd /home/labex/project/rbac-access
IDENTITY=system:serviceaccount:practice-rbac:inventory-reader
kubectl auth can-i list pods -n practice-rbac --as="$IDENTITY"
kubectl auth can-i get configmaps -n practice-rbac --as="$IDENTITY"
kubectl auth can-i delete pods -n practice-rbac --as="$IDENTITY" || true
kubectl auth can-i list pods -n default --as="$IDENTITY" || true
Les deux premières réponses doivent être yes ; la suppression et l’énumération entre espaces de noms doivent renvoyer no. L’usurpation d’identité permet de tester l’autorisation sans exposer ni créer de jeton.
kubectl auth can-i renvoie un code d’état non nul au shell en même temps qu’une réponse no. Les deux suffixes || true permettent à ces tests de refus délibérés de poursuivre leur exécution ; ils ne modifient pas la décision d’autorisation.
yes
yes
no
no
Interprétez ces résultats comme deux capacités nécessaires suivies de deux limites protégées. Une série de tests contenant uniquement des réponses yes ne suffirait pas à démontrer le respect du principe du moindre privilège.
L’utilisateur actuel du laboratoire est autorisé à usurper l’identité de ce ServiceAccount à des fins de test. --as modifie l’identité évaluée par le serveur d’API pour cette commande ; il ne change pas l’utilisateur de votre shell et ne bascule pas définitivement les identifiants de kubectl.
Résumé
Vous avez créé un ServiceAccount, défini des autorisations de lecture limitées à un espace de noms avec un Role, les avez attribuées au moyen d’un RoleBinding, puis vérifié les actions autorisées et refusées par usurpation d’identité.
