🚀 Platform Engineer Lektion 34/50 ~7 Min. Experte

Identity, SSO und Secrets als Plattform-Service

Zentralisierte Identity, Vault, External Secrets und Workload Identity.

Lernziele

Nach dieser Lektion kannst du erklären, warum Identity und Secrets zentrale Plattform-Services sind, wie SSO, Vault, External Secrets Operator und Workload Identity zusammenspielen und welche Trade-offs zwischen Zentralisierung und Team-Autonomie du setzt. Du kannst typische Secret-Anti-Patterns erkennen und in Interviews ein kohärentes Secrets-Lifecycle-Konzept skizzieren.

Das Problem: Secrets überall, Kontrolle nirgends

In einer typischen Organisation ohne zentrale Secrets-Schicht findest du Datenbankpasswörter in .env-Dateien im Git-Repo (auch wenn sie in .gitignore stehen — irgendwann committed jemand), API-Keys als Base64 in Kubernetes-Secrets (nicht verschlüsselt in etcd, wenn Encryption-at-Rest fehlt), TLS-Zertifikate per E-Mail und Service-Accounts mit JSON-Keys auf dem Laptop des Entwicklers. Rotation bedeutet: 40 Teams manuell informieren, hoffen, dass alle mitmachen, und drei Wochen später im Incident feststellen, dass Team 17 noch das alte Passwort nutzt.

Identity ist das gleiche Chaos auf einer Ebene höher: Jedes Tool hat eigene User-Accounts, MFA-Regeln und Offboarding-Prozesse. Ein Entwickler verlässt das Unternehmen — wer stellt sicher, dass sein Zugang zu Grafana, Harbor, Argo CD und dem internen Portal gleichzeitig entfällt? Ohne zentrale Identity ist Offboarding ein manuelles Multi-System-Ritual, das garantiert etwas übersieht.

Als Platform Engineer lieferst du Identity und Secrets als Service: ein SSO für Menschen, ein Vault für Secrets, External Secrets für die Kubernetes-Anbindung und Workload Identity, damit Pods ohne langlebige Credentials auf Cloud-Ressourcen zugreifen.

SSO: eine Identität für Menschen

Single Sign-On über OIDC oder SAML verbindet alle Plattform-Tools an einen Identity Provider — Keycloak, Azure AD, Okta oder Google Workspace. Der Entwickler loggt sich einmal ein und erreicht Portal, Grafana, Git-Plattform und Registry mit derselben Identität.

Was das Platform-Team besitzt: Integration der Tools als OIDC-Relying-Parties, Gruppen-Mapping (platform-admins, team-checkout) und RBAC-Anbindung. Was es nicht besitzt: Die HR-getriebene User-Lifecycle-Verwaltung — aber es muss den IdP-Webhook oder SCIM-Provisioning nutzen, damit Offboarding automatisch alle Tool-Zugänge entzieht.

Zwei Regeln, die du durchsetzen solltest: Kein lokales Passwort in Plattform-Tools (nur SSO), und Gruppen statt Einzel-User in RBAC-Bindings — sonst pflegt jemand ein Excel-Sheet mit 400 Einträgen.

Vault und External Secrets: der Secrets-Lifecycle

HashiCorp Vault (oder ein kompatibler Secrets-Manager) ist die Single Source of Truth für Secrets. Menschen und Maschinen holen sich kurzlebige Credentials — nicht aus Dateien, sondern per API. Dynamische Secrets (z. B. eine PostgreSQL-Rolle, die nach einer Stunde abläuft) sind das stärkste Muster: selbst bei Leak ist der Schaden begrenzt.

Der External Secrets Operator (ESO) überbrückt Vault und Kubernetes. Er synchronisiert Secrets aus Vault in Kubernetes-Secret-Objekte — oder besser: er nutzt den CSI-Driver, der Secrets direkt als Volume mountet, ohne sie in etcd zu persistieren. Der Entwickler deklariert im Git:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: checkout-api-db
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: checkout-api-db
  data:
    - secretKey: password
      remoteRef:
        key: secret/data/teams/checkout/db
        property: password

Das Platform-Team betreibt Vault, den ClusterSecretStore und die Auth-Methode (Kubernetes-ServiceAccount-Auth oder AppRole). Das Team besitzt nur den Pfad in Vault und die ExternalSecret-Ressource im Git.

Workload Identity: Pods ohne langlebige Keys

Workload Identity (AWS IRSA, GCP Workload Identity, Azure Workload Identity) erlaubt einem Pod, sich über seinen Kubernetes-ServiceAccount als Cloud-Identität auszuweisen — ohne Access Keys in Secrets. Der Pod bekommt ein kurzlebiges Token vom Cloud-Provider und kann S3, Pub/Sub oder Key Vault erreichen.

