Keycloak als souveräner Identity Provider für Cloud-Plattformen

In Gesprächen über souveräne Cloud geht es meist um Rechenzentren, Standorte und Verträge. Über den Identity Provider spricht selten jemand, obwohl er bei jedem einzelnen Zugriff mitentscheidet.

Ein Gedankenexperiment: Ihre Cluster stehen in einem deutschen Rechenzentrum, die Daten verlassen das Land nie. Angemeldet wird sich aber über den Identitätsdienst eines US-Hyperscalers. Fällt dieser Dienst aus, ändert der Anbieter seine Bedingungen oder sperrt den Mandanten, kommt niemand mehr an die Plattform, auch Ihr eigenes Betriebsteam nicht. Wie souverän ist diese Plattform?

Wir halten den IdP deshalb für eine der wichtigsten Komponenten einer souveränen Cloud. In unseren Projekten ist das in der Regel Keycloak.

Warum Keycloak

Keycloak ist Open Source unter der Apache-2.0-Lizenz, wird maßgeblich von Red Hat entwickelt und ist seit 2023 ein Incubating-Projekt der CNCF. Für uns entscheidend sind drei Eigenschaften.

Erstens spricht Keycloak die Standards, die alle anderen Komponenten auch sprechen: OpenID Connect, OAuth 2.0 und SAML 2.0. Kubernetes, die Kubermatic Kubernetes Platform, Git-Server, Monitoring und die meisten Fachanwendungen lassen sich damit anbinden, ohne dass eine davon Keycloak kennen muss. Tauscht man den IdP irgendwann aus, ändern sich Endpunkte und Zertifikate, aber nicht die Integration.

Zweitens kann Keycloak mit dem umgehen, was schon da ist. Benutzer aus Active Directory oder LDAP werden föderiert, nicht kopiert. Externe Identitätsanbieter, etwa der IdP einer Partnerbehörde oder eines Kunden, lassen sich per OIDC oder SAML anbinden.

Drittens ist Keycloak mandantenfähig. Realms trennen Mandanten vollständig, mit eigenen Benutzern, Rollen und Login-Seiten. Für Plattformen mit vielen Kundenorganisationen gibt es seit Version 26 zusätzlich das Organizations-Feature, mit dem mehrere Organisationen innerhalb eines Realms verwaltet werden.

Kubernetes an Keycloak anbinden

Der Kubernetes-API-Server kann OIDC-Tokens direkt prüfen. Er braucht dafür den Aussteller, die Client-ID und die Angabe, welche Claims Benutzername und Gruppen enthalten:

kube-apiserver \
  --oidc-issuer-url=https://id.example.de/realms/plattform \
  --oidc-client-id=kubernetes \
  --oidc-username-claim=preferred_username \
  --oidc-username-prefix=oidc: \
  --oidc-groups-claim=groups \
  --oidc-groups-prefix=oidc:

Die Präfixe verhindern, dass ein Benutzer aus Keycloak versehentlich denselben Namen trägt wie ein interner Kubernetes-Benutzer. Die Gruppen landen nur dann im Token, wenn in Keycloak ein entsprechender Mapper konfiguriert ist (dazu unten mehr).

Berechtigungen vergibt man anschließend über RBAC an Gruppen, nie an Einzelpersonen:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: plattform-admins
subjects:
  - kind: Group
    name: oidc:plattform-admins
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

Fachteams bekommen statt einer ClusterRoleBinding eine RoleBinding in ihrem Namespace. Wer das Team verlässt, verliert den Zugriff, sobald er in Keycloak aus der Gruppe entfernt wird, auf allen Clustern gleichzeitig. Damit ist auch die Anforderung A3 aus dem BSI-Baustein APP.4.4 abgedeckt: Jede Aktion ist authentifiziert und autorisiert, niemand administriert anonym.

Mit der Kubermatic Kubernetes Platform muss man die API-Server-Flags nicht für jeden Cluster einzeln pflegen. Die OIDC-Konfiguration wird zentral hinterlegt und für die Benutzer-Cluster übernommen.

Die Konfiguration gehört ins Repository

Die Admin-Oberfläche von Keycloak ist bequem. Sie ist aber auch der schnellste Weg zu einem IdP, dessen Zustand niemand mehr erklären kann. Wir verwalten Realms, Clients und Mapper deshalb mit Terraform:

terraform {
  required_providers {
    keycloak = {
      source = "keycloak/keycloak"
    }
  }
}

resource "keycloak_realm" "plattform" {
  realm   = "plattform"
  enabled = true
}

resource "keycloak_openid_client" "kubernetes" {
  realm_id              = keycloak_realm.plattform.id
  client_id             = "kubernetes"
  access_type           = "PUBLIC"
  standard_flow_enabled = true
  valid_redirect_uris   = ["http://localhost:8000"]
}

resource "keycloak_openid_group_membership_protocol_mapper" "groups" {
  realm_id   = keycloak_realm.plattform.id
  client_id  = keycloak_openid_client.kubernetes.id
  name       = "groups"
  claim_name = "groups"
  full_path  = false
}

Der Client ist öffentlich, weil die Anmeldung von der Kommandozeile über ein kubectl-Plugin wie kubelogin läuft, das den Browser-Login auf localhost entgegennimmt. Der Mapper schreibt die Gruppen als groups-Claim ins Token, ohne Pfad, damit die Namen zu den RoleBindings passen.

Änderungen am IdP laufen damit durch dieselbe Pipeline wie alle anderen Änderungen an der Plattform: Pull Request, Review, terraform plan, Freigabe.

Betrieb: der IdP darf nicht ausfallen

Wenn Keycloak nicht erreichbar ist, kann sich niemand anmelden. Das klingt trivial, wird aber in Architekturen oft so behandelt, als sei der IdP eine Nebensache. Wir betreiben Keycloak deshalb mit mehreren Instanzen auf Kubernetes, über den Keycloak-Operator, mit einer hochverfügbaren Datenbank dahinter.

Für den Fall, dass trotzdem alles schiefgeht, braucht es einen Notfallzugang zu den Clustern, der nicht von Keycloak abhängt. Dieser Break-Glass-Zugang ist dokumentiert, streng kontrolliert, wird bei jeder Nutzung protokolliert und hoffentlich nie gebraucht.

Und Keycloak bekommt regelmäßig Updates, als Teil des normalen Release-Prozesses über eine Staging-Umgebung. Ein IdP, der zwei Major-Versionen hinterherhängt, ist ein Sicherheitsrisiko, kein stabiles System.

---

Keycloak macht eine Plattform nicht von allein souverän. Es schafft aber die Voraussetzung dafür: Der IdP läuft auf Infrastruktur Ihrer Wahl, die Identitäten bleiben bei Ihnen, und alle Integrationen beruhen auf offenen Standards. Wenn Sie den Cloud-Anbieter wechseln, nehmen Sie Ihre Benutzer, Gruppen und Rollen einfach mit.