DEV Community: Manuel Engelhardt

Kubernetes RBAC: Least Privilege statt cluster-admin für CI

Manuel Engelhardt — Fri, 04 Sep 2026 08:44:09 +0000

English readers: this is a German-language post on Kubernetes RBAC least-privilege patterns — Role vs. ClusterRole, right-sizing ServiceAccount bindings for CI pipelines, and where RBAC's authority ends. Originally published at muellermh.blog.

API-Zugriff statt Workload-Verhalten

Admission Control entscheidet, was beim Erstellen eines Pods erlaubt ist. Runtime Security erkennt verdächtiges Verhalten, während ein Container läuft. NetworkPolicies begrenzen, mit wem ein Pod im Netzwerk sprechen darf. RBAC (Role-Based Access Control) setzt eine Ebene davor an: Es regelt, wer überhaupt mit der Kubernetes-API sprechen darf und was er dort tun darf — Pods erstellen, Secrets lesen, Nodes löschen. Das ist auch die Abgrenzung zum Artikel über Kubernetes-Secrets und base64: Dort ging es darum, dass base64 keine Verschlüsselung ist. Hier geht es darum, wer über die API überhaupt an das Secret-Objekt herankommt. Zwei verschiedene Kontrollen, zwei verschiedene Angriffsflächen.

Das eigentliche Risiko: cluster-admin für ServiceAccounts und CI-Pipelines

Eine RBAC-Fehlkonfiguration ist keine exotische Rechteausweitung, sondern eine banale Bequemlichkeitsentscheidung: Eine CI-Pipeline soll deployen, verschiedene Ressourcen in verschiedenen Namespaces anfassen, und irgendwann bindet jemand den ServiceAccount an cluster-admin, um endlich Ruhe vor Rechte-Fehlern zu haben.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: ci-pipeline-admin
subjects:
  - kind: ServiceAccount
    name: ci-deployer
    namespace: ci
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

Das Token dieses ServiceAccounts liegt danach in jedem Pipeline-Lauf — als Klartext-Umgebungsvariable oder als gemountetes Secret. Wer dieses Token in die Hände bekommt — über eine kompromittierte Dependency, einen geleakten Log, eine falsch konfigurierte Artifact-Ablage — hat nicht Zugriff auf die Deploy-Funktion der Pipeline, sondern auf den gesamten Cluster: alle Secrets in allen Namespaces lesen, beliebige privilegierte Pods erstellen und darüber auf den Node ausbrechen, RBAC-Objekte selbst verändern. Das ist kein theoretisches Risiko, das nur in Threat-Modeling-Workshops existiert — es ist die direkte Konsequenz einer Zeile YAML, die in dieser Form leicht entsteht.

Role vs. ClusterRole: RBAC nach dem Least-Privilege-Prinzip zuschneiden

Der Gegenentwurf ist Scoping auf das, was die Pipeline tatsächlich braucht. Eine Role gilt nur innerhalb eines Namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: deployer
  namespace: app
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch", "update", "patch"]
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]

Gebunden wird sie über eine RoleBinding, ebenfalls im selben Namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ci-deployer-binding
  namespace: app
subjects:
  - kind: ServiceAccount
    name: ci-deployer
    namespace: ci
roleRef:
  kind: Role
  name: deployer
  apiGroup: rbac.authorization.k8s.io

Damit kann der ServiceAccount ci-deployer Deployments im Namespace app aktualisieren — und sonst nichts. Kein Zugriff auf billing, kein Zugriff auf Secrets, kein Zugriff auf Cluster-weite Ressourcen wie Nodes oder Namespaces selbst.

Für genau solche Cluster-weiten Ressourcen — oder wenn dieselbe Rolle über viele Namespaces hinweg gebraucht wird — gibt es ClusterRole und ClusterRoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-reader-clusterwide
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: monitoring-pod-reader
subjects:
  - kind: ServiceAccount
    name: monitoring
    namespace: monitoring
roleRef:
  kind: ClusterRole
  name: pod-reader-clusterwide
  apiGroup: rbac.authorization.k8s.io

