Blog

SSO mit Authentik

Jetze Schuurmans

Jetze Schuurmans

Aktualisiert März 17, 2026
9 Minuten

Die Verwaltung der Authentifizierung für mehrere Dienste in einem Kubernetes-Cluster kann schnell mühsam werden. Jede Anwendung benötigt ihre eigenen Anmeldedaten, was die Verwaltung des Benutzerzugriffs und die Aufrechterhaltung der Sicherheit erschwert. Single Sign-On (SSO) löst dieses Problem, indem es ein zentralisiertes Authentifizierungssystem bereitstellt, bei dem sich Benutzer einmal anmelden und Zugang zu allen autorisierten Diensten erhalten.

Dieser Blogbeitrag beschreibt, wie wir Authentik als SSO-Anbieter für einen lokalen Kubernetes-Cluster einrichten. Authentik ist ein Open-Source-Identitätsanbieter, der verschiedene Authentifizierungsprotokolle unterstützt, darunter OAuth2, SAML und LDAP.

Ablauf der Authentifizierung

Der Authentifizierungsfluss verwendet das OpenID Connect (OIDC) Protokoll mit kubectl und kubelogin:

Ablauf der Authentifizierung

Wenn Sie einen kubectl-Befehl ausführen:

  1. kubectl ruft kubelogin auf, um Anmeldeinformationen zu erhalten
  2. kubelogin öffnet Ihren Browser, um sich mit Authentik zu authentifizieren
  3. Nach erfolgreicher Authentifizierung gibt Authentik ein ID-Token zurück
  4. kubelogin übergibt dieses Token an kubectl
  5. kubectl verwendet das Token zur Authentifizierung beim Kubernetes-API-Server

Unser Stapel

Bevor wir uns mit der Konfiguration befassen, sollten wir die von uns verwendeten Tools vorstellen:

  • K3s: Leichtgewichtige Kubernetes-Distribution
  • Helm: Paketmanager für Kubernetes
  • Kustomize: Konfigurationsmanagement für Kubernetes
  • Versiegelte Geheimnisse: Verschlüsselte Verwaltung von Geheimnissen
  • Tailscale: VPN für sicheren Zugang und DNS
  • Argo CD: GitOps kontinuierliche Bereitstellung

Konfiguration

Authentik benötigt eine PostgreSQL-Datenbank und verwendet Redis für das Caching. In diesem Abschnitt wird beschrieben, wie Sie Authentik mit diesen Abhängigkeiten mithilfe von Helm und Kustomize einsetzen können.

Einrichten anpassen

Wir beginnen mit dem Verweis auf die Authentik Helm Chart in unserem kustomization.yml:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: authentik

helmCharts:
  - name: authentik
    releaseName: authentik
    version: "2025.8.4"
    repo: https://charts.goauthentik.io

Namespace

Um den Namensraum zu erstellen, erstellen Sie unter dem Ordner resources/ namespace.yml :

apiVersion: v1
kind: Namespace
metadata:
  name: authentik

Verweisen Sie darauf in der kustomization.yml:

...
resources:
  - resources/namespace.yml

PostgreSQL-Verbindung

Authentik erfordert eine PostgreSQL-Datenbank. Wir gehen davon aus, dass Sie PostgreSQL bereits in Ihrem Cluster unter dem Namespace postgres installiert haben. Konfigurieren Sie Authentik für die Verbindung zu dieser Datenbank: 

helmCharts:
  - name: authentik
    ...
    valuesInline:
      authentik:
        postgresql:
          host: postgres.postgres.svc.cluster.local
          name: authentik
          user: file:///postgres-creds/username
          password: file:///postgres-creds/password

Geheimnisse Management

Authentik benötigt mehrere Geheimnisse: - PostgreSQL-Anmeldeinformationen - Geheimschlüssel für die Verschlüsselung

Wir verwenden Sealed Secrets, um diese sicher zu verwalten. Stellen Sie zunächst sicher, dass Sealed Secrets installiert ist: 

