Kubernetes 007 – API Server : authentification et autorisations

TL;DR

Dans Kubernetes, presque tout passe par l’API Server. Avant d’accepter une action, Kubernetes doit identifier le demandeur, verifier ses droits, appliquer d’eventuelles admissions, puis persister l’objet. RBAC permet de controler finement qui peut faire quoi.

La video de reference

Video: https://www.youtube.com/watch?v=m6utysX-zN8

Elle complete l’architecture en abordant la securite d’acces au cluster.

Le role de l’API Server

kube-apiserver expose l’API Kubernetes. kubectl, les controleurs et de nombreux outils passent par lui. C’est donc un point critique: une mauvaise configuration d’acces peut donner trop de droits ou bloquer des usages legitimes.

Authentification puis autorisation

L’authentification repond a la question: qui fait la requete ? L’autorisation repond ensuite: cette identite a-t-elle le droit de faire cette action sur cette ressource ?

Kubernetes supporte plusieurs mecanismes d’authentification. Pour l’autorisation, RBAC est le modele le plus courant avec Role, ClusterRole, RoleBinding et ClusterRoleBinding.

Commandes utiles

kubectl auth can-i get pods
kubectl auth can-i create deployments
kubectl get roles,rolebindings -A
kubectl get clusterroles,clusterrolebindings

Ces commandes aident a comprendre les droits effectifs.

Liens utiles

• Video: https://www.youtube.com/watch?v=m6utysX-zN8
• Controle d’acces API: https://kubernetes.io/docs/concepts/security/controlling-access/
• RBAC: https://kubernetes.io/docs/reference/access-authn-authz/rbac/
• API Server: https://kubernetes.io/docs/concepts/overview/kubernetes-api/

FAQ

RBAC sert-il a authentifier ?

Non. RBAC sert a autoriser. L’authentification identifie d’abord l’utilisateur ou le service account.

Quelle commande teste mes droits ?

kubectl auth can-i est la commande la plus directe.

Les droits sont-ils toujours limites a un namespace ?

Pas toujours. Role est namespaced, ClusterRole peut couvrir tout le cluster.

La chaine de controle d’une requete

Quand une requete arrive sur l’API Server, elle traverse plusieurs etapes. D’abord, Kubernetes cherche a authentifier l’appelant. Ensuite, il verifie si cette identite est autorisee a effectuer l’action. Puis des mecanismes d’admission peuvent valider, refuser ou modifier l’objet. Enfin seulement, l’objet est persiste.

Cette chaine explique pourquoi deux erreurs proches peuvent avoir des causes differentes. Une erreur d’authentification signifie que Kubernetes ne sait pas qui vous etes. Une erreur d’autorisation signifie qu’il vous connait, mais refuse l’action.

Lire une erreur RBAC

Une erreur typique ressemble a: User cannot list resource pods in API group "" in the namespace default. Elle contient plusieurs informations utiles: l’identite, le verbe, la ressource, le groupe API et le namespace.

On peut tester explicitement:

kubectl auth can-i list pods -n default
kubectl auth can-i create deployments -n default
kubectl auth can-i get secrets -A

Role, ClusterRole et bindings

Un Role definit des permissions dans un namespace. Un ClusterRole definit des permissions a l’echelle cluster ou reutilisables dans plusieurs namespaces. Un RoleBinding attache un role a une identite dans un namespace. Un ClusterRoleBinding attache un ClusterRole globalement.

La distinction est cruciale: donner trop facilement un ClusterRoleBinding peut ouvrir des droits sur tout le cluster.

Erreurs frequentes

• Donner cluster-admin pour aller vite.
• Confondre service account et utilisateur humain.
• Modifier un role sans verifier les verbs exacts (get, list, watch, create, update, delete).
• Oublier le namespace dans les tests can-i.

A retenir

La securite Kubernetes commence par l’API Server. Chaque outil qui gere le cluster passe par lui. Savoir lire RBAC et tester ses droits evite beaucoup de diagnostics approximatifs.

Exemple minimal de Role

Un Role peut donner le droit de lire les pods dans un namespace donne:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: lecteur-pods
  namespace: default
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]

Ce role ne donne pas le droit de creer, modifier ou supprimer des pods. Il ne donne pas non plus de droits sur les secrets, les deployments ou les ressources d’un autre namespace. Cette granularite est la force de RBAC.

