Lab 04 : Gestion des RBAC et des Kubeconfigs personnalisés sur OKS

Dans ce TP, vous allez apprendre à utiliser l’outil OKS CLI pour gérer l’accès à un cluster Kubernetes. Vous découvrirez comment créer des utilisateurs, attribuer des rôles via RBAC (Role-Based Access Control) et générer des kubeconfigs sécurisés pour gérer l’accès à des ressources Kubernetes de manière fine. Nous couvrirons aussi la sécurisation des kubeconfigs via le chiffrement.

Prérequis

Avoir un accès à un cluster Kubernetes via OKS.
L’outil OKS CLI installé et configuré.
Un projet dans OKS avec des permissions suffisantes pour créer des rôles et générer des kubeconfigs.

Vérifier l’accès au cluster

Assurez-vous d’avoir les permissions nécessaires pour accéder au cluster cible. Vous devez disposer d’un utilisateur ou d’un rôle qui vous permet d’exporter ou de récupérer la configuration du cluster.

Récupérer le fichier kubeconfig

oks-cli cluster kubeconfig --cluster-name my-cluster --project-name my-project > kubeconfig.yaml
export KUBECONFIG=./kubeconfig.yaml

Tester le cluster

kubectl get nodes

Partie 1 : Préparation des rôles avec RBAC

Dans cette section, nous allons créer des rôles avec différentes permissions pour accorder des accès au cluster en fonction des besoins des utilisateurs.

1.1 Créer un rôle `namespace-admin`

Le rôle namespace-admin accordera un accès complet à un namespace spécifique. Cela peut être utile pour les administrateurs de namespaces qui doivent gérer toutes les ressources au sein d’un namespace particulier.

Avant tout, nous allons créer le namespace dev dans lequel nous allons travailler.

Soit directement en ligne de commande (mode impératif)

