Seminar Kubernetes – OIDC, RBAC und Workload-Identitäten mit SPIFFE/SPIRE

Seminarbeschreibung

Clusteradministration und Kommunikation zwischen Anwendungen benötigen unterschiedliche Identitätsverfahren. Das Seminar trennt deshalb zuerst menschliche Benutzer von Kubernetes-ServiceAccounts und anschließend von anwendungsübergreifenden Workload-Identitäten. Ein vorhandener Cluster wird mit einem vorbereiteten Identity Provider verbunden. Gruppenmerkmale werden in begrenzte RBAC-Rechte übersetzt und mit konkreten Verwaltungsaktionen geprüft.

Im zweiten Teil werden langlebige Zugangsdaten durch kurzlebige, an einen Zweck gebundene Nachweise ergänzt oder ersetzt. SPIFFE beschreibt Identitäten für Workloads; SPIRE dient in der Übungsumgebung als Implementierung für deren Bereitstellung. Zwei Testdienste authentifizieren sich über mTLS und wenden anschließend eine eigene Zugriffserlaubnis an. Die Übungen machen deutlich, dass eine geprüfte Workload-Identität und eine fachliche Berechtigung unterschiedliche Entscheidungen bleiben. Netzrichtlinien unterstützen die Architektur, ersetzen aber keine Identitätsprüfung.

Seminarinhalte

Inhaltsübersicht:

1. Identitätsebenen im Cluster
2. OIDC für menschliche Zugriffe
3. RBAC und administrative Aufgabentrennung
4. ServiceAccounts und kurzlebige Tokens
5. SPIFFE und SPIRE bereitstellen
6. mTLS zwischen Workloads
7. Rotation, Entzug und Netzwerkgrenzen
8. Betrieb und Fehleranalyse

1. Identitätsebenen im Cluster

• Benutzer, Gruppen, ServiceAccounts, Workloads und Clusterkomponenten nach ihrem jeweiligen Zugriffszweck unterscheiden.
• Vertrauensgrenzen zwischen Identity Provider, API-Server, Node und Anwendung erfassen.
• Den vorbereiteten Cluster prüfen und einen begrenzten administrativen Notfallzugang festhalten.

2. OIDC für menschliche Zugriffe

• Den Kubernetes-API-Server beziehungsweise die vorhandene Authentifizierungskonfiguration mit dem Test-Provider abstimmen.
• Issuer, Audience und Benutzer- sowie Gruppenclaims validieren; den von Kubernetes erwarteten OIDC-ID-Token-Typ berücksichtigen.
• Eine geeignete kubectl-Anmeldung einrichten und Ablauf sowie Erneuerung des Anmeldenachweises prüfen.

3. RBAC und administrative Aufgabentrennung

• Roles, ClusterRoles, RoleBindings und ClusterRoleBindings passend zu konkreten Aufgaben gestalten.
• Gruppen aus der Anmeldung auf begrenzte Namespace-Rechte abbilden.
• Zugriffsprüfungen mit kubectl durchführen und unzulässige privilegierte Aktionen bewusst zurückweisen lassen.

4. ServiceAccounts und kurzlebige Tokens

• Anwendungsgebundene ServiceAccounts von menschlichen Konten und Standardkonten unterscheiden.
• TokenRequest und projizierte Tokens mit geeigneter Audience sowie begrenzter Laufzeit einordnen und verwenden.
• Automatisches Token-Mounting, benötigte API-Rechte und Zugriff auf Secrets anhand der Anwendung minimieren.

5. SPIFFE und SPIRE bereitstellen

• Trust Domain, SPIFFE-ID, SVID und Workload API nach ihrer jeweiligen Aufgabe unterscheiden.
• SPIRE Server und Agents in der vorbereiteten Umgebung überprüfen und die verwendete Attestierung nachvollziehen.
• Registrierungseinträge so begrenzen, dass nur die vorgesehenen Test-Workloads passende Identitäten erhalten.

6. mTLS zwischen Workloads

• Zwei vorbereitete Dienste mit X.509-SVIDs und passendem Vertrauensmaterial verbinden.
• Die Peer-Identität nach erfolgreichem TLS-Aufbau ausdrücklich gegen die erlaubten Zugreifer prüfen.
• Einen Dienst mit unerwarteter Identität und einen Dienst ohne geeignetes Zertifikat kontrolliert ablehnen.

7. Rotation, Entzug und Netzwerkgrenzen

• Erneuerung kurzlebiger Nachweise beobachten und die Wirkung eines entfernten Registrierungseintrags prüfen.
• Restlaufzeiten ausgestellter Nachweise und das Verhalten bereits bestehender Verbindungen berücksichtigen.
• Unterstützte NetworkPolicies als zusätzliche Begrenzung einsetzen und deren tatsächliche Durchsetzung prüfen.

8. Betrieb und Fehleranalyse

• OIDC-, RBAC-, ServiceAccount-, Attestierungs- und TLS-Fehler anhand getrennt formulierter Hypothesen eingrenzen.
• Ausfälle von Identity Provider oder SPIRE hinsichtlich Neuanmeldung, Erneuerung und bestehender Verbindung bewerten.
• Trust-Material, Betriebszugänge, Konfigurationsänderungen und wiederkehrende Negativtests dokumentieren.

Praxisübungen

1. Einen Benutzer über OIDC anmelden und die vom Cluster ausgewerteten Identitätsmerkmale kontrollieren.
2. Eine Gruppe mit lesenden Rechten in einem Namespace verbinden und einen schreibenden Zugriff zurückweisen lassen.
3. Einer Anwendung einen eigenen ServiceAccount mit begrenztem Token und minimalen API-Rechten zuordnen.
4. Die SPIRE-Registrierung der beiden Testdienste konfigurieren und die ausgegebenen SPIFFE-Identitäten prüfen.
5. Eine mTLS-Verbindung aufbauen und anschließend eine nicht erlaubte Peer-Identität auf Anwendungsebene abweisen.
6. Rotation und Entfernung eines Registrierungseintrags beobachten und verbleibende Gültigkeit sauber dokumentieren.
7. Ein vorbereitetes Attestierungs- oder Trust-Problem diagnostizieren und die gesamte Zugriffsmatrix erneut ausführen.

Einordnung und Vertiefung

Der Schwerpunkt liegt auf einem vorbereiteten Cluster und zwei Referenzdiensten. Clustergrundlagen, vollständiger Service-Mesh-Aufbau und eine standortübergreifende Trust-Föderation sind eigene Vertiefungen.

Seminarangebot und Lernpfade