Exemple de RoleBinding

Pour que le role serve a quelque chose, il faut l’attacher a une identite:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: lecteur-pods-binding
  namespace: default
subjects:
  - kind: ServiceAccount
    name: demo
    namespace: default
roleRef:
  kind: Role
  name: lecteur-pods
  apiGroup: rbac.authorization.k8s.io

On separe volontairement la definition des droits et leur attribution. Cela permet de reutiliser des roles, de relire plus facilement les permissions et d’eviter des configurations trop implicites.

Methode de diagnostic RBAC

Face a une erreur d’autorisation, il faut avancer dans l’ordre:

• identifier l’utilisateur ou le service account mentionne dans l’erreur;
• relever le verbe refuse: get, list, create, update, delete;
• relever la ressource et le groupe API;
• verifier le namespace;
• tester avec kubectl auth can-i;
• chercher le RoleBinding ou ClusterRoleBinding correspondant.

Cette methode est plus fiable que d’ajouter des droits au hasard. Elle limite aussi le risque classique: donner beaucoup trop de privileges pour resoudre vite un blocage ponctuel.

Notions et definitions

• Control plane: ensemble des composants qui exposent l’API et prennent les decisions.
• Worker node: machine qui execute les pods applicatifs.
• Runtime et kubelet: briques locales responsables du lancement et du suivi des conteneurs.

Ces definitions donnent le vocabulaire minimal pour suivre l’article sans reduire Kubernetes a une simple commande. Chaque notion doit etre reliee a un objet visible avec kubectl ou a un composant du cluster.

Exemple concret

Dans un cluster kubeadm, l’API Server recoit les manifests, le scheduler choisit un noeud, puis le kubelet demande au runtime de lancer les conteneurs.

Cet exemple sert de fil conducteur: il montre quel probleme operationnel Kubernetes cherche a resoudre et quelle ressource permet de le formaliser.

How-to rapide

• Verifier les prerequis systeme: swap, modules kernel, runtime, reseau.
• Initialiser ou rejoindre le cluster selon le role du noeud.
• Installer un CNI avant d’attendre des pods applicatifs fonctionnels.
• Valider CoreDNS, nodes Ready et un deploiement de test.

Le how-to est volontairement court: l’idee est d’obtenir un resultat observable, puis d’utiliser les commandes de verification pour comprendre ce qui s’est passe.

Approfondir cet article

Cet episode doit surtout permettre de maitriser les composants d’un cluster, leur installation et les responsabilites entre control plane, workers et runtime. L’objectif n’est pas seulement de refaire les commandes, mais de comprendre quel objet Kubernetes est cree, quel composant le prend en charge et comment verifier le resultat.

Questions a se poser

• Quel est l’etat desire exprime dans Kubernetes ?
• Quel composant observe cet etat et tente de le reconciler ?
• Quels symptomes montrent que l’objet est cree mais pas encore operationnel ?
• Quelle commande donne l’information la plus fiable pour diagnostiquer ?

Commandes de verification

• kubectl get nodes -o wide
• kubectl -n kube-system get pods -o wide
• sudo crictl ps ou sudo systemctl status containerd kubelet sur les noeuds

Ces commandes ne sont pas a apprendre par coeur. Elles servent a construire un reflexe: partir de l’objet Kubernetes, lire son etat, puis descendre vers les pods, les events, les logs ou le noeud uniquement si c’est necessaire.

Points de vigilance

• confondre installation reussie et cluster exploitable dans la duree
• ne pas verifier DNS, CNI, certificats et horloge apres l’installation
• oublier que la haute disponibilite depend aussi du load balancer et du reseau

Exercice conseille

Preparez une checklist post-installation: nodes Ready, CoreDNS fonctionnel, CNI actif, pod de test joignable et redemarrage d’un composant kube-system observe.

Pour valider la comprehension, gardez une trace courte: manifest utilise, commandes lancees, resultat attendu, resultat observe et correction appliquee. Cette methode rend les episodes suivants beaucoup plus faciles a enchainer.

Lien interne conseille

Pour poursuivre la progression, consultez aussi Kubernetes 008 – Kubectl et Curl pour debutant : commandes et certificats clients.

Conclusion

Comprendre l’API Server et RBAC est indispensable pour eviter de manipuler Kubernetes comme une simple boite noire. Chaque commande kubectl est une requete API soumise a des controles.