kubectl create namespace dev`
namespace/dev created

soit de manière décalarative via un fichier ns-dev.yaml comme ceci:

apiVersion: v1
kind: Namespace
metadata:
  name: dev

kubectl apply -f ns-dev.yaml

Ensuite, créez un fichier YAML pour définir un rôle namespace-admin et un RoleBinding dans un namespace appelé dev.

# ServiceAccount
apiVersion: v1
kind: ServiceAccount
metadata:
  name: namespace-admin
  namespace: dev

---
# Role (avec toutes les permissions dans le namespace)
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: namespace-admin-role
  namespace: dev
rules:
  - apiGroups: ["*"]
    resources: ["*"]
    verbs: ["*"]

---
# RoleBinding (lié au ServiceAccount)
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: namespace-admin-binding
  namespace: dev
subjects:
- kind: Group
  name: namespace-admin
  namespace: dev
roleRef:
  kind: Role
  name: namespace-admin-role
  apiGroup: rbac.authorization.k8s.io

Appliquez ce manifeste à votre cluster avec la commande suivante :

kubectl apply -f namespace-admin-role.yaml

Cela crée un rôle qui accorde un accès complet (*) à toutes les ressources dans le namespace dev et le lie au groupe namespace-admin.

On vérifie que tout les objets ont bien été crée

kubectl get role,rolebindings,sa --namespace dev
NAME                                                  CREATED AT
role.rbac.authorization.k8s.io/namespace-admin-role   2025-06-16T13:44:08Z

NAME                                                            ROLE                        AGE
rolebinding.rbac.authorization.k8s.io/namespace-admin-binding   Role/namespace-admin-role   65s

NAME                             SECRETS   AGE
serviceaccount/default           0         3m4s
serviceaccount/namespace-admin   0         94s

Pour la suite du TP, nous allons lancer un pod nginx dans le namespace dev, nous y reviendrons plus tard.

kubectl run nginx --image=nginx --namespace dev
pod/nginx created

1.2 Créer un rôle `readonly-users`

Le rôle readonly-users sera utilisé pour accorder un accès en lecture seule à toutes les ressources du cluster.

Créez un fichier YAML pour définir un ClusterRole readonly et un ClusterRoleBinding pour le groupe readonly-users.

# ClusterRole (en lecture seule)
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: readonly
  labels:
    app.kubernetes.io/name: readonly
    app.kubernetes.io/part-of: rbac-system
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["get", "list", "watch"]

---
# ClusterRoleBinding (lié au groupe readonly-users)
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: readonly-binding
  labels:
    app.kubernetes.io/name: readonly-binding
    app.kubernetes.io/part-of: rbac-system
subjects:
- kind: Group
  name: readonly-users
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: readonly
  apiGroup: rbac.authorization.k8s.io

Appliquez ce manifeste à votre cluster :

kubectl apply -f readonly-role.yaml

Cela permet d’accorder un accès en lecture seule à toutes les ressources dans le cluster pour les utilisateurs du groupe readonly-users.

Partie 2 : Génération des kubeconfig pour les utilisateurs

Une fois les rôles créés, nous devons générer des fichiers kubeconfig pour chaque groupe d’utilisateurs afin qu’ils puissent accéder au cluster avec les permissions appropriées.

2.1 Générer un kubeconfig pour le groupe `namespace-admin`

Pour accorder un accès au groupe namespace-admin, générez un kubeconfig qui contient les informations d’authentification et les permissions nécessaires.

oks-cli cluster kubeconfig --cluster-name my-cluster --project-name my-project --group "namespace-admin" --refresh > namespace-admin-kubeconfig.yaml

Cette commande génère un kubeconfig pour le groupe namespace-admin et le met à jour avec les permissions du rôle namespace-admin dans le namespace dev.

Nous allons tester que le groupe namespace-admin a bien un accès à toutes les ressources du namespace dev, et pas aux autres namespaces.

Commençons par utiliser le fichier de configuration pour accéder au cluster en tant qu’utilisatuer du groupe namespace-admin

export KUBECONFIG=./namespace-admin-kubeconfig.yaml

Testons que nous pouvons créer un nouveau pod avec notre rôle namespace-admin

kubectl run nginx2 --image=nginx --namespace dev
pod/nginx2 created

Maintenant, listons par exemple les pods du namespace dev, nous devrions voir notre pod nginx crée un peu plus tôt lors de la création du role namespace-admin et le nouveau nginx2

kubectl get pods --namespace dev
NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          23m
nginx2  1/1     Running   0          1m

Testons désormais le fait que nous ne puissions pas créer/lister quoi que ce soit dans une autre namespace, par exmple le namespace default

kubectl get pods --namespace default
Error from server (Forbidden): pods is forbidden: User "kube-user" cannot list resource "pods" in API group "" in the namespace "default"

C’est bien le résultat attendu, notre rôle ne nous donne accès qu’au namespace dev et aucun autre.

2.2 Générer un kubeconfig pour le groupe `readonly-users`

De manière similaire, générez un kubeconfig pour les utilisateurs du groupe readonly-users pour leur permettre d’accéder en lecture seule au cluster.

oks-cli cluster kubeconfig --cluster-name my-cluster --project-name my-project --group "readonly-users" --user user1 --ttl 2592000  > readonly-users-kubeconfig.yaml

Cette commande génère un kubeconfig pour le groupe readonly-users et le met à jour avec les permissions en lecture seule.

Nous allons désormais tester que nous pouvons avoir accès en lecture seule (read-only) à toutes les ressources du cluster, mais pas à la création de ressources kubernetes.

Commençons par utiliser le fichier de configuration pour accéder au cluster en tant qu’utilisatuer du groupe readonly-users

export KUBECONFIG=./readonly-users-kubeconfig.yaml

Commencons par lister, par exemple la liste de noeuds du cluster

kubectl get nodes
NAME              STATUS   ROLES    AGE   VERSION
ip-10-50-102-69   Ready    <none>   27d   v1.31.2
ip-10-50-62-80    Ready    <none>   27d   v1.31.2
ip-10-50-90-105   Ready    <none>   27d   v1.31.2

Voyons si nous pouvons lister les pods présents dans le namespace kube-system

kubectl get pods -n kube-system
 kubectl get pods -n kube-system
NAME                                  READY   STATUS    RESTARTS      AGE
cilium-548fj                          1/1     Running   0             27d
cilium-envoy-6jw85                    1/1     Running   0             27d
cilium-envoy-82kvq                    1/1     Running   0             27d
cilium-envoy-97qvx                    1/1     Running   0             27d
cilium-n75s9                          1/1     Running   0             27d
cilium-operator-5d59c9cd6d-j7g9v      1/1     Running   0             27d
cilium-z7kpt                          1/1     Running   0             27d
coredns-5658776d8b-gdf7p              1/1     Running   0             27d
coredns-5658776d8b-lff49              1/1     Running   0             27d
imds-provider-ip-10-50-102-69         1/1     Running   0             27d
imds-provider-ip-10-50-62-80          1/1     Running   0             27d
imds-provider-ip-10-50-90-105         1/1     Running   0             27d
konnectivity-agent-655br              1/1     Running   0             6d
konnectivity-agent-b6hbf              1/1     Running   0             27d
konnectivity-agent-gs4m7              1/1     Running   0             27d
konnectivity-agent-ldqzc              1/1     Running   0             6d
konnectivity-agent-wlnp8              1/1     Running   0             6d
konnectivity-agent-wp29w              1/1     Running   0             27d
metrics-server-56478ff848-q7w4v       1/1     Running   0             27d
osc-csi-node-bbdsj                    3/3     Running   0             27d
osc-csi-node-l25dn                    3/3     Running   1 (27d ago)   27d
osc-csi-node-mx75h                    3/3     Running   0             27d
snapshot-controller-9c8bd95c5-8f9rw   1/1     Running   0             27d
snapshot-controller-9c8bd95c5-cmp24   1/1     Running   0             27d

Essayez de créer un pod dans le namespace default

kubectl run nginx --image=nginx --namespace default
Error from server (Forbidden): pods is forbidden: User "kube-user" cannot create resource "pods" in API group "" in the namespace "default"

Le résultat obtenu est bien celui attendu, notre rôle readonly-users nous permet uniquement de list/voir les ressources du cluster tout entier, mais aucunement de créer quelque ressource que ce soit.

Partie 3 : Sécurisation des kubeconfig avec chiffrement

Pour renforcer la sécurité, vous pouvez chiffrer les kubeconfigs afin de prévenir les attaques de type Man-in-the-Middle (MitM) et garantir que seules les personnes autorisées puissent accéder aux informations sensibles.

3.1 Générer un kubeconfig chiffré

Pour chiffrer un kubeconfig, vous pouvez utiliser l’option --nacl avec la commande oks-cli cluster kubeconfig.

oks-cli cluster kubeconfig --cluster-name my-cluster --project-name my-project --user USER2   --nacl

--nacl : Cette option garantit que votre kubeconfig est récupéré en utilisant le chiffrement par clé publique pendant la transmission.

Conclusion

Dans ce TP, vous avez appris à utiliser OKS CLI pour gérer les accès à un cluster Kubernetes via RBAC. Vous avez créé des rôles comme namespace-admin et readonly-users, et vous avez généré des kubeconfigs pour permettre un accès contrôlé aux utilisateurs. Vous avez également appris à sécuriser vos kubeconfigs en les chiffrant pour éviter les risques liés aux attaques de type Man-in-the-Middle.

Ce processus vous permet de gérer les permissions avec une granularité fine et de protéger l’accès à vos clusters Kubernetes de manière efficace et sécurisée.