Der Unterschied liegt nicht im Namen, sondern im Scope: Ein RoleBinding kann auch auf eine ClusterRole verweisen (dann gilt sie nur im Namespace der Binding), ein ClusterRoleBinding dagegen wirkt immer clusterweit. cluster-admin ist selbst nur eine besonders weit gefasste ClusterRole — gebunden über ClusterRoleBinding, wirkt sie überall.

Rechte messen statt schätzen

Bevor du eine Rolle zuschneidest, lohnt sich der Blick auf das, was ein Subjekt aktuell tatsächlich darf. kubectl auth can-i --list mit --as simuliert einen anderen Identitätsträger, ohne dass du dessen Token brauchst:

kubectl auth can-i --list \
  --as=system:serviceaccount:ci:ci-deployer -n app

# gezielter Einzel-Check auf dieselbe Identität
kubectl auth can-i delete secrets \
  --as=system:serviceaccount:ci:ci-deployer -n app

Das beantwortet "was darf dieses Subjekt". Die umgekehrte Frage — "wer darf diese Aktion" — beantworten kubectl auth can-i allein nicht, dafür aber Zusatzwerkzeuge wie rbac-lookup (Fairwinds) oder kubectl-who-can (Aqua Security): Beide durchsuchen alle Rollen und Bindings im Cluster und listen auf, welche Subjekte ein bestimmtes Verb auf eine bestimmte Ressource anwenden dürfen. Gerade bei gewachsenen Clustern mit vielen ServiceAccounts ist das der einzige praktikable Weg, cluster-admin-Bindings überhaupt zu finden, statt sie zu erraten.

Aggregated ClusterRoles: erweiterbar ohne Rechteausweitung

Wenn ein Controller oder ein CRD eigene Ressourcen mitbringt, die in bestehende Standardrollen wie view oder edit einsortiert werden sollen, muss dafür nicht die eingebaute ClusterRole editiert werden. Kubernetes' Standardrollen selbst nutzen dafür Aggregation über Label-Selektoren:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: custom-metrics-reader
  labels:
    rbac.authorization.k8s.io/aggregate-to-view: "true"
rules:
  - apiGroups: ["metrics.k8s.io"]
    resources: ["pods"]
    verbs: ["get", "list"]

Diese ClusterRole wird über das Label automatisch in die eingebaute view-Rolle eingemischt, sobald sie existiert. Der Vorteil: Erweiterbarkeit ohne die Basis-Rolle direkt zu verändern und ohne das Risiko, bei einem Merge versehentlich mehr Rechte einzuführen als beabsichtigt.

Wo RBAC aufhört

RBAC regelt, wer über die API worauf zugreifen darf — es sagt nichts darüber aus, was innerhalb eines Pods mit bereits legitim erteilten Rechten passiert. Ein Pod, dessen ServiceAccount berechtigt ist, Secrets im eigenen Namespace zu lesen, kann diese Rechte über eine Remote-Code-Execution-Schwachstelle in der Anwendung genauso nutzen wie über den vorgesehenen Code-Pfad. RBAC hat in diesem Fall exakt das durchgesetzt, was in der Rolle stand — das Problem liegt dann entweder in einer zu weit gefassten Rolle (ein Least-Privilege-Problem, das sich mit den Mitteln aus diesem Artikel beheben lässt) oder darin, dass der Angriff einen legitim erlaubten Zugriff über einen Code-Pfad ausnutzt, den keine API-Autorisierung einschränken kann. Genau hier ergänzen sich die anderen Bausteine dieser Serie: Admission Control verhindert von vornherein, dass Pods mit unnötig weiten Rechten oder Privilegien überhaupt starten, Runtime Security erkennt, wenn ein Pod sich anders verhält als erwartet. RBAC ist die Grundlage, nicht die vollständige Antwort.

Woran es hier weitergeht

Least-Privilege-Reviews an RBAC-Bindings sind kein einmaliges Audit, sondern ein wiederkehrendes Thema in dieser Serie — Rollen wachsen mit jeder neuen Pipeline-Anforderung, und niemand entfernt Rechte von sich aus wieder.

