Authentification Kubernetes : commandes essentielles pour un accès sécurisé au cluster

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.

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) :

kubectl -n kube-system get pod kube-apiserver-<master-node> -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 :

  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 :

  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 :

  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 :

kubectl config view --minify

Cela montre le contexte, le cluster et les détails utilisateur actuels. Exemple :

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) :

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 :

kubectl get secrets

Recherchez les secrets de type kubernetes.io/service-account-token. Pour un compte de service spécifique default :

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) :

kubectl get secret <secret-name> -o jsonpath='{.data.token}' | base64 -d

Cela affichera le JWT. Vous pouvez décoder la charge utile pour voir les revendications :

# 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 :

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 :

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 :

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) :

   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.

1. Créez une ressource CertificateSigningRequest Kubernetes :

   cat <<EOF | kubectl apply -f -
   apiVersion: certificates.k8s.io/v1
   kind: CertificateSigningRequest
   metadata:
     name: alice-csr
   spec:
     request: $(cat user.csr | base64 | tr -d '\n')
     signerName: kubernetes.io/kube-apiserver-client
     usages:
     - client auth
   EOF

1. Approuvez la CSR :

   kubectl certificate approve alice-csr

1. Récupérez le certificat signé :

   kubectl get csr alice-csr -o jsonpath='{.status.certificate}' | base64 -d > user.crt

1. Ajoutez l'utilisateur au kubeconfig :

   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

1. Testez l'accès :

   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".

1. Accordez des permissions à l'aide d'un Role et d'un RoleBinding :

   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é :

   kubectl create serviceaccount my-app-sa

1. Attribuez-le à un déploiement :

   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

1. Vérifiez que le pod utilise le compte de service :

   kubectl get pod -l app=my-app -o jsonpath='{.items[0].spec.serviceAccountName}'

Sortie : my-app-sa.

1. Accordez au compte de service l'accès aux ressources nécessaires. Par exemple, autorisez-le à lire les configmaps dans son espace de noms :

   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 :

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=<token>

Ou vous pouvez passer le jeton à chaque requête :

kubectl --token=<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 :

kubectl get pods -v=8

Recherchez les lignes contenant 401 ou Authorization.

Si vous utilisez un jeton, vérifiez son expiration et sa signature :

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 :

# 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 :

{
  "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 :

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 :

kubectl exec <pod-name> -- 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 <cert-file>.
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 <sa-name> 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 <namespace> -o yaml et vérifiez les sujets.
• Vérifiez les règles du rôle : kubectl get role <role> -o yaml.
• Utilisez kubectl auth can-i --list --as=<user> 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 <namespace>.
• Vérifiez la spécification du pod : kubectl get pod <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.

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.