# macOS
brew install kubeseal yq

PostgreSQL Anmeldeinformationen

Erstellen Sie ein Geheimnis, das sich aus Ihrem PostgreSQL-Namensraum repliziert:

apiVersion: v1
kind: Secret
metadata:
  name: authentik-postgres
  annotations:
    replicator.v1.mittwald.de/replicate-from: postgres/postgres-user
data: {}

Authentik Secret Key

Generieren und versiegeln Sie den geheimen Schlüssel:

kubectl create secret generic authentik-secrets \
  --namespace authentik \
  --dry-run=client \
  --from-literal=secret-key=$(openssl rand -hex 32) \
  -o json | \
kubeseal \
  --controller-namespace sealed-secrets \
  --controller-name sealed-secrets | \
yq -p json

Fügen Sie die Ausgabe zu resources/sealed-secret.yml hinzu.

Montage-Geheimnisse

Konfigurieren Sie Volume-Mounts, um Geheimnisse für Authentik-Pods verfügbar zu machen:

helmCharts:
  - name: authentik
    ...
    valuesInline:
      ...
      server:
        volumes:
          - name: postgres-creds
            secret:
              secretName: authentik-postgres
          - name: secrets
            secret:
              secretName: authentik-secrets
        volumeMounts:
          - name: postgres-creds
            mountPath: /postgres-creds
            readOnly: true
          - name: secrets
            mountPath: /secrets
            readOnly: true
      worker:
        volumes:
          - name: postgres-creds
            secret:
              secretName: authentik-postgres
          - name: secrets
            secret:
              secretName: authentik-secrets
        volumeMounts:
          - name: postgres-creds
            mountPath: /postgres-creds
            readOnly: true
          - name: secrets
            mountPath: /secrets
            readOnly: true

Redis

Aktivieren Sie die integrierte Redis-Instanz:

helmCharts:
  - name: authentik
    ...
    valuesInline:
      ...
      redis:
        enabled: true

Ingress mit Tailscale

Konfigurieren Sie den Ingress, um Authentik über Tailscale freizugeben:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: authentik
  annotations:
    tailscale.com/experimental-forward-cluster-traffic-via-ingress: "true"
spec:
  defaultBackend:
    service:
      name: authentik-server
      port:
        number: 443
  ingressClassName: tailscale
  tls:
    - hosts:
        - auth

Dadurch wird ein Tailscale-Hostname auth erstellt, der zum Authentik-Server leitet.

Ersteinrichtung