Das Muster ersetzt das klassische „JSON-Key als Kubernetes-Secret” — ein Anti-Pattern, das Rotation unmöglich macht und bei jedem Pod-Schedule das Leak-Risiko erhöht. Die Plattform stellt das Mapping (ServiceAccount-Annotation → Cloud-Rolle) als Template bereit; Teams beantragen Berechtigungen, sie bekommen kein Roh-Credential.

Rotation, Audit und Break-Glass

Drei Betriebsprozesse trennen einen Secrets-Service von „wir haben Vault installiert”:

Rotation: Automatisch für dynamische Secrets; für statische Secrets (TLS-Zertifikate, Third-Party-API-Keys) ein dokumentierter Zyklus mit ESO-Refresh. Die Pipeline aus Lektion 33 darf nie Secrets in Images backen — Rotation im Image ist ein Rebuild-Zwang für alle Versionen.

Audit: Vault Audit-Log, wer wann welches Secret gelesen hat. Nicht zur Mikrokontrolle, sondern für Incident-Response und Compliance.

Break-Glass: Ein Notfall-Zugang, wenn Vault selbst down ist — versiegelt, dual-controlled, mit Pflicht-Postmortem. Ohne Break-Glass blockiert ein Vault-Incident alle Deployments; mit schlechtem Break-Glass hast du ein permanentes Hintertür-Credential.

Praxis: Secret-Flow für einen neuen Service

Team Checkout deployt checkout-api und braucht ein Datenbankpasswort:

Vault-Pfad anlegen: Platform-Team oder Self-Service-API erstellt secret/data/teams/checkout/db mit Rotation-Policy.
ExternalSecret committen: Team legt die ExternalSecret-Ressource ins GitOps-Repo.
ESO synchronisiert: Innerhalb des refreshInterval erscheint das Kubernetes-Secret — oder der CSI-Mount ist verfügbar.
Pod referenziert Secret: Deployment nutzt envFrom.secretRef oder Volume-Mount — kein Klartext im Git.
Rotation testen: Passwort in Vault rotieren, nach Refresh-Zeit prüfen, ob der Pod das neue Secret nutzt (ggf. Rollout-Restart).

Wenn Schritt 2–5 ohne Ticket beim Platform-Team funktionieren, ist Secrets-as-a-Service real.

Typische Stolperfallen

Kubernetes-Secrets als Sicherheitskonzept: Base64 ist keine Verschlüsselung. Ohne Encryption-at-Rest in etcd und ohne Rotation sind sie ein Trostpflaster.

Vault als Single Point of Failure ohne HA: Vault down = keine neuen Deployments, keine Secret-Rotation. Cluster-Modus, Auto-Unseal und Monitoring sind Pflicht.

Zu breite Vault-Policies: Ein Policy read /* für alle Teams negiert Tenant-Trennung. Policies pro Team und Environment, nicht pro Organisation.

ESO-Refresh ohne Rollout-Strategie: Pods cachen Environment-Variablen beim Start. Nach Rotation braucht es Rolling Restart oder Reloader — sonst läuft die alte Version stundenlang.

SSO ohne Gruppen-Mapping: Jeder User einzeln in Grafana eingetragen — skaliert nicht, überlebt kein Offboarding.

Interview-Vorbereitung

Auf „Wie managst du Secrets in einer Kubernetes-Plattform?” antwortest du: Problem (Secrets in Git, keine Rotation, Offboarding-Lücken) → Architektur (Vault als Source of Truth, ESO für K8s-Sync, Workload Identity für Cloud) → Lifecycle (dynamische Secrets, Audit, Break-Glass) → Grenze (Teams besitzen Pfade und ExternalSecrets, Plattform besitzt Vault und Auth).

Follow-ups:

„Vault vs. Cloud-Native Secrets Manager?” — Vault wenn Multi-Cloud oder einheitliche API nötig; Cloud-SM wenn Single-Cloud und weniger Betriebsaufwand — oft Kombination mit ESO.
„Wie verhinderst du Secrets in Git?” — Pre-Commit-Hooks, CI-Scanning (gitleaks, trufflehog), Policy-as-Code — Detection ergänzt, ersetzt aber nicht Vault.
„Was ist Workload Identity?” — Pod authentifiziert sich über ServiceAccount-Token beim Cloud-Provider, erhält kurzlebige Rolle — keine statischen Keys.

Zusammenfassung

Identity und Secrets als Plattform-Service zentralisieren SSO für Menschen und Vault für Maschinen. External Secrets Operator und Workload Identity bringen Credentials in Pods, ohne sie in Git oder etcd zu persistieren. Rotation, Audit und Break-Glass sind Betriebsprozesse, nicht Nice-to-have. Ohne Gruppen-basiertes RBAC und ohne klare Vault-Policy-Trennung pro Team wird Zentralisierung zum Sicherheits- und Bottleneck-Risiko.

Die nächste Lektion erweitert das Service-Modell auf persistente Daten: DBaaS, Kafka-as-a-Service und Data-Platform-Patterns auf Kubernetes.