Wir befestigen die LDAP-Autorisierung an Kubernetes

Wir befestigen die LDAP-Autorisierung an Kubernetes

Ein kleines Tutorial, wie Sie mit Keycloak Kubernetes mit Ihrem LDAP-Server verbinden und den Import von Benutzern und Gruppen einrichten. Auf diese Weise können Sie RBAC für Ihre Benutzer einrichten und Auth-Proxy verwenden, um das Kubernetes Dashboard und andere Anwendungen zu schützen, die nicht wissen, wie sie sich selbst autorisieren sollen.

Keycloak-Installation

Nehmen wir an, dass Sie bereits über einen LDAP-Server verfügen. Es könnte Active Directory, FreeIPA, OpenLDAP oder was auch immer sein. Wenn Sie keinen LDAP-Server haben, können Sie Benutzer im Prinzip direkt in der Keycloak-Oberfläche erstellen oder öffentliche OIDC-Anbieter (Google, Github, Gitlab) verwenden, das Ergebnis wird fast das gleiche sein.

Lassen Sie uns zunächst Keycloak selbst installieren. Die Installation kann separat oder direkt im Kubernetes-Cluster durchgeführt werden. Wenn Sie mehrere Kubernetes-Cluster haben, ist es in der Regel einfacher, es separat zu installieren. Andererseits können Sie es immer verwenden Offizielle Steuerkarte und installieren Sie es direkt in Ihrem Cluster.

Um Keycloak-Daten zu speichern, benötigen Sie eine Datenbank. Die Standardeinstellung ist h2 (alle Daten werden lokal gespeichert), eine Nutzung ist aber auch möglich postgres, mysql oder mariadb.
Sollten Sie sich dennoch dazu entschließen, Keycloak separat zu installieren, finden Sie eine ausführlichere Anleitung in amtliche Dokumentation.

Föderations-Setup

Lassen Sie uns zunächst einen neuen Bereich erstellen. Realm ist der Raum unserer Anwendung. Jede Anwendung kann einen eigenen Bereich mit unterschiedlichen Benutzern und Berechtigungseinstellungen haben. Der Master-Bereich wird von Keycloak selbst verwendet und es ist falsch, ihn für andere Zwecke zu verwenden.

Klicken Bereich hinzufügen

Option
Wert

Name und Vorname
kubernetes

Display Name
Kubernetes

HTML-Anzeigename
<img src="https://kubernetes.io/images/nav_logo.svg" width="400" >

Kubernetes prüft standardmäßig, ob die E-Mail-Adresse des Benutzers bestätigt ist oder nicht. Da wir unseren eigenen LDAP-Server verwenden, wird diese Prüfung fast immer zurückgegeben false. Deaktivieren wir die Darstellung dieser Einstellung in Kubernetes:

Clientbereiche -> E-Mail -> Mapper -> Email überprüft (Löschen)

Jetzt gründen wir die Föderation, dazu gehen wir zu:

Benutzerverband -> Anbieter hinzufügen… -> ldap

Hier ist ein Beispiel-Setup für FreeIPA:

Option
Wert

Anzeigename der Konsole
freeipa.example.org

Verkäufer
Red Hat Directory Server

UUID-LDAP-Attribut
ipauniqueid

Verbindungs-URL
ldaps://freeipa.example.org

Benutzer-DN
cn=users,cn=accounts,dc=example,dc=org

DN binden
uid=keycloak-svc,cn=users,cn=accounts,dc=example,dc=org

Anmeldeinformationen binden
<password>

Kerberos-Authentifizierung zulassen:
on

Kerberos-Bereich:
EXAMPLE.ORG

Serverprinzipal:
HTTP/[email protected]

Schlüsselregisterkarte:
/etc/krb5.keytab

Benutzer keycloak-svc muss vorab auf unserem LDAP-Server erstellt werden.

Bei Active Directory einfach auswählen Anbieter: Active Directory und die notwendigen Einstellungen werden automatisch in das Formular eingefügt.

Klicken Speichern

