Un article publié sur le blog de la CNCF recommande de traiter le contrôle d’accès aux clusters Kubernetes comme faisant partie de la liste de configuration de base, au même titre que le réseau et le stockage, en particulier dans les environnements autohébergés qui ne fournissent généralement pas d’intégration IAM ou SSO prête à l’emploi, contrairement aux services Kubernetes managés. L’idée centrale consiste à utiliser un fournisseur d’identité compatible avec OIDC, tel que Keycloak, en enregistrant le client comme un client public utilisant PKCE, et non comme un client secret détenant une clé partagée.
Dans de nombreux clusters locaux, l’accès repose sur un certificat client statique ou sur un jeton à longue durée de vie émis une seule fois. Ces données restent valides même après le départ de l’employé, le changement de son rôle ou la perte de l’appareil qui les contient. De plus, la révocation de l’accès nécessite de retrouver chaque copie du fichier de certificat ou du jeton, une opération dont il est difficile de garantir l’exhaustivité lorsque les appareils et les utilisateurs sont nombreux. À mesure que le nombre de personnes augmente et que les niveaux d’autorisation diffèrent, la distribution et la gestion des fichiers deviennent une tâche opérationnelle permanente.
Qu’est-ce qui change avec OIDC ?
Au lieu de lier l’autorisation à un fichier de certificat, celle-ci est liée au compte de l’utilisateur et à son appartenance aux groupes du fournisseur d’identité. L’intégration se compose de trois parties interconnectées : l’outil kubectl avec l’extension kubelogin ou kubectl oidc-login, le fournisseur d’identité qui authentifie l’utilisateur et émet le jeton d’identité, et le serveur kube-apiserver qui vérifie le jeton, en extrait le nom d’utilisateur et les groupes, puis laisse Kubernetes RBAC déterminer les opérations autorisées.
kubectl ne se connecte pas d’abord au serveur API pour lancer la connexion. L’extension exec-credential lance la connexion via le navigateur auprès du fournisseur d’identité, puis renvoie le jeton d’identité à kubectl afin qu’il soit envoyé comme identifiant d’authentification Bearer. Le serveur API vérifie le jeton à l’aide des clés de signature publiques du fournisseur d’identité. Selon l’article, le serveur n’a pas besoin d’une connexion permanente au fournisseur d’identité, à l’exception de la récupération de ces clés lorsque cela est nécessaire.
Pourquoi le client doit-il être public ?
Le client secret émet une clé qui est ajoutée à la configuration de l’extension kubelogin et distribuée à chaque appareil nécessitant un accès. L’article estime que la clé qui doit être distribuée à tous les clients n’est plus réellement secrète, mais constitue un identifiant statique partagé difficile à renouveler. Pour les applications en ligne de commande et les applications natives, le choix le plus approprié est donc un client public sans secret, avec PKCE, ou Proof Key for Code Exchange, activé.
Le client génère localement une valeur aléatoire et en envoie le hachage dans la première requête de connexion, puis prouve qu’il possède la valeur originale lorsqu’il échange le code d’autorisation contre un jeton d’accès. Ainsi, une personne qui intercepte uniquement le code d’autorisation ne peut pas terminer l’opération. Les paramètres Keycloak présentés dans l’article recommandent de désactiver l’authentification du client, d’activer le flux standard, de désactiver les octrois d’accès direct et d’imposer PKCE avec S256, tout en limitant les URI de redirection et les origines web aux adresses loopback telles que 127.0.0.1 et localhost.
Étapes essentielles de configuration
- Ajouter le mappeur d’appartenance aux groupes à la portée du client dans Keycloak, afin qu’une revendication nommée groups apparaisse dans le jeton d’identité.
- Configurer kube-apiserver à l’aide d’indicateurs tels que oidc-issuer-url, oidc-client-id, oidc-username-claim et oidc-groups-claim.
- Ajouter oidc-ca-file si le fournisseur d’identité utilise un certificat qui n’est pas signé par une autorité publique de confiance, afin que le serveur API puisse vérifier la connexion TLS et récupérer les clés de signature.
- Modifier kubeconfig pour utiliser une entrée exec-credential via kubectl oidc-login au lieu d’inclure des certificats ou des jetons statiques, sans ajouter de champ secret.
- Associer les groupes du fournisseur d’identité aux rôles Kubernetes RBAC, par exemple en associant le groupe platform-viewer au rôle view.
Impact pratique et limites
Après cette association, les modifications d’accès sont effectuées dans le fournisseur d’identité : l’utilisateur est ajouté à un groupe ou en est retiré, au lieu de modifier le cluster ou de redistribuer kubeconfig. Le jeton suivant émis pour l’utilisateur contient la nouvelle appartenance au groupe, et la règle RBAC qui lui est associée s’applique. L’article explique que la première connexion ouvre le navigateur, tandis que kubelogin réutilise le jeton stocké dans le cache jusqu’à son expiration, puis utilise le jeton d’actualisation sans nouvelle étape dans le navigateur. L’identité et les groupes effectifs peuvent être vérifiés avec la commande kubectl auth whoami.
Cela ne signifie pas que l’intégration est dépourvue d’exigences opérationnelles. Il faut configurer précisément la revendication des groupes, vérifier le certificat du fournisseur d’identité, limiter les URI de redirection et s’assurer que les rôles RBAC reflètent les autorisations requises. L’article ne fournit pas non plus de mesures indépendantes du temps de configuration ou du coût d’exploitation ; il estime plutôt que la préparation peut être effectuée en une seule période de travail, sans migration complète de la plateforme.
Le principal avantage en matière de sécurité et d’administration est que les journaux Kubernetes deviennent liés à l’identité réelle de l’utilisateur. Les journaux qui reposent sur un compte générique tel que cluster-admin ne permettent pas de distinguer les auteurs des requêtes, tandis que chaque requête émise via OIDC contient le nom de l’utilisateur et les groupes qui lui sont associés. Il s’agit d’une lecture éditoriale fondée sur les détails de l’article : l’amélioration ne concerne pas uniquement la méthode de connexion, mais aussi la possibilité d’attribuer les actions à leurs auteurs, tout en faisant de l’octroi et du retrait des autorisations un processus d’identité centralisé plutôt qu’une recherche de fichiers d’identifiants dispersés.