OIDC Workload Identity Federation in CI/CD: das Ende langlebiger Cloud-Secrets

Manuel Engelhardt — Thu, 03 Sep 2026 10:42:35 +0000

This article is in German. It covers OIDC Workload Identity Federation for CI/CD pipelines (AWS, GCP, Azure): how the trust handshake works, real IAM trust-policy and workflow snippets, and the pitfalls that keep long-lived cloud secrets alive during migration. Canonical version on my blog: muellermh.blog.

Ein AWS Access Key in einem GitHub Actions Secret ist ein Passwort, das nie abläuft, bis jemand es manuell rotiert. Genau das macht ihn zum bevorzugten Ziel: er liegt fest an einem Ort, gilt oft über Monate, und die Rechte dahinter sind meist großzügiger zugeschnitten, als der einzelne Workflow braucht. Wird er kopiert, aus einem Log ausgelesen oder aus einem kompromittierten Dependency-Paket exfiltriert, funktioniert er so lange weiter, bis jemand den Diebstahl bemerkt und den Key widerruft. Genau dieses Muster, gespeicherte, langlebige Credentials in der Pipeline, ist der wiederkehrende Fund in Berichten zu CI/CD-Kompromittierungen.

OIDC Workload Identity Federation dreht das Modell um. Statt eines gespeicherten Secrets stellt der CI-Anbieter pro Lauf ein signiertes JSON Web Token aus. Die Cloud prüft dieses Token gegen eine Trust Policy und stellt im Gegenzug ein kurzlebiges Zugriffstoken aus, das nur für die Dauer des Jobs gilt. Es gibt kein Secret mehr, das irgendwo liegt und gestohlen werden kann, weil es keins mehr gibt.

Wie der Trust Handshake abläuft

GitHub Actions tritt dabei als OpenID Connect Identity Provider auf. Für jeden Job, der id-token: write in seinen Permissions gesetzt hat, kann der Workflow ein JWT anfordern. Dieses Token enthält unter anderem folgende Claims:

iss: https://token.actions.githubusercontent.com
sub: repo:meine-org/mein-repo:ref:refs/heads/main
aud: sts.amazonaws.com
repository: meine-org/mein-repo
workflow: deploy.yml

Die Cloud Seite, egal ob AWS, GCP oder Azure, kennt den öffentlichen Schlüssel von token.actions.githubusercontent.com und kann die Signatur des Tokens prüfen, ohne dass GitHub und die Cloud vorher ein gemeinsames Secret ausgetauscht haben. Danach entscheidet eine Trust Policy anhand der Claims im Token, ob und mit welcher Rolle Zugriff gewährt wird. Zwei Claims tragen hier die eigentliche Sicherheitsentscheidung: sub bindet den Zugriff an ein konkretes Repository, einen Branch oder ein Environment, aud stellt sicher, dass das Token wirklich für diese eine Cloud ausgestellt wurde und nicht für einen anderen Dienst umgewidmet werden kann. Das ausgestellte Zugriffstoken selbst ist danach nur für die Laufzeit des Jobs gültig, nicht für den nächsten Lauf und nicht wiederverwendbar, wenn der Job längst durch ist.

AWS in der Praxis: Trust Policy und Workflow

Auf der AWS Seite richtest du einmalig einen OIDC Identity Provider für token.actions.githubusercontent.com ein und hängst eine IAM Rolle mit passender Trust Policy daran:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:meine-org/mein-repo:ref:refs/heads/main"
        }
      }
    }
  ]
}

Im Workflow selbst brauchst du dafür kein einziges gespeichertes Secret mehr:

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/gh-actions-deploy
          aws-region: eu-central-1
      - run: aws s3 ls

Die Action fordert das JWT selbst an, tauscht es gegen ein STS Token, und exportiert die resultierenden temporären Zugangsdaten als Umgebungsvariablen für die folgenden Steps. Nach Ende des Jobs sind sie wertlos.

GCP und Azure kurz skizziert

