## Introduction L'authentification Kubernetes est la première barrière que chaque requête doit franchir avant d'atteindre le serveur d'API. Que vous soyez un développeur déboguant un déploiement défaillant, un ingénieur de plateforme intégrant une nouvelle équipe ou un SRE enquêtant sur une erreur de permission inhabituelle, connaître les commandes exactes pour inspecter et vérifier l'authentification est essentiel pour des opérations de cluster sûres et efficaces. Cet article fournit une référence de commandes pratiques pour l'authentification Kubernetes. Il couvre les concepts fondamentaux, les flux de travail courants et les techniques de diagnostic, avec des exemples concrets et les sorties attendues. Nous nous concentrons sur des commandes sûres à exécuter dans un cluster de production, mettons l'accent sur le principe du moindre privilège et incluons des étapes de récupération pour les modes de défaillance courants. L'objectif est la clarté opérationnelle : comprendre qui est authentifié, comment il est authentifié et si ses informations d'identification fonctionnent comme prévu. Vous apprendrez à inspecter les certificats, les jetons, les comptes de service et à valider les configurations RBAC (Role-Based Access Control, contrôle d'accès basé sur les rôles) avec quelques commandes bien choisies. ## Inventaire des versions et de l'environnement Avant d'exécuter des commandes d'authentification, connaissez la version de votre cluster et ses composants. Le comportement de l'authentification peut varier selon les versions de Kubernetes, notamment avec des fonctionnalités comme l'API TokenRequest (stable depuis la 1.20) et les jetons de compte de service liés (par défaut depuis la 1.21). Utilisez les commandes en lecture seule suivantes pour recueillir des informations sans modifier l'état. ```bash kubectl version --short ``` Exemple de sortie : ``` Client Version: v1.27.3 Kustomize Version: v5.0.1 Server Version: v1.27.3 ``` Cela confirme que le client et le serveur sont compatibles. Si la version du serveur est nettement plus ancienne ou plus récente que prévu, certaines fonctionnalités d'authentification peuvent ne pas être disponibles. Vérifiez la configuration d'authentification du serveur d'API en affichant la spécification de son pod (si vous avez accès au plan de contrôle) : ```bash kubectl -n kube-system get pod kube-apiserver- -o yaml | grep -A5 'command:' ``` Recherchez des indicateurs comme `--authentication-token-webhook-config-file`, `--oidc-issuer-url` ou `--client-ca-file`. Ceux-ci indiquent les méthodes d'authentification activées. ### Vérifications pratiques de l'environnement - Vérifiez que vous pouvez joindre le serveur d'API et que vos informations d'identification actuelles fonctionnent : ```bash kubectl auth whoami ``` Exemple de sortie : ``` ATTRIBUTE VALUE Username kubernetes-admin UID abc123... (sur certains clusters) Groups [system:masters system:authenticated] ``` Si vous obtenez `Error from server (Forbidden)`, votre utilisateur ne dispose pas de la permission `selfsubjectaccessreviews`, mais l'authentification de base fonctionne toujours. - Listez les nœuds pour confirmer la santé du cluster : ```bash kubectl get nodes ``` Un nœud `NotReady` peut indiquer des problèmes d'authentification de certificat ou de kubelet. - Vérifiez les comptes de service de l'espace de noms par défaut : ```bash kubectl get serviceaccounts ``` Chaque espace de noms possède un compte de service `default`. Des problèmes avec ce compte provoquent souvent des échecs d'authentification pour les charges de travail. Gardez toutes les commandes en lecture seule jusqu'à ce que vous ayez établi une base de référence. Utilisez `kubectl` avec `--dry-run=client` pour tout changement afin de comprendre quelles ressources seraient modifiées. ## Comprendre l'authentification Kubernetes Kubernetes ne gère pas nativement les comptes d'utilisateurs. Il s'appuie plutôt sur des fournisseurs d'identité externes (certificats X.509, jetons statiques, OpenID Connect, webhooks) pour les utilisateurs humains, et sur les comptes de service pour les processus s'exécutant à l'intérieur du cluster. Toutes les requêtes authentifiées sont ensuite autorisées séparément, généralement via RBAC. ### Commandes de base pour l'inspection de l'authentification #### 1. Inspecter vos informations d'identification actuelles Votre fichier kubeconfig stocke les informations de cluster, d'utilisateur et de contexte. Utilisez `kubectl config view` pour le voir : ```bash kubectl config view --minify ``` Cela montre le contexte, le cluster et les détails utilisateur actuels. Exemple : ```yaml apiVersion: v1 clusters: - cluster: certificate-authority-data: REDACTED server: https://192.168.1.100:6443 name: my-cluster contexts: - context: cluster: my-cluster user: my-user name: my-context current-context: my-context kind: Config preferences: {} users: - name: my-user user: client-certificate-data: REDACTED client-key-data: REDACTED ``` Pour voir les détails du certificat décodé (expiration, sujet, émetteur) : ```bash kubectl config view --raw -o jsonpath='{.users[?(@.name=="my-user")].user.client-certificate-data}' | base64 -d | openssl x509 -noout -subject -issuer -dates ``` La sortie peut ressembler à : ``` subject=O=system:masters, CN=kubernetes-admin issuer=CN=kubernetes notBefore=Jan 1 00:00:00 2023 GMT notAfter=Dec 31 23:59:59 2024 GMT ``` Vérifiez la date d'expiration. Un certificat expiré provoque des échecs d'authentification. #### 2. Vérifier les jetons de compte de service Chaque compte de service est associé à un ou plusieurs secrets contenant des jetons. Listez-les : ```bash kubectl get secrets ``` Recherchez les secrets de type `kubernetes.io/service-account-token`. Pour un compte de service spécifique `default` : ```bash kubectl get secret $(kubectl get serviceaccount default -o jsonpath='{.secrets[0].name}') -o yaml ``` Le jeton est encodé en base64. Décodez-le pour inspecter le JWT (JSON Web Token) : ```bash kubectl get secret -o jsonpath='{.data.token}' | base64 -d ``` Cela affichera le JWT. Vous pouvez décoder la charge utile pour voir les revendications : ```bash # Copiez le jeton et collez-le sur jwt.io, ou utilisez un outil en ligne de commande ``` Dans Kubernetes 1.24+, les secrets de jetons de compte de service hérités ne sont plus créés automatiquement. Utilisez l'API TokenRequest pour générer un jeton à courte durée de vie : ```bash kubectl create token default ``` Cela produit un jeton valide pendant 1 heure par défaut. Exemple de sortie : ``` eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJhdWQiOlsiaHR0cHM6Ly9rdWJlcm5ldGVzLmRlZmF1bHQuc3ZjLmNsdXN0ZXIubG9jYWwiXSwiZXhwIjoxNjg4NzY1NDMyLCJpYXQiOjE2ODg3NjE4MzIsImlzcyI6Imh0dHBzOi8va3ViZXJuZXRlcy5kZWZhdWx0LnN2Yy5jbHVzdGVyLmxvY2FsIiwia3ViZXJuZXRlcy5pbyI6eyJuYW1lc3BhY2UiOiJkZWZhdWx0Iiwic2VydmljZWFjY291bnQiOiJ7XCJuYW1lXCI6XCJkZWZhdWx0XCIsXCJ1aWQiXCI6XCI5ZDc5YzA1MS05YjQxLTQ0MjEtOGVjMC0wM2ExMjI2OTk2YmZcIn0ifSwibmJmIjoxNjg4NzYxODMyLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6ZGVmYXVsdDpkZWZhdWx0In0.eyJhbGciOiJSUzI1NiJ9... (truncated) ``` #### 3. Vérifier les permissions RBAC Utilisez `kubectl auth can-i` pour vérifier si une action spécifique est autorisée pour l'utilisateur actuel ou un compte de service. Vérifiez si vous pouvez créer des pods dans l'espace de noms actuel : ```bash kubectl auth can-i create pods ``` Sortie : `yes` ou `no`. Pour un compte de service `my-sa` dans l'espace de noms `my-ns`, vérifiez s'il peut lister les déploiements : ```bash kubectl auth can-i list deployments --as=system:serviceaccount:my-ns:my-sa -n my-ns ``` Pour voir qui peut effectuer une action dans tout le cluster, utilisez `kubectl auth reconcile` mais c'est pour appliquer des changements RBAC. Pour le dépannage, inspectez les rôles et les liaisons. ## Flux de travail d'authentification courants avec exemples ### Ajouter un nouvel utilisateur avec des certificats clients 1. Générez une clé privée et une demande de signature de certificat (CSR, Certificate Signing Request) : ```bash openssl genrsa -out user.key 2048 openssl req -new -key user.key -out user.csr -subj "/CN=alice/O=developers" ``` Le `CN` est le nom d'utilisateur, et `O` devient le groupe. 2. Créez une ressource CertificateSigningRequest Kubernetes : ```bash cat < user.crt ``` 5. Ajoutez l'utilisateur au kubeconfig : ```bash kubectl config set-credentials alice --client-certificate=user.crt --client-key=user.key kubectl config set-context alice-context --cluster=my-cluster --user=alice kubectl config use-context alice-context ``` 6. Testez l'accès : ```bash kubectl get pods ``` Si aucune permission RBAC n'est attribuée, la sortie sera `Error from server (Forbidden): pods is forbidden: User "alice" cannot list resource "pods" in API group "" in the namespace "default"`. 7. Accordez des permissions à l'aide d'un Role et d'un RoleBinding : ```bash kubectl create role pod-reader --verb=get,list,watch --resource=pods kubectl create rolebinding alice-pod-reader --role=pod-reader --user=alice ``` Maintenant, `kubectl get pods` devrait réussir. ### Créer un compte de service pour une application 1. Créez un compte de service dédié : ```bash kubectl create serviceaccount my-app-sa ``` 2. Attribuez-le à un déploiement : ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: my-app spec: replicas: 1 selector: matchLabels: app: my-app template: metadata: labels: app: my-app spec: serviceAccountName: my-app-sa containers: - name: app image: nginx ``` 3. Vérifiez que le pod utilise le compte de service : ```bash kubectl get pod -l app=my-app -o jsonpath='{.items[0].spec.serviceAccountName}' ``` Sortie : `my-app-sa`. 4. Accordez au compte de service l'accès aux ressources nécessaires. Par exemple, autorisez-le à lire les configmaps dans son espace de noms : ```bash kubectl create role configmap-reader --verb=get,list --resource=configmaps kubectl create rolebinding my-app-sa-configmap-reader --role=configmap-reader --serviceaccount=default:my-app-sa ``` ### Utiliser l'authentification OpenID Connect (OIDC) Si votre cluster est configuré avec OIDC (OpenID Connect, protocole d'authentification basé sur OAuth 2.0), les utilisateurs obtiennent un jeton d'identité auprès du fournisseur d'identité et l'utilisent comme jeton porteur. Le serveur d'API valide le jeton par rapport à la configuration du fournisseur. Pour utiliser un jeton OIDC, fournissez-le directement dans le kubeconfig : ```bash kubectl config set-credentials oidc-user --auth-provider=oidc --auth-provider-arg=idp-issuer-url=https://issuer.example.com --auth-provider-arg=client-id=kubernetes --auth-provider-arg=id-token= ``` Ou vous pouvez passer le jeton à chaque requête : ```bash kubectl --token= get pods ``` Pour inspecter les revendications du jeton, décodez la charge utile du JWT. La revendication `sub` devient le nom d'utilisateur, et la revendication `groups` devient les appartenances aux groupes. ## Vérification et diagnostics ### Diagnostiquer les échecs d'authentification Les échecs d'authentification se traduisent généralement par des erreurs HTTP 401 du serveur d'API. Messages courants : - `Unauthorized` - `error: You must be logged in to the server (Unauthorized)` - `x509: certificate signed by unknown authority` Utilisez `kubectl` avec une verbosité accrue pour voir les détails de la requête/réponse : ```bash kubectl get pods -v=8 ``` Recherchez les lignes contenant `401` ou `Authorization`. Si vous utilisez un jeton, vérifiez son expiration et sa signature : ```bash kubectl create token default --duration=0s # Dans les anciennes versions, peut échouer ; utilisez un décodage manuel. ``` Décodez le jeton avec un outil comme `jq` et `base64` : ```bash # Extraire la charge utile (deuxième segment) TOKEN=$(kubectl create token default) echo $TOKEN | cut -d'.' -f2 | base64 -d 2>/dev/null | jq . ``` Exemple de sortie : ```json { "aud": ["https://kubernetes.default.svc.cluster.local"], "exp": 1688765432, "iat": 1688761832, "iss": "https://kubernetes.default.svc.cluster.local", "kubernetes.io": { "namespace": "default", "serviceaccount": {"name":"default","uid":"9d79c051-..."} }, "nbf": 1688761832, "sub": "system:serviceaccount:default:default" } ``` Vérifiez que `exp` est dans le futur et que `aud` inclut l'audience du serveur d'API. ### Vérifier les politiques RBAC Pour voir quels rôles sont liés à un utilisateur ou un compte de service : ```bash kubectl get rolebindings,clusterrolebindings --all-namespaces -o custom-columns='KIND:.kind,NAMESPACE:.metadata.namespace,NAME:.metadata.name,ROLE:.roleRef.name,SUBJECTS:.subjects[*].name' | grep alice ``` Pour une analyse plus approfondie, utilisez `kubectl auth reconcile --dry-run=client -f rbac.yaml` pour voir les différences sans les appliquer. ### Vérifier les montages de jetons de compte de service À l'intérieur d'un pod, le jeton de compte de service est monté à `/var/run/secrets/kubernetes.io/serviceaccount/token`. Pour vérifier que le jeton est celui attendu : ```bash kubectl exec -- cat /var/run/secrets/kubernetes.io/serviceaccount/token ``` Comparez avec le jeton du secret ou de TokenRequest. ## Modes de défaillance et récupération Comprendre les échecs d'authentification courants vous aide à réagir rapidement. ### Certificat client expiré **Symptôme** : Lors de l'exécution de `kubectl get pods`, vous voyez : ``` Unable to connect to the server: x509: certificate has expired or is not yet valid ``` **Pourquoi cela arrive** : Le certificat client dans le kubeconfig a dépassé sa date `notAfter`. **Récupération** : 1. Vérifiez l'expiration avec `openssl x509 -noout -dates -in `. 2. Obtenez un nouveau certificat auprès de votre autorité de certification ou régénérez via CSR comme décrit précédemment. 3. Mettez à jour les informations d'identification du kubeconfig. ### Jeton invalide ou expiré **Symptôme** : Les requêtes API renvoient `401 Unauthorized: invalid token`. **Pourquoi cela arrive** : Le jeton peut être expiré, malformé, ou la clé de signature a été renouvelée. **Récupération** : - Pour les jetons de compte de service : générez un nouveau jeton avec `kubectl create token ` et mettez à jour votre application. - Pour les jetons statiques : vérifiez le fichier `--token-auth-file` du serveur d'API et assurez-vous que le jeton correspond. - Pour OIDC : actualisez le jeton d'identité auprès du fournisseur. ### Certificat signé par une autorité inconnue **Symptôme** : `x509: certificate signed by unknown authority` lors de la connexion. **Pourquoi cela arrive** : Le certificat de l'autorité de certification du cluster dans le kubeconfig ne correspond pas au certificat du serveur, ou l'autorité de certification n'est pas approuvée. **Récupération** : - Assurez-vous que `certificate-authority-data` ou `certificate-authority` dans le kubeconfig pointe vers la bonne autorité de certification. - Si vous utilisez une autorité de certification personnalisée, ajoutez-la à votre magasin de confiance système ou spécifiez `insecure-skip-tls-verify: true` (non recommandé en production). ### L'utilisateur ne peut pas effectuer une action malgré une liaison de rôle **Symptôme** : `kubectl auth can-i create pods` renvoie `no` mais vous pensez que l'utilisateur devrait avoir la permission. **Pourquoi cela arrive** : RBAC est mal configuré : liaison de rôle dans le mauvais espace de noms, mauvais sujet (utilisateur vs compte de service), ou verbes/ressources manquants. **Récupération** : - Listez les liaisons avec `kubectl get rolebindings -n -o yaml` et vérifiez les sujets. - Vérifiez les règles du rôle : `kubectl get role -o yaml`. - Utilisez `kubectl auth can-i --list --as=` pour voir toutes les permissions de cet utilisateur. ### Le compte de service ne monte pas le jeton **Symptôme** : L'application à l'intérieur du pod échoue à s'authentifier auprès du serveur d'API, et le fichier de jeton est manquant ou vide. **Pourquoi cela arrive** : Le nom du compte de service du pod peut être mal orthographié, ou le compte de service n'existe pas. **Récupération** : - Vérifiez le compte de service : `kubectl get serviceaccounts -n `. - Vérifiez la spécification du pod : `kubectl get pod -o jsonpath='{.spec.serviceAccountName}'`. - S'il est manquant, recréez le pod avec le bon `serviceAccountName`. ## Liste de contrôle des opérations Utilisez cette liste de contrôle pour vous assurer que l'authentification est correctement gérée dans votre cluster. Attribuez un responsable et une fréquence de révision. | Élément | Commande / Action | Responsable | Fréquence | |------|-------------------|-------|-----------| | Auditer les utilisateurs actifs et leurs groupes | `kubectl config view --raw` à examiner | Ingénieur sécurité (ex. Priya Shah) | Mensuelle | | Examiner les comptes de service et leurs jetons | `kubectl get serviceaccounts --all-namespaces` et inspecter les secrets | Responsable plateforme (ex. Marcus Chen) | Mensuelle | | Vérifier les certificats expirés | `kubectl get csr`, `openssl x509 -noout -dates` sur tous les certificats clients | Administrateur cluster (ex. Alice Johnson) | Hebdomadaire | | Valider les politiques RBAC par rapport au moindre privilège | `kubectl auth reconcile --dry-run` et `kubectl auth can-i --list` pour les utilisateurs critiques | Responsable sécurité (ex. David Kim) | Trimestrielle | | Renouveler les jetons de compte de service | `kubectl create token ` pour des jetons à courte durée de vie | Ingénieur DevOps (ex. Sarah Lee) | Trimestrielle | | Examiner la configuration du webhook d'authentification | Inspecter les indicateurs du serveur d'API | Architecte plateforme (ex. Tom Brown) | Semestrielle | | Tester la réponse aux incidents pour les échecs d'authentification | Simuler un certificat ou jeton expiré et exécuter la procédure de récupération | Équipe SRE (responsable unique : Emily Davis) | Annuelle | ### Pratiques opérationnelles clés 1. **Utilisez RBAC avec le moindre privilège** : N'accordez que les permissions nécessaires. Évitez d'utiliser `cluster-admin` pour le travail quotidien. 2. **Préférez les jetons à courte durée de vie** : Pour les comptes de service, utilisez l'API TokenRequest ou des jetons projetés avec expiration. Pour les utilisateurs, utilisez OIDC avec des jetons d'actualisation. 3. **Surveillez les métriques d'authentification** : Activez les journaux d'audit du serveur d'API et alertez sur les pics de `401`. 4. **Automatisez le renouvellement des certificats** : Utilisez cert-manager ou un contrôleur similaire pour les certificats clients. 5. **Documentez les étapes de récupération** : Tenez à jour des procédures pour les certificats expirés, les problèmes de jetons et les mauvaises configurations RBAC. ## Pièges courants et comment les éviter ### Piège 1 : Utiliser le compte de service par défaut pour toutes les charges de travail **Pourquoi cela arrive** : C'est pratique car chaque espace de noms en possède un, et les développeurs peuvent ne pas penser à l'isolation des identités. **Comment éviter** : Créez un compte de service dédié pour chaque application et définissez explicitement `serviceAccountName` dans les spécifications des pods. Cela limite le rayon d'impact si un jeton est compromis. **Récupération** : Si vous utilisez déjà le compte par défaut, créez de nouveaux comptes de service, mettez à jour les déploiements et supprimez les montages de jetons par défaut avec `automountServiceAccountToken: false` là où ce n'est pas nécessaire. ### Piège 2 : Permissions RBAC trop larges avec des caractères génériques **Pourquoi cela arrive** : Les développeurs demandent souvent `*` sur les ressources pour que les choses fonctionnent rapidement, ou les administrateurs copient le rôle cluster-admin par simplicité. **Comment éviter** : Commencez avec des permissions minimales, testez avec `kubectl auth can-i --list`, et étendez uniquement lorsque nécessaire. Utilisez des outils comme `kubectl-who-can` ou `audit2rbac` pour générer des rôles à moindre privilège. **Récupération** : Examinez toutes les liaisons de rôles pour l'utilisation de caractères génériques avec `kubectl get clusterrolebindings -o json | jq '.items[] | select(.roleRef.name=="cluster-admin")'` et resserrez. ### Piège 3 : Coder en dur les jetons de compte de service dans le code de l'application ou les fichiers de configuration **Pourquoi cela arrive** : Cela semble plus facile que de monter depuis les secrets, surtout lors de l'exécution en dehors de Kubernetes. **Comment éviter** : Utilisez le fichier de jeton monté ou l'API TokenRequest à l'intérieur du cluster. À l'extérieur, utilisez l'identité de charge de travail ou OIDC. **Récupération** : Supprimez les jetons codés en dur, renouvelez-les immédiatement et adoptez une livraison sécurisée des jetons. ### Piège 4 : Ignorer l'expiration des certificats **Pourquoi cela arrive** : Les certificats clients ont de longues durées de vie et aucune alerte n'est configurée. **Comment éviter** : Surveillez l'expiration des certificats avec des alertes Prometheus ou des notifications cert-manager. **Récupération** : Mettez en œuvre un renouvellement automatisé et ayez un processus manuel comme secours. ### Piège 5 : Ne pas faire la distinction entre authentification et autorisation **Pourquoi cela arrive** : Les utilisateurs confondent souvent les deux : ils voient `Forbidden` (403) et pensent que l'authentification est cassée. **Comment éviter** : Diagnostiquez avec `kubectl auth can-i`. Si `whoami` réussit mais que `can-i` renvoie `no`, c'est un problème d'autorisation (RBAC), pas d'authentification. **Récupération** : Corrigez la liaison de rôle plutôt que d'essayer de changer les informations d'identification de l'utilisateur. ### Piège 6 : Exécuter avec cluster-admin pour les pipelines CI/CD **Pourquoi cela arrive** : Les CI/CD ont besoin d'un accès large pour déployer à travers les espaces de noms, et accorder cluster-admin est facile. **Comment éviter** : Créez des comptes de service dédiés avec des rôles étroitement définis pour chaque pipeline. Utilisez l'isolation des espaces de noms Kubernetes. **Récupération** : Auditez les informations d'identification des pipelines, créez de nouveaux rôles et renouvelez les jetons. ## Conclusion L'authentification est la base de la sécurité Kubernetes. Maîtriser les commandes pour inspecter et gérer l'authentification garantit que vous pouvez résoudre rapidement les problèmes d'accès, maintenir le moindre privilège et garder votre cluster sécurisé. Cet article a fourni une référence complète : de la vérification de votre environnement et de vos informations d'identification, à la création d'utilisateurs et de comptes de service, au diagnostic des échecs et à l'évitement des pièges courants. Commencez par appliquer une vérification à faible risque de ce guide : exécutez `kubectl auth whoami` pour voir sous quelle identité vous êtes authentifié, puis vérifiez vos permissions avec `kubectl auth can-i --list`. Documentez les résultats et comparez-les avec l'accès attendu. Ensuite, examinez vos comptes de service et vos pratiques en matière de jetons. Au fil du temps, étendez aux vérifications automatisées et aux audits. Un système d'exploitation d'authentification robuste rend les échecs visibles, protège les informations d'identification sensibles, limite les modifications aux ressources prévues et garantit que les plans de récupération sont testés avant qu'un incident ne se produise.