Kubernetes : Accès « Viewer » Facile pour Éviter les Catastrophes (et garder ses cheveux)

Ah, Kubernetes ! Le nouveau joujou, le Graal, le super-héros (ou le super-vilain, selon les jours) du monde DevOps. Dans mon quotidien professionnel, je passe beaucoup de temps à jongler avec ce monstre sacré. Et si c’est un outil incroyablement puissant, c’est aussi un outil qui peut… disons… causer des « incidents de parcours » si on ne fait pas attention.

La situation classique : un client (ou un collègue, soyons honnêtes) a besoin d’un accès à un cluster Kubernetes. Mais pas question de lui donner les clés du camion ! On veut qu’il puisse regarder, fouiller, inspecter… mais surtout pas toucher. Pas de kubectl delete intempestif, pas de apply malencontreux. Juste un accès « viewer », en toute sécurité.

On pourrait se lancer dans des configurations de RBAC complexes à faire pâlir un architecte système. Mais pour un besoin simple de visualisation, j’ai trouvé une méthode assez directe, élégante et rapide. Et aujourd’hui, je vous la partage pour vous éviter bien des maux de tête (et des remontées acides).

Le principe : un ServiceAccount « yeux seulement »

L’idée est de créer un ServiceAccount dédié, auquel on va attacher des permissions très limitées. Le but est de lui donner le droit de voir tout ce qui se passe sur le cluster, sans jamais pouvoir le modifier. Kubernetes a une chance de bien faire les choses, car il propose un ClusterRole parfait pour ça : view.

Voici le fichier de configuration Kubernetes pour mettre en place ce ServiceAccount et lui attribuer le rôle de « viewer ». Nous allons le nommer service-account-readonly-setup.yaml.

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: readonly-user
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: readonly-user
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: view
subjects:
- kind: ServiceAccount
  name: readonly-user
  namespace: kube-system
---
apiVersion: v1
kind: Secret
metadata:
  name: readonly-token
  namespace: kube-system
  annotations:
    kubernetes.io/service-account.name: readonly-user
type: kubernetes.io/service-account-token
---

Ce fichier fait 3 choses :

• il définit notre ServiceAccount nommé readonly-user dans le namespace kube-system
• il définit un ClusterRoleBinding qui va lier notre ServiceAccount readonly-user au ClusterRole view (pré-défini par Kubernetes). C’est ce ClusterRole qui confère les permissions de lecture seule sur l’ensemble du cluster.
• il génère un jeton (token) qui est stocké dans un Secret pour que notre readonly-user puisse s’authentifier

Maintenant que notre fichier YAML est prêt, on l’applique à notre cluster :

kubectl apply -f service-account-readonly-setup.yaml

Une fois appliqués, le ServiceAccount et le ClusterRoleBinding sont créés. Pour récupérer le token d’authentification, qui est la clé d’accès de notre utilisateur readonly-user, on va inspecter le Secret que nous venons de créer :

kubectl -n kube-system describe secret readonly-token

Dans la sortie de cette commande, vous trouverez une ligne token: suivie d’une longue chaîne de caractères. C’est votre bearer token. Gardez-le précieusement !

Le Kubeconfig pour l’utilisateur « viewer »

La dernière étape consiste à créer le fichier kubeconfig que vous pourrez fournir à votre client ou collègue. Ce fichier leur permettra d’accéder au cluster avec les permissions de notre readonly-user.

Remplacez <url>, <put the certificate auth data here> et <YOUR_BEARER_TOKEN> par les valeurs réelles de votre cluster et le token que vous avez récupéré.

apiVersion: v1
kind: Config
clusters:
- name: eks-cluster
  cluster:
    server: <url>
    certificate-authority-data: <put the certificate auth data here>
contexts:
- name: eks-context
  context:
    cluster: eks-cluster
    user: readonly-user
current-context: eks-context
users:
- name: readonly-user
  user:
    token: <YOUR_BEARER_TOKEN>

Et voilà ! Il ne vous reste plus qu’à distribuer ce fichier kubeconfig à vos utilisateurs. Quand ils utiliseront kubectl avec ce fichier, ils n’auront que des droits de lecture. Ils pourront lister les pods, les services, les déploiements… mais toute tentative de modification se soldera par un joli message d’erreur « Forbidden ».

C’est simple, c’est efficace, et ça vous évitera de veiller sur votre cluster comme sur la prunelle de vos yeux. Une petite victoire DevOps, ça se fête !

Alors, prêts à donner des accès sans donner les pleins pouvoirs ?