Bei Google Cloud heißt der äquivalente Mechanismus Workload Identity Federation: du legst einen Workload Identity Pool und darin einen Provider an, der GitHub als Identity Provider akzeptiert, mit einer Attribute Condition, die wieder auf assertion.repository prüft. Bei Azure trägst du an einer App Registrierung eine Federated Credential ein, mit token.actions.githubusercontent.com als Issuer und demselben sub Muster wie bei AWS. In beiden Fällen ist die Grundidee identisch zu AWS: kein gespeichertes Secret, sondern eine Trust Beziehung, die pro Lauf neu geprüft wird.

Typische Fallstricke bei der Migration

Der häufigste Fehler ist ein zu weiter sub Wildcard. Eine Bedingung wie repo:meine-org/*:* erlaubt jedem Repository und jedem Branch der Organisation, dieselbe Rolle zu übernehmen, das ist im Ergebnis kaum enger als ein geteilter Access Key. Die Bedingung gehört auf ein konkretes Repository und, wo möglich, auf ein Environment oder einen Branch eingeschränkt, nicht auf die ganze Organisation.

Der zweite Fehler ist eine Trust Policy ohne aud Prüfung. Fehlt die Bedingung auf token.actions.githubusercontent.com:aud, verlässt sich die Rolle allein auf sub, und ein Token, das eigentlich für einen anderen Zweck ausgestellt wurde, aber zufällig einen passenden sub Claim trägt, würde ebenfalls akzeptiert. Beide Bedingungen gehören zusammen in die Policy, nicht nur eine davon.

Der dritte Punkt betrifft die Migration selbst. Alte Pipelines laufen häufig noch eine Weile mit dem gespeicherten Access Key parallel zur neuen OIDC Rolle, während die Umstellung getestet wird. Genau in dieser Übergangsphase bleibt der alte Key aktiv und wird oft schlicht vergessen, sobald die neue Rolle einmal läuft. Ohne einen festen Termin, an dem der alte IAM User deaktiviert und der Key gelöscht wird, bleibt die eigentliche Angriffsfläche, die die Migration beseitigen sollte, einfach liegen.

Wie du Rechte in der Pipeline generell auf das Nötige zuschneidest, unabhängig vom Auth Mechanismus, ist eine eigene Frage, die OIDC Workload Identity nicht beantwortet. Es ersetzt darin genau einen Baustein, das gespeicherte Cloud Secret, nicht die Sorgfalt bei der Rechtevergabe selbst.

GitSecOps: Why Compliance Only Works When Teams Can Prove What They Deliver — Not Just Promise It

Manuel Engelhardt — Mon, 24 Nov 2025 16:05:50 +0000

Many organizations are working hard to meet NIS2, DORA, or supply-chain-security requirements.
And yet they still fail at a point that seems almost trivial:

👉 They can’t technically prove what actually happened.

Auditors ask:
“Show me when, by whom, why, how, and with what something was deployed.”

And the usual reality is:
— 7 tools
— 5 ticket systems
— 0 unified evidence
— 100% headache

The solution is simple — but hard to enforce:

Everything that matters must live versioned in Git.

Code

IaC

Policies-as-Code

Pipelines

Evidence

Risk decisions

Recovery paths

Not scattered.
Not “documented somewhere.”
But commit-based, signed, traceable.

That turns Git into the Technical Source of Trust.

And suddenly NIS2 & DORA become things you can prove, not just answer vaguely.

🔐 NIS2

End-to-end automated traceability across the entire software supply chain — without manual heroism.

🧩 DORA

Operational resilience by design through reproducible recovery paths and verifiable risk decisions.

🇪🇺 Digital Sovereignty

Sovereign code hosting: the technical proof that you operate independently, controllably, and audit-ready.

What GitSecOps Changes in Practice

No more “documentation theater”

Auditors review technical evidence — not slide decks

Dev, Sec, and Ops speak from the same data

Every decision is versioned

Every deviation is visible

Every delivery is auditable

Why I'm Writing About This

I build systems that prove trust — not promise it.
And GitSecOps is the first approach that puts compliance on a technical foundation without slowing down teams.

If you want to see how GitSecOps can be implemented in practice, I regularly share patterns, examples, and real use cases here.