ServiceAccounts pour développeurs

Un ServiceAccount est l’identité Kubernetes de votre application. Chaque Pod est associé à un ServiceAccount. Lorsqu’un Pod doit appeler l’API Kubernetes, il peut utiliser les credentials montés pour ce ServiceAccount — sauf si ce montage est désactivé. Ce guide vous montre comment créer des ServiceAccounts dédiés avec les permissions minimales nécessaires.

Identité ≠ Permissions

Le ServiceAccount est une identité. Les permissions viennent de RBAC (Role, RoleBinding). Un ServiceAccount sans Role n’a aucun droit sur l’API Kubernetes.

Ce que vous allez apprendre

• Comprendre le rôle des ServiceAccounts comme identité
• Créer un ServiceAccount dédié
• Configurer les permissions avec Role et RoleBinding
• Maîtriser les tokens projetés modernes
• Désactiver le montage de token quand inutile
• Appliquer les bonnes pratiques de sécurité

Tableau de décision rapide

Besoin	Outil recommandé
Pod lit des ressources dans son namespace	Role + RoleBinding
Même permission réutilisée dans plusieurs namespaces	ClusterRole + RoleBinding (par namespace)
Accès réellement global au cluster	ClusterRole + ClusterRoleBinding
Pod n’appelle jamais l’API Kubernetes	automountServiceAccountToken: false
Test ponctuel d’un token	kubectl create token

Glissez pour voir

Pourquoi des ServiceAccounts dédiés ?

Par défaut, un Pod utilise le ServiceAccount default du namespace. Ce n’est pas forcément dangereux en soi, mais c’est rarement un bon choix pour une application de production :

Problème	Conséquence
Identité partagée	Plusieurs workloads apparaissent sous la même identité vis-à-vis de l’API
Traçabilité réduite	La corrélation d’audit devient moins fine
Permissions héritées	Tout RoleBinding sur default s’applique à tous les Pods

Glissez pour voir

Le problème n'est pas le nom 'default'

Le vrai risque n’est pas d’utiliser default, c’est le partage d’identité entre workloads différents et le risque d’y attacher des permissions trop larges.

Solution : Un ServiceAccount par application (ou groupe d’applications avec le même besoin).

Créer un ServiceAccount

serviceaccount.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-sa
  namespace: mon-app

Ou en une ligne :

kubectl create serviceaccount app-sa -n mon-app

Convention de nommage

Utilisez le pattern <app>-sa ou <app>-serviceaccount pour identifier facilement les ServiceAccounts.

Configurer RBAC

RBAC (Role-Based Access Control) définit ce que le ServiceAccount peut faire.

Concepts RBAC

Ressource	Portée	Description
Role	Namespace	Permissions dans un namespace
ClusterRole	Cluster	Définition de permissions réutilisable
RoleBinding	Namespace	Associe Role ou ClusterRole à un sujet dans un namespace
ClusterRoleBinding	Cluster	Associe ClusterRole à un sujet pour tout le cluster

Glissez pour voir

ClusterRole ≠ permissions cluster-wide

Un ClusterRole est une définition de permissions réutilisable. C’est le binding (RoleBinding ou ClusterRoleBinding) qui détermine la portée effective.

Créer un Role

Un Role liste les permissions accordées dans un namespace :

role.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: mon-app
rules:
- apiGroups: [""]           # "" = core API group
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["pods/log"]
  verbs: ["get"]

Les verbes disponibles :

Verbe	Action
get	Lire une ressource
list	Lister les ressources
watch	Observer les changements
create	Créer une ressource
update	Modifier une ressource
patch	Modifier partiellement
delete	Supprimer une ressource

Glissez pour voir

Créer un RoleBinding

Le RoleBinding connecte le Role au ServiceAccount :

rolebinding.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: mon-app
subjects:
- kind: ServiceAccount
  name: app-sa
  namespace: mon-app
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

roleRef est immutable

Vous ne pouvez pas modifier roleRef après création. C’est une protection : un simple update ne peut pas changer silencieusement le rôle accordé. Supprimez et recréez le RoleBinding si nécessaire.

Réutiliser un ClusterRole dans plusieurs namespaces

Cas fréquent : vous avez besoin des mêmes permissions dans plusieurs namespaces, mais pas sur tout le cluster.

Solution : Créez un ClusterRole (définition réutilisable), puis un RoleBinding par namespace.

clusterrole-reusable.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: configmap-reader
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "list", "watch"]

Puis, dans chaque namespace où c’est nécessaire :

rolebinding-namespace-a.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: app-configmap-reader
  namespace: namespace-a
subjects:
- kind: ServiceAccount
  name: app-sa
  namespace: namespace-a
roleRef:
  kind: ClusterRole   # Référence le ClusterRole
  name: configmap-reader
  apiGroup: rbac.authorization.k8s.io

ClusterRole + RoleBinding = permissions par namespace

Cette combinaison est très puissante : vous réutilisez une définition de rôle centrale, mais les permissions restent scopées au namespace du RoleBinding.

Permissions vraiment cluster-wide

Pour un accès global (monitoring, opérateur, controller manager), utilisez ClusterRoleBinding :

clusterrolebinding.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: namespace-reader
rules:
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: app-namespace-reader
subjects:
- kind: ServiceAccount
  name: app-sa
  namespace: mon-app
roleRef:
  kind: ClusterRole
  name: namespace-reader
  apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding = tout le cluster

Un ClusterRoleBinding donne des permissions sur tout le cluster. N’utilisez cette combinaison que pour les composants qui ont réellement besoin d’un accès global.

Associer à un Pod

Spécifiez le ServiceAccount dans le spec du Pod :

pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: mon-pod
  namespace: mon-app
spec:
  serviceAccountName: app-sa
  containers:
  - name: app
    image: mon-image:1.0.0

Pour un Deployment :

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mon-app
spec:
  replicas: 3
  template:
    spec:
      serviceAccountName: app-sa
      containers:
      - name: app
        image: mon-image:1.0.0

Tokens : comprendre le mécanisme moderne

Tokens projetés (bound service account tokens)

Les clusters Kubernetes modernes montent des tokens projetés et liés au Pod. Ces tokens sont :

• À durée limitée — renouvelés automatiquement avant expiration
• Audience-bound — portent une audience contrôlée (typiquement l’API server)
• Liés au Pod — invalidés si le Pod est supprimé

Structure du répertoire monté :

/var/run/secrets/kubernetes.io/serviceaccount/
├── ca.crt     # Certificat CA du cluster
├── namespace  # Namespace du Pod
└── token      # Token JWT (renouvelé automatiquement)

Validation par l'API server

L’API server vérifie la signature, l’expiration, les claims d’audience et la validité des références d’objet liées au token.

Créer un token manuellement

Pour tester une identité ou intégrer un composant externe :

# Token avec durée par défaut (1h)
kubectl create token app-sa -n mon-app

# Token avec durée personnalisée
kubectl create token app-sa -n mon-app --duration=24h

Ne stockez pas ces tokens

Les tokens créés avec kubectl create token sont utiles pour des tests ponctuels ou des intégrations. Ne les stockez pas dans des fichiers ou des variables d’environnement permanentes.

Éviter les anciens tokens en Secret

Les versions antérieures de Kubernetes créaient des tokens statiques dans des Secrets de type kubernetes.io/service-account-token. Ces tokens :

• N’expirent jamais
• Restent valides même après suppression du Pod
• Sont plus difficiles à révoquer

❌ À éviter - token statique legacy

apiVersion: v1
kind: Secret
metadata:
  name: app-sa-token
  annotations:
    kubernetes.io/service-account.name: app-sa
type: kubernetes.io/service-account-token

Préférez les tokens projetés

Évitez de créer ou d’utiliser des tokens statiques de type kubernetes.io/service-account-token sauf cas particulier (compatibilité legacy). Préférez les tokens projetés modernes et kubectl create token.

Désactiver le montage de token

Quand désactiver ?

La checklist sécurité Kubernetes recommande de ne pas monter de token dans les Pods qui n’en ont pas besoin. Exemples :

Type de workload	Besoin de token ?
Frontend statique (nginx, Caddy)	❌ Non
Worker applicatif pur (calcul, ML)	❌ Non
Job batch sans interaction API	❌ Non
Application qui lit des ConfigMaps via API	✅ Oui
Opérateur Kubernetes	✅ Oui
Sidecar qui contacte l’API	✅ Oui

Glissez pour voir

Désactiver au niveau Pod

pod-sans-token.yaml

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  serviceAccountName: frontend-sa
  automountServiceAccountToken: false
  containers:
  - name: nginx
    image: nginx:1.25.4

Désactiver au niveau ServiceAccount

Pour définir un comportement par défaut pour tous les Pods utilisant ce ServiceAccount :

sa-sans-automount.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: frontend-sa
  namespace: mon-app
automountServiceAccountToken: false

Priorité Pod > ServiceAccount

Si les deux sont définis, la valeur au niveau Pod prévaut. Cela permet de désactiver par défaut sur le ServiceAccount et de réactiver ponctuellement sur un Pod spécifique.

Exemple complet

1. Créez les ressources RBAC

   rbac-complet.yaml

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: app-sa
     namespace: mon-app
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: pod-reader
     namespace: mon-app
   rules:
   - apiGroups: [""]
     resources: ["pods"]
     verbs: ["get", "list", "watch"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: read-pods
     namespace: mon-app
   subjects:
   - kind: ServiceAccount
     name: app-sa
     namespace: mon-app
   roleRef:
     kind: Role
     name: pod-reader
     apiGroup: rbac.authorization.k8s.io

   kubectl apply -f rbac-complet.yaml

2. Déployez votre application

   deployment.yaml

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: mon-app
     namespace: mon-app
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: mon-app
     template:
       metadata:
         labels:
           app: mon-app
       spec:
         serviceAccountName: app-sa
         containers:
         - name: app
           image: bitnami/kubectl:1.29.0
           command: ["sleep", "3600"]

3. Vérifiez les permissions

   # Ce que le ServiceAccount peut faire
   kubectl auth can-i list pods \
     --as=system:serviceaccount:mon-app:app-sa \
     -n mon-app
   # Résultat: yes
   
   # Ce qu'il ne peut PAS faire
   kubectl auth can-i delete pods \
     --as=system:serviceaccount:mon-app:app-sa \
     -n mon-app
   # Résultat: no

Cas d’usage courants

Application qui lit des ConfigMaps

rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "list", "watch"]

Opérateur qui gère des Deployments

rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: [""]
  resources: ["events"]
  verbs: ["create", "patch"]

Accès à des Secrets spécifiques uniquement

rules:
- apiGroups: [""]
  resources: ["secrets"]
  resourceNames: ["app-credentials", "db-password"]
  verbs: ["get"]

resourceNames et list

resourceNames limite l’accès à des ressources nommées. Cela fonctionne bien pour get, update, patch, delete. Le verbe list sans resourceNames listera toutes les ressources, mais avec resourceNames, il ne retournera que celles spécifiées.

Bonnes pratiques

Organisation

1. Un ServiceAccount par application — Pas de partage entre applications différentes
2. Convention de nommage — <app>-sa pour identifier facilement
3. Documentation — Annotez vos ServiceAccounts avec leur usage

Sécurité

1. Principe du moindre privilège — N’accordez que les permissions strictement nécessaires
2. Évitez * dans les verbes — Listez explicitement les actions autorisées
3. Utilisez resourceNames quand possible — Limitez l’accès à des ressources spécifiques
4. Préférez Role à ClusterRole — Scope namespace sauf besoin cluster-wide
5. Désactivez automount si inutile — Réduisez la surface d’attaque
6. Préférez les tokens projetés — Évitez les tokens statiques en Secret

Audit

1. Revoyez régulièrement les permissions — Les besoins évoluent
2. Utilisez kubectl auth can-i — Testez ce qu’un ServiceAccount peut faire
3. Activez l’audit logging — Tracez les actions sur l’API

Débugger RBAC

# Lister toutes les permissions d'un ServiceAccount
kubectl auth can-i --list \
  --as=system:serviceaccount:mon-app:app-sa \
  -n mon-app

# Tester une permission spécifique
kubectl auth can-i create deployments \
  --as=system:serviceaccount:mon-app:app-sa \
  -n mon-app

# Voir les RoleBindings d'un namespace
kubectl get rolebindings -n mon-app -o wide

# Voir les ClusterRoleBindings qui concernent un ServiceAccount
kubectl get clusterrolebindings -o wide | grep app-sa

# Créer un token pour tester
kubectl create token app-sa -n mon-app

À retenir

Concept	Utilisation
ServiceAccount	Identité d’un workload dans Kubernetes
Role	Permissions dans un namespace
ClusterRole	Définition de permissions réutilisable
RoleBinding	Associe un rôle à un sujet dans un namespace
ClusterRoleBinding	Associe un rôle à un sujet pour tout le cluster
serviceAccountName	Spécifie l’identité du Pod
automountServiceAccountToken	Contrôle le montage du token
kubectl create token	Crée un token ponctuel pour tests

Glissez pour voir

Règle d’or : Le ServiceAccount est une identité, les permissions viennent de RBAC, et le token ne doit être monté que lorsqu’il y a un vrai besoin.

Prochaines étapes

Secrets Kubernetes Gérez les credentials de vos applications

Network Policies Isolez le trafic réseau entre Pods

Sécuriser un cluster Bonnes pratiques de sécurité Kubernetes

Debug applications Diagnostiquez les problèmes de permissions

×

📖 Voir la documentation →