Kubernetes ServiceAccount: Identität für Pods – einfach erklärt

Ein ServiceAccount ist die Identität, unter der sich Prozesse in einem Pod gegenüber der Kubernetes-API authentifizieren. Während echte Menschen sich als Benutzer anmelden, treten Anwendungen und Automatisierungen als ServiceAccount auf. Jeder Namespace besitzt automatisch einen Default-ServiceAccount namens default.

Vom Konto zum Token

Wird ein Pod ohne Angabe angelegt, nutzt er den default-ServiceAccount seines Namespace. Über spec.serviceAccountName weist man einem Pod ein eigenes Konto zu:

apiVersion: v1
kind: Pod
metadata:
  name: mein-pod
spec:
  serviceAccountName: build-robot
  containers:
  - name: app
    image: nginx

Für die Authentifizierung erhält der ServiceAccount ein Token. Seit Kubernetes 1.24 (2022) sind die früheren dauerhaften Secret-Tokens abgeschafft: Der kubelet projiziert dem Pod stattdessen ein gebundenes, zeitlich begrenztes Token als Volume ein (projiziertes ServiceAccount-Token). Es ist an den Pod gebunden, trägt eine begrenzte Gültigkeit und verliert seine Gültigkeit, sobald Pod oder ServiceAccount gelöscht werden – das schließt die frühere Sicherheitslücke lang lebender, nicht ablaufender Tokens.

Wofür ServiceAccounts wichtig sind

  • API-Zugriff aus dem Pod: Werkzeuge wie Helm-Charts, CI/CD-Agenten oder eigene Controller sprechen über das Token die Kubernetes-API an.
  • Image-Pull: Über imagePullSecrets lassen sich Registry-Zugänge einem ServiceAccount zuordnen.
  • Kombination mit RBAC: Ein ServiceAccount allein kann noch nichts – erst eine Role- oder ClusterRole-Bindung über RBAC gibt ihm Rechte (Least Privilege).

Im Manifest einer RoleBinding erscheint der ServiceAccount als Subjekt im Format system:serviceaccount:<namespace>:<name>. So wird die Anwendung zu einem vollwertigen, berechtigten API-Client – ohne dass ein menschliches Konto oder ein Admin-Zertifikat im Pod liegt.

Sicherheits-Einstellungen

  • automountServiceAccountToken: mit false lässt sich das automatische Einhängen des Tokens unterbinden – sinnvoll für Pods, die die API nicht brauchen.
  • Eigene Konten statt default: pro Anwendung ein eigener ServiceAccount mit minimalen Rechten ist sauberer als der gemeinsame Default-Account.
  • Audience & Laufzeit: projizierte Tokens lassen sich mit audience (Zielgruppe) und Gültigkeitsdauer versehen; für externe Dienste wird der Token per TokenRequest-API oder kubectl create token ausgegeben. Wer die Rechte eines ServiceAccount prüfen will, nutzt die Impersonation mit --as.

Vertrauliche Zugangsdaten wie Registry-Passwörter gehören übrigens nicht in ServiceAccounts, sondern in Secrets. Die technische Grundlage der Tokens sind JWTs, die der kube-apiserver signiert und validiert. Wie die zugehörigen Rechte strukturiert werden, erklärt der Artikel Kubernetes Role.