Authentification : Utilisateurs vs ServiceAccounts

L'étape initiale : Qui êtes-vous ?

Toute interaction avec l'API Server Kubernetes commence par une question fondamentale : qui initie cette requête ? C'est le rôle de l'authentification. Avant même d'évaluer si une action est autorisée (l'autorisation, que nous verrons avec RBAC), Kubernetes doit d'abord vérifier et établir de manière fiable l'identité de l'appelant, qu'il s'agisse d'un administrateur utilisant kubectl, d'une application s'exécutant dans un Pod, ou d'un autre composant du système.

Kubernetes ne possède pas en interne de système de gestion de comptes utilisateurs classique avec mots de passe. Au lieu de cela, il s'appuie sur des modules d'authentification externes ou configurés pour valider les informations d'identification (credentials) fournies avec chaque requête. Si l'un des modules configurés réussit à valider les credentials, la requête est considérée comme authentifiée et l'identité de l'appelant (son nom d'utilisateur, son UID et ses appartenances à des groupes) est extraite pour être utilisée lors de la phase d'autorisation.

Pour comprendre comment l'authentification fonctionne, il est essentiel de distinguer les deux principaux types d'identités que Kubernetes reconnaît : les Utilisateurs et les ServiceAccounts.

Les identités humaines : les Utilisateurs

Les Utilisateurs (Users) sont destinés à représenter les humains qui interagissent avec le cluster (développeurs, administrateurs, opérateurs). Un point crucial à comprendre est que Kubernetes ne gère pas les objets Utilisateur directement. Il n'existe pas d'objet `User` que vous pouvez créer, lire, mettre à jour ou supprimer via l'API Kubernetes.

La gestion des utilisateurs est considérée comme une responsabilité externe au cluster. Les identités des utilisateurs sont établies et gérées par un ou plusieurs systèmes configurés par l'administrateur du cluster. Les méthodes courantes incluent :

• Certificats clients X.509 : L'utilisateur présente un certificat signé par une autorité de certification (CA) reconnue par le cluster. Le Common Name (CN) du certificat est souvent utilisé comme nom d'utilisateur, et les Organizations (O) comme groupes. C'est une méthode courante pour les administrateurs via kubectl et les fichiers `kubeconfig`.
• Tokens statiques : Un fichier sur l'API Server contient une liste de tokens prédéfinis associés à des utilisateurs/groupes. Moins sécurisé et difficile à gérer.
• Tokens OpenID Connect (OIDC) : Permet d'intégrer Kubernetes avec un fournisseur d'identité externe (comme Google, Keycloak, Okta, Dex). L'utilisateur s'authentifie auprès du fournisseur OIDC, obtient un ID token (JWT), et présente ce token à l'API Server Kubernetes, qui le valide auprès du fournisseur. C'est une méthode très populaire pour gérer les accès utilisateurs.
• Webhook d'authentification : L'API Server envoie le token présenté dans la requête à un service externe (webhook) pour validation.

Quelle que soit la méthode, le module d'authentification qui réussit doit fournir à Kubernetes au minimum un nom d'utilisateur (une chaîne de caractères unique) et optionnellement un UID et une liste de groupes auxquels l'utilisateur appartient. Ces informations sont ensuite utilisées par le système d'autorisation (RBAC) pour déterminer les permissions.

Les identités des processus : les ServiceAccounts

A l'inverse des Utilisateurs, les ServiceAccounts sont spécifiquement conçus pour représenter les processus et applications s'exécutant à l'intérieur des Pods du cluster, qui ont besoin d'interagir avec l'API Server (par exemple, pour découvrir d'autres services, lire des ConfigMaps, ou gérer d'autres ressources).

Les ServiceAccounts sont des objets natifs de l'API Kubernetes. Vous pouvez les créer, les lister, les modifier et les supprimer comme n'importe quelle autre ressource (ex: kubectl get serviceaccounts, kubectl create serviceaccount my-app-sa).

• Chaque Namespace possède automatiquement un ServiceAccount par défaut nommé `default`.
• Lorsqu'un Pod est créé sans spécifier explicitement de ServiceAccount (via spec.serviceAccountName), il utilise automatiquement le ServiceAccount `default` de son Namespace.
• Kubernetes monte automatiquement les credentials (un token JWT - JSON Web Token) associés au ServiceAccount du Pod dans un emplacement prédéfini à l'intérieur du conteneur (typiquement /var/run/secrets/kubernetes.io/serviceaccount/).
• Les applications à l'intérieur du Pod peuvent alors lire ce token et l'utiliser comme Bearer Token dans l'en-tête `Authorization` de leurs requêtes vers l'API Server pour s'authentifier en tant que ce ServiceAccount.
• L'API Server valide ce token JWT (signature, expiration, audience) pour authentifier la requête.

Le nom d'un ServiceAccount authentifié utilisé par RBAC est formaté comme suit : system:serviceaccount::. Par exemple, system:serviceaccount:kube-system:replicaset-controller.

Il est possible de désactiver le montage automatique du token pour les Pods qui n'ont pas besoin d'accéder à l'API via le champ automountServiceAccountToken: false dans la spécification du Pod ou du ServiceAccount lui-même, ce qui est une bonne pratique de sécurité (principe de moindre privilège).

Pourquoi cette distinction est-elle importante ?

La distinction entre Utilisateurs et ServiceAccounts est fondamentale pour la sécurité et la gestion :

• Gestion : Les utilisateurs sont gérés en externe, permettant l'intégration avec les systèmes d'identité d'entreprise. Les ServiceAccounts sont gérés en interne par Kubernetes, spécifiquement pour les besoins des applications intra-cluster.
• Cycle de vie des credentials : Les méthodes d'authentification des utilisateurs (certificats, OIDC) ont leurs propres cycles de vie et mécanismes de révocation. Les tokens de ServiceAccount sont gérés par Kubernetes (avec des mécanismes de rotation et d'expiration pour les tokens liés aux Pods dans les versions récentes).
• Cas d'usage : Les utilisateurs sont pour les humains accédant au cluster depuis l'extérieur (ou via des outils). Les ServiceAccounts sont pour les machines/processus accédant à l'API depuis l'intérieur du cluster.
• RBAC : Bien que différents, les Utilisateurs, les Groupes et les ServiceAccounts sont tous des 'subjects' (sujets) auxquels on peut attribuer des rôles via les RoleBindings et ClusterRoleBindings dans le système RBAC.

Comprendre cette séparation est la première étape pour configurer correctement l'accès à votre cluster. L'étape suivante consiste à définir ce que ces identités authentifiées sont autorisées à faire, ce qui nous amène directement au contrôle d'accès basé sur les rôles (RBAC).