Jetzt machen wir weiter:

Benutzerverband -> freeipa.example.org -> Mapper -> Vorname

Option
Wert

Ldap-Attribute
givenName

Aktivieren Sie nun die Gruppenzuordnung:

Benutzerverband -> freeipa.example.org -> Mapper -> Erstellen

Option
Wert

Name und Vorname
groups

Mapper-Typ
group-ldap-mapper

LDAP-Gruppen-DN
cn=groups,cn=accounts,dc=example,dc=org

Strategie zum Abrufen von Benutzergruppen
GET_GROUPS_FROM_USER_MEMBEROF_ATTRIBUTE

Damit ist die Föderationseinrichtung abgeschlossen. Fahren wir mit der Einrichtung des Clients fort.

Client-Setup

Erstellen wir einen neuen Client (eine Anwendung, die Benutzer von Keycloak empfängt). Lass uns gehen:

Kunden -> Erstellen

Option
Wert

Kunden-ID
kubernetes

Zugangsart
confidenrial

Root-URL
http://kubernetes.example.org/

Gültige Weiterleitungs-URIs
http://kubernetes.example.org/*

Admin-URL
http://kubernetes.example.org/

Wir werden auch einen Bereich für Gruppen erstellen:

Clientbereiche -> Erstellen

Option
Wert

Template
No template

Name und Vorname
groups

Vollständiger Gruppenpfad
false

Und richten Sie einen Mapper für sie ein:

Clientbereiche -> Gruppen -> Mapper -> Erstellen

Option
Wert

Name und Vorname
groups

Mapper-Typ
Group membership

Name des Token-Anspruchs
groups

Jetzt müssen wir die Gruppenzuordnung in unserem Client-Bereich aktivieren:

Kunden -> Kubernetes -> Clientbereiche -> Standard-Client-Bereiche

wählen Gruppen в Verfügbare Client-Bereiche, Drücken Sie Auswahl hinzufügen

Lassen Sie uns nun die Authentifizierung unserer Anwendung einrichten. Gehen Sie zu:

Kunden -> Kubernetes

Option
Wert

Autorisierung aktiviert
ON

Lasst uns pushen Speichern Damit ist die Client-Einrichtung abgeschlossen, jetzt auf der Registerkarte

Kunden -> Kubernetes -> Referenzen

du kannst bekommen Die Geheime die wir später verwenden werden.

Kubernetes konfigurieren

Das Einrichten von Kubernetes für die OIDC-Autorisierung ist recht trivial und nicht sehr kompliziert. Sie müssen lediglich das CA-Zertifikat Ihres OIDC-Servers eingeben /etc/kubernetes/pki/oidc-ca.pem und fügen Sie die erforderlichen Optionen für kube-apiserver hinzu.
Führen Sie dazu ein Update durch /etc/kubernetes/manifests/kube-apiserver.yaml auf allen deinen Meistern:

...
spec:
  containers:
  - command:
    - kube-apiserver
...
    - --oidc-ca-file=/etc/kubernetes/pki/oidc-ca.pem
    - --oidc-client-id=kubernetes
    - --oidc-groups-claim=groups
    - --oidc-issuer-url=https://keycloak.example.org/auth/realms/kubernetes
    - --oidc-username-claim=email
...

Und aktualisieren Sie auch die kubeadm-Konfiguration im Cluster, um diese Einstellungen während des Updates nicht zu verlieren:

kubectl edit -n kube-system configmaps kubeadm-config

...
data:
  ClusterConfiguration: |
    apiServer:
      extraArgs:
        oidc-ca-file: /etc/kubernetes/pki/oidc-ca.pem
        oidc-client-id: kubernetes
        oidc-groups-claim: groups
        oidc-issuer-url: https://keycloak.example.org/auth/realms/kubernetes
        oidc-username-claim: email
...

Damit ist die Kubernetes-Einrichtung abgeschlossen. Sie können diese Schritte für alle Ihre Kubernetes-Cluster wiederholen.

Erstgenehmigung

