ArgoCD an Keycloak hängen: SSO für das GitOps-Werkzeug

ArgoCD bringt einen lokalen admin-Account mit. Zum Ausprobieren ist das praktisch, für den Betrieb ist es zu wenig. Ein Werkzeug, mit dem man alles ausrollt, was in Produktion läuft, gehört nicht hinter ein geteiltes Passwort. In diesem Artikel gehe ich den Weg der Reihe nach: warum der Login an den zentralen Identity-Provider gehört, wie die OIDC-Konfiguration nach Keycloak zeigt, wie ich Gruppen auf Rollen mappe, und welche Falle mich dabei zuverlässig erwischt.

Warum SSO gerade für das GitOps-Werkzeug

Wer ArgoCD bedienen kann, kann deployen, also faktisch alles ändern. Solche Rechte gehören an echte, benannte Identitäten mit klaren Rollen, nicht an ein Passwort, das im Team herumgereicht wird. Über OIDC greifen dieselben Konten und Gruppen, die ohnehin überall gelten. Ein Austritt, ein Klick im Identity-Provider, und der Zugang zu ArgoCD ist mit weg.

Der erste Schritt ist deshalb, den mitgelieferten admin-Account zu deaktivieren, sobald der SSO-Login steht. Danach führt kein Weg mehr über das geteilte Passwort, sondern nur noch über Keycloak.

Die Konfiguration gehört in die Helm-Values

Wie schon beim Deployen von ArgoCD gilt: ArgoCD ist Helm-managed. Die OIDC-Konfiguration gehört deshalb in die Helm-Values und damit nach Git, nicht per kubectl edit an die laufende ConfigMap. Sonst überschreibt der nächste helm upgrade die Anbindung wieder, und man sucht den Fehler an der falschen Stelle.

Die offizielle Doku beschreibt die OIDC-Felder und den Ablauf für ArgoCD mit Keycloak im Detail. Wichtig ist, dass diese Werte versioniert in Git liegen, damit die Anbindung genauso reproduzierbar ist wie der Rest des Deployments.

Gruppen auf Rollen mappen

OIDC liefert die Gruppen des Nutzers, ArgoCD macht daraus Rechte. Erst dieses Mapping entscheidet, wer nur sehen, wer synchronisieren und wer Projekte verwalten darf. Ohne sauberes RBAC ist jeder eingeloggte Nutzer entweder zu mächtig oder nutzlos. Die Rollen gehören mitgedacht, nicht nachgereicht.

Die Issuer-Falle

Der häufigste Stolperstein bei OIDC ist der Aussteller. ArgoCD muss den Keycloak-Issuer unter genau der URL erreichen, die in den ausgestellten Tokens steht. Der Server spricht Keycloak intern über den Service-Namen an, der Browser wird für den Login an den öffentlichen Hostnamen umgeleitet, und beide müssen zum Issuer im Token passen. Stimmt das nicht überein, schlägt die Prüfung fehl, oft mit einer wenig aussagekräftigen Meldung. Es ist dasselbe Muster wie bei der Keycloak-Anbindung von Mattermost: Aussteller, interner Weg und Browser-Weg müssen dieselbe Identität ergeben.

Ehrlich: erst absichern, dann öffnen

Bevor ArgoCD über einen Ingress von außen erreichbar wird, müssen SSO und RBAC stehen. Ein öffentlich erreichbares ArgoCD mit admin und Passwort ist eine offene Einladung, den ganzen Cluster zu übernehmen. Die Reihenfolge ist nicht verhandelbar: erst die Identität, dann die Erreichbarkeit.

Sie wollen, dass der Zugriff auf Ihre Deploy-Werkzeuge an echte Identitäten und Rollen gebunden ist? Ich binde GitOps- und Admin-Oberflächen an Ihren zentralen Login an, mit sauberem Rollenmodell. Mehr unter IT-Sicherheit & ISMS, das Erstgespräch ist unverbindlich.