[LAYER_4] Identity Backbone: Keycloak & OIDC in KRITIS-Netzen

In der klassischen Netzwerktechnik galt lange: Wer physischen Zugriff auf die Management-Konsole hat oder im richtigen VLAN sitzt, ist vertrauenswürdig. In einer Zero-Trust-Architektur ist das ein fataler Trugschluss. Für Project Sentinel haben wir Layer 4 als Identity Plane definiert. Unser Credo: Identität ist der neue Perimeter.

Kein Tool in unserem Stack – weder NetBox noch GitLab – vertraut lokalen Benutzerdatenbanken. Die gesamte Autorität liegt beim Identity Provider (IdP).

Keycloak: Die zentrale Instanz für Authentifizierung

Wir setzen auf Keycloak v24.0, gekoppelt an eine redundante PostgreSQL 15 Instanz. Keycloak fungiert als unser Single Point of Authentication.

Anstatt für jedes Management-Tool eigene User anzulegen und mühsam zu synchronisieren, nutzen wir moderne Föderationsprotokolle:

1. OIDC (OpenID Connect): Alle administrativen Web-GIs (NetBox, GitLab) nutzen Keycloak für den Login.
2. Kryptographische Tokens: Authentifizierung und Autorisierung erfolgen über signierte JWTs (JSON Web Tokens).
3. RBAC (Role-Based Access Control): Berechtigungen werden zentral in Keycloak definiert und über Mappings an die Applikationen weitergegeben.

Least-Privilege by Design

Sicherheit bedeutet auch, Fehlkonfigurationen durch menschliches Versagen zu minimieren. In unserem Setup erhalten föderierte Benutzer standardmäßig eine restriktive Nur-Lese-Rolle (view-only) in der NetBox. Schreibrechte müssen explizit über Keycloak-Gruppen zugewiesen werden. So stellen wir sicher, dass jeder Zugriff auditierbar ist und dem Prinzip der minimalen Rechtevergabe entspricht.

Lessons Learned: Wenn der Speicherplatz die Identität blockiert

Ein kritischer Moment beim Deployment auf dem Management-Host (MGMT-01) war nicht softwareseitiger Natur, sondern lag in der Infrastruktur-Basis. Keycloak, GitLab-Runner und die später folgenden ML-Bibliotheken sind speicherhungrig.

Das Problem:
Die standardmäßig vom Ubuntu-Installer angelegte Root-Partition (/) war durch Docker-Images und Container-Logs innerhalb kürzester Zeit zu 100 % ausgelastet. Ein klassischer "Staging-Fehler", der in Produktion zum Systemstillstand führt.

Die Lösung (Operational Hardening):
Wir haben die LVM-Partition im laufenden Betrieb erweitert. Das ist der Vorteil einer professionellen LVM-Struktur gegenüber statischen Partitionen.

codeBash

# LVM-Volume auf die vollen 50 GB erweitern
sudo lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv

# Das Dateisystem zur Laufzeit vergrößern
sudo resize2fs /dev/ubuntu-vg/ubuntu-lv

# Aufräumen der Docker-Leichen
docker system prune -a --volumes -f

Ergebnis: Das System atmet wieder. Die Identity-Services laufen stabil.

Fazit Layer 4

Ohne einen gehärteten Identity-Backbone ist jede Automatisierung eine Gefahr. Durch die Zentralisierung via Keycloak haben wir die volle Kontrolle darüber, wer zu welchem Zeitpunkt welche Änderung an der KRITIS-Infrastruktur vornimmt.

Nächster Halt: Im finalen Teil der Serie erreichen wir das Ziel: Layer 5 – Die KI-Ebene. Wir schauen uns an, wie Sentinel Core den gesamten Context nutzt, um lokale, souveräne Intelligenz zu liefern.

Status: Identity Federated. RBAC Enforced. LVM Resized.