Nach diesen Schritten verfügen Sie bereits über einen Kubernetes-Cluster mit konfigurierter OIDC-Autorisierung. Der einzige Punkt ist, dass Ihre Benutzer noch keinen Client und keine eigene kubeconfig konfiguriert haben. Um dieses Problem zu lösen, müssen Sie die automatische Ausgabe von kubeconfig an Benutzer nach erfolgreicher Autorisierung konfigurieren.

Dazu können Sie spezielle Webanwendungen nutzen, die es Ihnen ermöglichen, den Benutzer zu authentifizieren und anschließend die fertige kubeconfig herunterzuladen. Eine der bequemsten ist KuberosDamit können Sie alle Kubernetes-Cluster in einer Konfiguration beschreiben und problemlos zwischen ihnen wechseln.

Um Kuberos zu konfigurieren, reicht es aus, die Vorlage für kubeconfig zu beschreiben und mit den folgenden Parametern auszuführen:

kuberos https://keycloak.example.org/auth/realms/kubernetes kubernetes /cfg/secret /cfg/template

Weitere Einzelheiten finden Sie unter Anwendungsbereich auf Github.

Es ist auch möglich, es zu verwenden kubelogin wenn Sie die Autorisierung direkt auf dem Computer des Benutzers durchführen möchten. In diesem Fall öffnet der Benutzer einen Browser mit einem Autorisierungsformular auf localhost.

Die resultierende kubeconfig kann auf der Website überprüft werden jwt.io. Kopieren Sie einfach den Wert users[].user.auth-provider.config.id-token von Ihrer kubeconfig in ein Formular auf der Website und erhalten Sie sofort das Transkript.

RBAC-Setup

Bei der Konfiguration von RBAC können Sie sich sowohl auf den Benutzernamen (Feld) beziehen name im JWT-Token) und für eine Gruppe von Benutzern (Feld groups im JWT-Token). Hier ist ein Beispiel für das Festlegen von Berechtigungen für eine Gruppe kubernetes-default-namespace-admins:

kubernetes-default-namespace-admins.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: default-admins
  namespace: default
rules:
- apiGroups:
  - '*'
  resources:
  - '*'
  verbs:
  - '*'
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: kubernetes-default-namespace-admins
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: default-admins
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: kubernetes-default-namespace-admins

Weitere Beispiele für RBAC finden Sie in offizielle Kubernetes-Dokumentation

Authentifizierungs-Proxy festlegen

Es gibt ein wunderbares Projekt Schlüsselmantel-Pförtner, mit dem Sie jede Anwendung sichern können, indem Sie dem Benutzer die Authentifizierung beim OIDC-Server ermöglichen. Wie Sie es einrichten können, zeige ich Ihnen am Beispiel des Kubernetes Dashboards:

Dashboard-proxy.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: kubernetes-dashboard-proxy
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: kubernetes-dashboard-proxy
    spec:
      containers:
      - args:
        - --listen=0.0.0.0:80
        - --discovery-url=https://keycloak.example.org/auth/realms/kubernetes
        - --client-id=kubernetes
        - --client-secret=<your-client-secret-here>
        - --redirection-url=https://kubernetes-dashboard.example.org
        - --enable-refresh-tokens=true
        - --encryption-key=ooTh6Chei1eefooyovai5ohwienuquoh
        - --upstream-url=https://kubernetes-dashboard.kube-system
        - --resources=uri=/*
        image: keycloak/keycloak-gatekeeper
        name: kubernetes-dashboard-proxy
        ports:
        - containerPort: 80
          livenessProbe:
            httpGet:
              path: /oauth/health
              port: 80
            initialDelaySeconds: 3
            timeoutSeconds: 2
          readinessProbe:
            httpGet:
              path: /oauth/health
              port: 80
            initialDelaySeconds: 3
            timeoutSeconds: 2
---
apiVersion: v1
kind: Service
metadata:
  name: kubernetes-dashboard-proxy
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: kubernetes-dashboard-proxy
  type: ClusterIP

Source: habr.com

Kommentar hinzufügen