Rufen Sie Authentik nach der Installation unter der von Ihnen konfigurierten URL auf (z.B. https://auth.tail6720f8.ts.net) und schließen Sie die Ersteinrichtung ab:

  1. Navigieren Sie zu /if/flow/initial-setup/
  2. Erstellen Sie einen Admin-Benutzer mit einem sicheren Passwort
  3. Melden Sie sich mit Ihren Admin-Zugangsdaten an

Benutzer und Gruppen konfigurieren

Benutzer erstellen

In der Authentik-Verwaltungsoberfläche: 1. Navigieren Sie zu Verzeichnis → Benutzer 2. Klicken Sie auf Erstellen 3. Geben Sie die Benutzerdetails ein (Benutzername, Name, E-Mail) 4. Legen Sie ein Passwort fest oder konfigurieren Sie die E-Mail-basierte Aktivierung

Gruppen erstellen

Gruppen helfen bei der Organisation von Benutzern und der Zuweisung von Berechtigungen: 1. Navigieren Sie zu Verzeichnis → Gruppen 2. Klicken Sie auf Erstellen 3. Benennen Sie Ihre Gruppe (z.B. "Admins") 4. Fügen Sie Benutzer zu der Gruppe hinzu

Kubernetes-Integration mit kubelogin

Um SSO für kubectl zu aktivieren, verwenden wir kubelogin, ein Authentifizierungs-Plugin, das den OIDC-Fluss implementiert.

OAuth Provider in Authentik einrichten

  1. Navigieren Sie zu Anwendungen → Anbieter
  2. Klicken Sie auf Erstellen und wählen Sie OAuth2/OpenID Provider
  3. Konfigurieren Sie den Anbieter:
  4. Name: kubernetes
  5. Autorisierungsablauf: implizit
  6. Kundenart: Öffentlich
  7. URIs umleiten: http://localhost:8000 und http://localhost:18000
  8. Notieren Sie die Client-ID (z.B. zUdTG...)

Erstellen der Anwendung

  1. Navigieren Sie zu Anwendungen → Anwendungen
  2. Klicken Sie auf Erstellen
  3. Verknüpfen Sie ihn mit dem soeben erstellten Anbieter
  4. Konfigurieren Sie:
  5. Name: Kubernetes
  6. Slug: kubernetes
  7. Provider: kubernetes (der von Ihnen erstellte)

Installieren von kubelogin

Installieren Sie kubelogin auf Ihrem lokalen Rechner:

# macOS
brew install kubelogin

kubectl konfigurieren

Ändern Sie Ihre kubeconfig, um kubelogin zu verwenden:

users:
  - name: oidc
    user:
      exec:
        apiVersion: client.authentication.k8s.io/v1beta1
        command: kubectl
        args:
          - oidc-login
          - get-token
          - --oidc-issuer-url=https://auth.tail6720f8.ts.net/application/o/kubernetes/
          - --oidc-client-id=zUdTG...
          - --oidc-extra-scope=email
          - --oidc-extra-scope=profile

K3s konfigurieren

Konfigurieren Sie K3s für die Validierung von OIDC-Tokens, indem Sie /etc/rancher/k3s/config.yaml bearbeiten:

kube-apiserver-arg:
  - "oidc-issuer-url=https://auth.tail6720f8.ts.net/application/o/kubernetes/"
  - "oidc-client-id=zUdTG..."
  - "oidc-username-claim=email"
  - "oidc-groups-claim=groups"

Starten Sie K3s neu:

sudo systemctl restart k3s

RBAC einrichten

Erstellen Sie eine ClusterRoleBinding, um Ihrer Authentik-Administratorgruppe Admin-Rechte zu gewähren:

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

Der Gruppenname sollte mit der Gruppe übereinstimmen, die Sie in Authentik erstellt haben.

Vollständiges Beispiel

Zusammengefasst ergibt sich daraus die folgende Dateistruktur:

authentik/
├── kustomization.yml
└── resources
    ├── cluster-role-binding.yml
    ├── ingress.yml
    ├── namespace.yml
    └── sealed-secret.yml

kustomization.yml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: authentik

helmCharts:
  - name: authentik
    releaseName: authentik
    version: "2025.8.4"
    repo: https://charts.goauthentik.io
    valuesInline:
      authentik:
        secret_key: file:///secrets/secret-key
        postgresql:
          host: postgres.postgres.svc.cluster.local
          name: authentik
          user: file:///postgres-creds/username
          password: file:///postgres-creds/password
      redis:
        enabled: true
      server:
        ingress:
          enabled: false
        volumes:
          - name: postgres-creds
            secret:
              secretName: authentik-postgres
          - name: secrets
            secret:
              secretName: authentik-secrets
        volumeMounts:
          - name: postgres-creds
            mountPath: /postgres-creds
            readOnly: true
          - name: secrets
            mountPath: /secrets
            readOnly: true
      worker:
        volumes:
          - name: postgres-creds
            secret:
              secretName: authentik-postgres
          - name: secrets
            secret:
              secretName: authentik-secrets
        volumeMounts:
          - name: postgres-creds
            mountPath: /postgres-creds
            readOnly: true
          - name: secrets
            mountPath: /secrets
            readOnly: true

resources:
  - resources/cluster-role-binding.yml
  - resources/ingress.yml
  - resources/namespace.yml
  - resources/sealed-secret.yml

Ressourcen

resources/namespace.yml:

apiVersion: v1
kind: Namespace
metadata:
  name: authentik

resources/ingress.yml:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: authentik
  annotations:
    tailscale.com/experimental-forward-cluster-traffic-via-ingress: "true"
spec:
  defaultBackend:
    service:
      name: authentik-server
      port:
        number: 443
  ingressClassName: tailscale
  tls:
    - hosts:
        - auth

resources/cluster-role-binding.yml:

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

resources/sealed-secret.yml:

apiVersion: v1
kind: Secret
metadata:
  name: authentik-postgres
  annotations:
    replicator.v1.mittwald.de/replicate-from: postgres/postgres-user
data: {}
---
kind: SealedSecret
apiVersion: bitnami.com/v1alpha1
metadata:
  name: authentik-secrets
  namespace: authentik
  creationTimestamp: null
spec:
  template:
    metadata:
      name: authentik-secrets
      namespace: authentik
      creationTimestamp: null
  encryptedData:
    secret-key: AgB2l3...

Testen der Einrichtung

Test kubectl Zugriff

Nachdem Sie alles konfiguriert haben, testen Sie Ihren kubectl-Zugang:

kubectl get nodes

Bei der ersten Verwendung öffnet kubelogin Ihren Browser, um sich bei Authentik zu authentifizieren. Nach erfolgreicher Authentifizierung sollten die kubectl-Befehle nahtlos funktionieren.

Token verifizieren

Prüfen Sie, ob Sie die OIDC-Authentifizierung verwenden:

kubectl config view --minify

Sie sollten die kubelogin exec-Konfiguration im Benutzerbereich sehen.

Benutzeridentität prüfen

Überprüfen Sie, welchen Benutzer Kubernetes sieht:

kubectl auth whoami

Der Befehl sollte Ihre E-Mail Adresse von Authentik anzeigen.

Integration mit Argo CD

Authentik kann auch SSO für Argo CD bereitstellen, so dass Entwickler dieselben Anmeldeinformationen sowohl für kubectl als auch für die Argo CD-Benutzeroberfläche verwenden können.

Erstellen eines OAuth Providers für Argo CD

  1. Erstellen Sie in Authentik einen neuen OAuth2/OpenID Provider:
  2. Name: argocd
  3. Autorisierungsablauf: implizit
  4. Kundenart: Öffentlich
  5. URIs umleiten: https://argocd.example.com/auth/callback
  6. Notieren Sie die Client-ID (z.B. zSN3...)

Erstellen der Argo CD-Anwendung

  1. Navigieren Sie zu Anwendungen → Anwendungen
  2. Klicken Sie auf Erstellen
  3. Verknüpfen Sie es mit dem Argo CD-Anbieter
  4. Konfigurieren Sie die Anwendungsdetails

Argo CD konfigurieren

Fügen Sie die OIDC-Konfiguration zu Ihrer Argo CD ConfigMap hinzu:

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
  namespace: argocd
data:
  url: https://argocd.example.com
  oidc.config: |
    name: Authentik
    issuer: https://auth.tail6720f8.ts.net/application/o/argocd/
    clientID: zSN3...
    requestedScopes:
      - openid
      - profile
      - email
      - groups

Konfigurieren Sie RBAC, um Authentik-Gruppen den Argo CD-Rollen zuzuordnen:

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argocd
data:
  policy.csv: |
    g, admins, role:admin

Erweiterungen

Um diese Einrichtung zu professionalisieren, sollten Sie sich überlegen:

Referenzen

Verfasst von

Jetze Schuurmans

Machine Learning Engineer

Jetze is a well-rounded Machine Learning Engineer, who is as comfortable solving Data Science use cases as he is productionizing them in the cloud. His expertise includes: AI4Science, MLOps, and GenAI. As a researcher, he has published papers on: Computer Vision and Natural Language Processing and Machine Learning in general.

Contact

Let’s discuss how we can support your journey.

‌
‌
‌
‌
‌
‌
‌
‌
‌