ServiceAccount Kubernetes

cloud

Définition

Un ServiceAccount Kubernetes est une identité assignée aux pods et aux processus s'exécutant dans un cluster Kubernetes, permettant leur authentification auprès du kube-apiserver pour effectuer des appels API. Contrairement aux User Accounts destinés aux humains, les ServiceAccounts sont destinés aux processus automatisés (applications, opérateurs, pipelines CI/CD) et sont des ressources Kubernetes native stockées dans le cluster. Chaque namespace Kubernetes dispose d'un ServiceAccount par défaut ("default") créé automatiquement. Par défaut dans les versions antérieures à Kubernetes 1.24, un token JWT est automatiquement monté dans chaque pod via un volume secret à /var/run/secrets/kubernetes.io/serviceaccount/token. Ce token permet au pod de s'authentifier à l'API Kubernetes. Depuis Kubernetes 1.24, les tokens ServiceAccount sont liés à un pod spécifique et ont une durée de vie limitée (expiration après 1h par défaut). Les risques de sécurité des ServiceAccounts incluent : l'utilisation du ServiceAccount "default" avec des permissions excessives (le SA default d'un namespace héritera de toutes les permissions qui lui sont assignées via RoleBindings), le montage automatique du token même dans des pods qui n'en ont pas besoin (activé par défaut mais désactivable via automountServiceAccountToken: false), et l'attribution de ClusterRoles à des ServiceAccounts applicatifs (donnant des droits cluster-wide à un pod potentiellement compromis). La bonne pratique consiste à créer des ServiceAccounts dédiés pour chaque application avec uniquement les permissions RBAC nécessaires à ses fonctions. Le champ automountServiceAccountToken: false doit être ajouté au ServiceAccount et/ou au PodSpec pour les pods qui n'ont pas besoin d'accéder à l'API Kubernetes. Les ServiceAccounts GKE avec Workload Identity s'associent directement à des Service Accounts GCP, permettant aux pods Kubernetes d'appeler des APIs GCP (Cloud Storage, Pub/Sub) via IAM GCP sans stocker de clés JSON dans le cluster.

Audit des permissions ServiceAccount

Identifiez les ServiceAccounts avec des permissions excessives : kubectl get clusterrolebindings -o json | jq '.items[] | select(.subjects[].kind=="ServiceAccount") | .roleRef.name + " -> " + .subjects[].name'. Les ClusterRoleBindings attribuant cluster-admin ou des rôles permettant de list/get Secrets à des ServiceAccounts applicatifs sont des risques critiques. Utilisez kubectl auth can-i --list --as=system:serviceaccount:namespace:sa-name pour lister toutes les permissions d'un SA.

Désactiver le montage automatique du token

Désactivez le montage automatique du token SA pour les pods qui n'ont pas besoin d'accéder à l'API : ajoutez automountServiceAccountToken: false dans le PodSpec ou dans la définition du ServiceAccount. Cette configuration évite qu'un attaquant ayant compromis un pod puisse récupérer un token API valide. Pour les pods nécessitant l'accès à l'API, montez le token explicitement avec un volume projected à durée de vie limitée.

Projected tokens et durée de vie limitée

Kubernetes 1.20+ supporte les projected ServiceAccount tokens avec expiration : montez le token via un volume projected (serviceAccountToken) avec un expirationSeconds de 3600 (1h). Ces tokens sont automatiquement renouvelés par le kubelet avant expiration, garantissant que les pods utilisent toujours un token valide tout en limitant la durée d'utilisation en cas de vol. Cette approche remplace les tokens statiques anciens qui n'expiraient jamais.

Articles liés

Expert en cybersécurité offensive et intelligence artificielle. Pentest, audit et développement IA sur-mesure.

Services

Ressources

Projets & Outils

Contact

Nous contacter

Mentions légales Confidentialité Politique éditoriale Plan du site ⭐ Source préférée

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis