Wie wird die Implementierung von Entra ID Privileged Identity Management (PIM) für Just-in-Time-Zugriffe auf Kubernetes-Cluster-Admin-Rollen technisch realisiert?

Die technische Realisierung erfolgt über die Kopplung von Entra ID PIM mit Azure RBAC oder Kubernetes-nativen RBAC-Rollen mittels Sicherheitsgruppen. Da PIM keine direkten Kubernetes-Rollen verwaltet, nutzen wir eine Indirektionsschicht über Entra ID Gruppen.

Wir konfigurieren den Prozess in folgenden technischen Schritten:

1. Identitäts-Integration: Der Kubernetes-Cluster (z. B. AKS) wird mit Entra ID integriert. Wir aktivieren die Azure RBAC-Autorisierung für den Cluster, um die Berechtigungssteuerung zentral in der Azure-Control-Plane zu halten.
2. Gruppen-Mapping: Wir erstellen eine spezifische Entra ID Sicherheitsgruppe (z. B. k8s-cluster-admins). Dieser Gruppe weisen wir die Azure-Rolle Azure Kubernetes Service RBAC Cluster Admin zu.
3. PIM-Konfiguration: Die Sicherheitsgruppe wird in Entra ID PIM als Ressource definiert. Wir weisen den Administratoren die Rolle "Mitglied" der Gruppe als berechtigt (eligible) zu, statt sie dauerhaft zuzuweisen.
4. JIT-Aktivierung: Der Nutzer fordert über das PIM-Portal die Aktivierung der Gruppenmitgliedschaft an. Nach erfolgreicher MFA-Prüfung oder Genehmigung durch einen Approver wird der Nutzer für einen definierten Zeitraum (z. B. 4 Stunden) Mitglied der Gruppe.
5. Token-Refresh: Der Zugriff auf den Cluster erfolgt über kubectl. Da die Gruppenmitgliedschaft im Access-Token hinterlegt ist, muss der Nutzer nach der PIM-Aktivierung ein neues Token beziehen (z. B. via az aks get-credentials), damit die aktualisierten Claims an die Kubernetes-API übermittelt werden.

Die technische Prozesskette lässt sich wie folgt zusammenfassen:

Diese Architektur reduziert das Risiko von "Standing Privileges" und ist ein Kernbestandteil unserer Strategie im Bereich IT-Consulting & Digitale Strategie.

Wir empfehlen, die maximale Aktivierungsdauer für Cluster-Admin-Rollen auf maximal 4 Stunden zu begrenzen und jede Aktivierung durch eine obligatorische Begründung sowie ein Ticket-Referenzsystem zu koppeln, um eine lückenlose Audit-Chain für regulatorische Anforderungen zu gewährleisten.