Kubernetes ServiceAccount

De wiki.nexiat.fr
Aller à la navigation Aller à la recherche
Fiche express
Type Identité pour les processus s'exécutant dans un Pod
Autorisation RBAC (Role/ClusterRole + RoleBinding/ClusterRoleBinding)
Consommation Jeton monté automatiquement dans le Pod
Voir aussi Kubernetes secrets · Kubernetes ConfigMaps

Un ServiceAccount est l'objet Kubernetes utilisé par les processus tournant à l'intérieur des Pods pour s'authentifier auprès de l'API server — l'équivalent, côté machine, de ce qu'un compte utilisateur est pour un humain. Il est indissociable du système RBAC (Role-Based Access Control) qui définit ce que ce compte a le droit de faire.

RBAC : Role, ClusterRole et bindings

Kubernetes distingue la portée des permissions :

  • Role — portée limitée à un namespace.
  • ClusterRole — portée sur l'ensemble du cluster.
  • RoleBinding / ClusterRoleBinding — associent respectivement un Role ou un ClusterRole à un sujet (utilisateur, groupe ou ServiceAccount), avec le même principe de portée namespace/cluster.
kubectl apply -f role.yml
kubectl apply -f rolebinding.yml

Pour vérifier les droits effectifs d'un sujet :

# Droits de l'utilisateur courant
kubectl auth can-i create pods --all-namespaces

Créer et utiliser un ServiceAccount

Création déclarative ou impérative :

# Déclarative
kubectl create -f mon-serviceaccount.yml

# Impérative
kubectl create sa mon-serviceaccount -n default
apiVersion: v1
kind: ServiceAccount
metadata:
  name: mon-serviceaccount
  namespace: default

Lister et inspecter :

kubectl get sa
kubectl describe sa mon-serviceaccount

Attacher des droits via un RoleBinding

Un ServiceAccount sans binding n'a par défaut que des droits minimaux. On lui attache des permissions en le référençant comme sujet d'un RoleBinding (ou ClusterRoleBinding) :

kubectl create -f sa-role-binding.yml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: sa-lecture-pods
  namespace: default
subjects:
  - kind: ServiceAccount
    name: mon-serviceaccount
    namespace: default
roleRef:
  kind: Role
  name: lecteur-pods
  apiGroup: rbac.authorization.k8s.io

Utilisation dans un Pod

Un Pod référence son ServiceAccount via spec.serviceAccountName ; à défaut, il utilise le ServiceAccount default du namespace. Kubernetes monte automatiquement un jeton dans le conteneur (généralement sous /var/run/secrets/kubernetes.io/serviceaccount), que le processus applicatif utilise pour s'authentifier auprès de l'API server.

Simuler un contexte de permissions

Pour tester le comportement d'un ServiceAccount précis sans en changer réellement le contexte d'exécution, kubectl permet de « jouer » une commande comme si elle provenait de ce compte :

kubectl get pods -n web --as=system:serviceaccount:web:mon-automation

Utile pour valider qu'un binding RBAC produit bien l'effet attendu avant de le déployer.

Voir aussi