Authentification, autorisation et contrôle d'admission

Chaque commande kubectl, chaque contrôleur, chaque pod qui parle à Kubernetes passe par le même guichet : le serveur d'API. Avant d'exécuter quoi que ce soit, il pose trois questions, toujours dans le même ordre : qui es-tu ?, as-tu le droit ?, ta demande est-elle acceptable ? Comprendre ces trois étapes, c'est comprendre la plupart des messages Unauthorized, Forbidden et denied que vous rencontrerez.

Ce que vous saurez à la fin : décrire le chemin d'une requête dans l'API, distinguer authentification, autorisation et contrôle d'admission, interpréter les erreurs 401, 403 et les refus d'admission, et citer les mécanismes courants de chaque étape.

1. Le chemin d'une requête

kubectl apply -f pod.yaml
        │  HTTPS (certificat du serveur vérifié)
        ▼
┌───────────────────────────────────────────────────────────────┐
│ serveur d'API                                                 │
│  1. Authentification   « Qui es-tu ? »          → sinon 401   │
│  2. Autorisation       « As-tu le droit ? »     → sinon 403   │
│  3. Admission          « Est-ce acceptable ? »  → sinon refus │
│     (mutation, puis validation)                               │
│  4. Enregistrement dans etcd                                  │
└───────────────────────────────────────────────────────────────┘

Une requête n'atteint etcd que si elle a franchi les trois portes.

2. L'authentification : qui es-tu ?

Kubernetes ne stocke aucun compte d'utilisateur humain. Il fait confiance à des preuves d'identité présentées à chaque requête :

Mécanisme	Utilisé par	Exemple
Certificat client (X.509)	administrateurs, composants du cluster	le kubeconfig d'un cluster tout juste installé
Jeton de ServiceAccount	les pods, les robots	le jeton monté dans /var/run/secrets/kubernetes.io/serviceaccount/
OIDC (OpenID Connect)	les humains, en entreprise	connexion via l'annuaire de l'entreprise (Entra ID, Keycloak, Zitadel…)
Webhook	cas particuliers	un service maison qui valide les jetons

Le résultat de l'authentification est un nom d'utilisateur et une liste de groupes. Exemple pour un pod : utilisateur system:serviceaccount:boutique:robot, groupes system:serviceaccounts et system:serviceaccounts:boutique.

Échec : 401 Unauthorized. Le jeton est expiré, le certificat n'est pas signé par la bonne autorité, le kubeconfig vise le mauvais cluster…

kubectl config view --minify       # quel cluster, quel utilisateur ?
kubectl auth whoami                # qui l'API pense-t-elle que vous êtes ?

3. L'autorisation : as-tu le droit ?

Une fois l'identité connue, l'API vérifie que cette identité peut faire ce verbe sur cette ressource, dans ce namespace. Plusieurs modules peuvent être enchaînés :

Module	Rôle
RBAC	le standard : des rôles (Role, ClusterRole) attribués par des liaisons (RoleBinding, ClusterRoleBinding) (leçons 2.11 et 4.1)
Node	limite chaque kubelet aux objets des pods de son propre nœud
Webhook	délègue la décision à un service externe

RBAC n'a que des autorisations : tout ce qui n'est pas explicitement permis est interdit. Il n'existe pas de règle « interdire ».

Échec : 403 Forbidden, avec un message très précis :

Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:boutique:robot"
cannot delete resource "pods" in API group "" in the namespace "boutique"

Tout y est : qui (robot), quel verbe (delete), quelle ressource (pods), quel groupe d'API ("", le groupe principal) et où (boutique). Pour tester avant d'agir :

kubectl auth can-i delete pods
kubectl auth can-i --list

4. Le contrôle d'admission : est-ce acceptable ?

Même avec les droits, une demande peut être modifiée ou refusée par les contrôleurs d'admission. Ils interviennent en deux temps :

1. Mutation : ils peuvent compléter la demande. Par exemple, LimitRanger ajoute des requests et limits par défaut, ServiceAccount ajoute le compte default à un pod qui n'en précise pas, et un webhook peut injecter un conteneur sidecar (Istio).
2. Validation : ils acceptent ou refusent la demande finale. Par exemple, ResourceQuota refuse un pod qui dépasse le quota, et Pod Security Admission refuse un pod privilégié dans un namespace protégé (leçon 6.1).

Des contrôleurs intégrés, et deux mécanismes d'extension :

Mécanisme	Exemples
Contrôleurs intégrés	NamespaceLifecycle, LimitRanger, ResourceQuota, PodSecurity, DefaultStorageClass
Webhooks d'admission (mutation ou validation)	Kyverno, OPA Gatekeeper, Istio, cert-manager
ValidatingAdmissionPolicy	des règles écrites en CEL, sans webhook à héberger

Les refus d'admission se reconnaissent à leur message, qui nomme la règle en cause :

Error from server (Forbidden): pods "x" is forbidden: exceeded quota: lab, requested: pods=1 …
Error from server (Forbidden): pods "x" is forbidden: violates PodSecurity "restricted:latest": …
admission webhook "validate.kyverno.svc" denied the request: les images doivent venir du registre interne

Les deux premiers s'affichent eux aussi comme Forbidden : lisez la suite du message pour savoir si c'est RBAC (User … cannot …) ou l'admission (quota, PodSecurity, webhook).

5. Diagnostiquer en trente secondes

Message	Porte	Piste
Unauthorized (401)	authentification	jeton expiré, mauvais kubeconfig, certificat révoqué
User "…" cannot <verbe> resource "…"	autorisation (RBAC)	kubectl auth can-i, rôles et liaisons
exceeded quota	admission (ResourceQuota)	kubectl describe resourcequota
violates PodSecurity	admission (Pod Security)	securityContext du pod, label du namespace
admission webhook "…" denied	admission (webhook)	la politique de l'outil nommé (Kyverno, Gatekeeper…)

Pour aller plus loin

Dans votre propre cluster (« Mon cluster »), vous êtes administrateur : essayez de créer un ServiceAccount, de lui donner un Role, puis de tester ses droits avec kubectl auth can-i --as=system:serviceaccount:<namespace>:<nom>.

Cette leçon se valide par le QCM de passage, avec des messages d'erreur réels à interpréter.