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

La sortie est un JWT signé par l'API server. En décodant son header avec base64, vous obtenez l'algorithme et l'identifiant de clé :

kubectl create token app-sa -n mon-app | cut -d. -f1 | base64 -d
# {"alg":"RS256","kid":"LxkUHA9ITF5w3mg80D102dT48j1E4k1DsNIgUcHOrRg"}

Le payload (deuxième segment) contient les claims standard : aud (audience), exp (expiration), iss (issuer), sub (sujet) et un bloc kubernetes.io qui rattache le token au namespace et au ServiceAccount.

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.

Signature externe via KMS (GA en Kubernetes 1.36)

Par défaut, l'API server signe les tokens ServiceAccount avec une clé privée stockée localement (--service-account-signing-key-file). Cette clé ne quitte jamais le control plane, mais elle reste un secret hautement sensible : sa compromission permettrait de forger n'importe quelle identité de pod.

Kubernetes 1.36 fait passer en GA la signature externe (KEP-5066) : l'API server délègue l'opération de signature à un service externe via un endpoint Unix domain socket. La clé privée vit alors dans un KMS (HashiCorp Vault, AWS KMS, GCP KMS, Azure Key Vault…) et n'est jamais exposée au control plane.

Architecture

┌──────────────────────────┐         ┌─────────────────────┐
│ kube-apiserver           │  signer │ Service de signature│
│   --service-account-     │ ───────►│   (Vault, KMS, …)   │
│   signing-endpoint=...   │  via    │                     │
│                          │  UDS    │   clé privée jamais │
│                          │ ◄───────│   exposée au control│
└──────────────────────────┘ token   │   plane             │
                             signé   └─────────────────────┘

Configurer l'API server

Sur kubeadm, ajouter dans /etc/kubernetes/manifests/kube-apiserver.yaml :

spec:
  containers:
  - name: kube-apiserver
    command:
    - kube-apiserver
    - --service-account-signing-endpoint=unix:///var/run/k8s-signer/signer.sock
    # Garder --service-account-issuer pour la cohérence des claims
    - --service-account-issuer=https://kubernetes.default.svc.cluster.local
    volumeMounts:
    - name: signer-socket
      mountPath: /var/run/k8s-signer
  volumes:
  - name: signer-socket
    hostPath:
      path: /var/run/k8s-signer
      type: Directory

Le service de signature (Vault avec le plugin vault-plugin-secrets-kubernetes ou un binaire maison conforme au protocole gRPC signing.k8s.io/v1) écoute sur la même socket Unix.

Cas d'usage

La signature externe est pertinente pour :

• Les déploiements zero-trust où aucun secret ne doit résider sur les nœuds.
• Les environnements multi-clusters qui veulent une autorité de signature unique (un seul KMS pour signer les tokens de N clusters).
• Les contraintes de conformité (PCI-DSS, FedRAMP, eIDAS) qui exigent que les clés privées soient gérées par un module HSM.

Compatibilité avec les tokens existants

L'activation de la signature externe est transparente côté workloads : les tokens projetés montés dans les pods continuent d'avoir le même format JWT RS256, le même issuer et la même structure de claims. Seul le porteur de la clé privée change. Aucune adaptation des SDK Kubernetes (client-go, fabric8, kubernetes-python) n'est nécessaire.

Sur cluster managé

EKS, GKE et AKS exposent leur propre intégration KMS pour les tokens ServiceAccount (souvent activée par défaut côté provider). Sur ces plateformes, le flag --service-account-signing-endpoint n'est pas configurable côté client : la signature externe est gérée par le contrôle plane managé.

É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

Comprendre les Admission Controllers

Pourquoi c'est important pour CKAD

Le blueprint CKAD demande de comprendre authentication, authorization et admission control. Même si RBAC autorise votre Pod, un admission controller peut le refuser.

Le flux complet d'une requête API

Quand vous créez un Pod, la requête passe par 3 étapes :

┌──────────────────────────────────────────────────────────────────┐
│                     API Server Request Flow                       │
├──────────────────────────────────────────────────────────────────┤
│  1. AUTHENTICATION : Qui êtes-vous ?                              │
│     → Token ServiceAccount, certificat, OIDC...                   │
│                                                                   │
│  2. AUTHORIZATION : Avez-vous le droit (RBAC) ?                   │
│     → Role/ClusterRole vérifié                                    │
│                                                                   │
│  3. ADMISSION CONTROL : La ressource est-elle conforme ?          │
│     → Validating/Mutating webhooks, PSA, quotas...                │
└──────────────────────────────────────────────────────────────────┘

Pourquoi RBAC OK ≠ Pod créé

Problème	RBAC	Admission	Résultat
Pas de Role pour créer des Pods	❌	—	Forbidden
Pod privilégié dans namespace restricted	✅	❌ PSA	Rejected
ResourceQuota dépassé	✅	❌ Quota	Rejected
Image non signée	✅	❌ Policy	Rejected

Glissez pour voir

Pod Security Admission (PSA)

PSA remplace les anciennes PodSecurityPolicies. Il applique les Pod Security Standards (PSS) au niveau namespace :

Niveau	Ce qui est autorisé	Cas d'usage
privileged	Tout	Pods système, debug
baseline	Pas de privileges dangereux	Applications standards
restricted	Configuration la plus sécurisée	Production, multi-tenant

Glissez pour voir

# Vérifier le niveau PSA d'un namespace
kubectl get namespace mon-app -o yaml | grep pod-security

Si votre Pod est refusé avec une erreur mentionnant pod-security.kubernetes.io, c'est PSA qui bloque.

Diagnostiquer un refus Admission

# L'erreur apparaît dans le message de rejet
kubectl apply -f pod.yaml
# Error: admission webhook "validate.policy" denied the request...

# Ou via describe sur le parent (Deployment, Job...)
kubectl describe deployment mon-app -n mon-namespace
# Events:
#   Warning  FailedCreate  ... violates PodSecurity "restricted:latest"

Ce que le développeur doit savoir

Admission Controller	Ce qu'il vérifie	Comment s'adapter
PSA	Privileges, capabilities, volumes	Respecter les Pod Security Standards
ResourceQuota	CPU/mémoire du namespace	Vérifier les quotas disponibles
LimitRange	Requests/limits par Pod	Définir requests/limits conformes
ValidatingWebhook	Règles custom (Kyverno, Gatekeeper)	Consulter les policies actives

Glissez pour voir

En cas de doute

1. Vérifiez les labels PSA du namespace (kubectl get ns <ns> --show-labels)
2. Consultez les ResourceQuotas (kubectl describe quota -n <ns>)
3. Demandez les policies actives à votre équipe plateforme

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

Testez vos connaissances

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

7 questions

5 min.

80% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

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 →