ProHoster > Blog > Administration > Wir integrieren die LDAP-Authentifizierung in Kubernetes

Wir integrieren die LDAP-Authentifizierung in Kubernetes

Wir integrieren die LDAP-Authentifizierung in Kubernetes

Eine kurze Anleitung, wie Sie mit Keycloak Kubernetes mit Ihrem LDAP-Server verbinden und den Import von Benutzern und Gruppen konfigurieren können. Dies ermöglicht die Einrichtung von RBAC fĂŒr Ihre Benutzer und die Verwendung von auth-proxy zum Schutz des Kubernetes Dashboards und anderer Anwendungen, die keine eigene Authentifizierung durchfĂŒhren können.

Installation von Keycloak

Angenommen, Sie haben bereits einen LDAP-Server. Dies könnte Active Directory, FreeIPA, OpenLDAP oder etwas anderes sein. Wenn Sie keinen LDAP-Server haben, können Sie Benutzer direkt ĂŒber die Keycloak-OberflĂ€che erstellen oder öffentliche OIDC-Anbieter (Google, Github, Gitlab) nutzen, das Ergebnis wird fast dasselbe sein.

Zuerst installieren wir Keycloak selbst, die Installation kann sowohl separat als auch direkt im Kubernetes-Cluster erfolgen. In der Regel wÀre es einfacher, es separat zu installieren, wenn Sie mehrere Kubernetes-Cluster haben. Andererseits können Sie immer das offizielle Helm-Chart verwenden und es direkt in Ihrem Cluster installieren.

FĂŒr die Speicherung von Keycloak-Daten benötigen Sie eine Datenbank. StandardmĂ€ĂŸig wird h2 verwendet (alle Daten werden lokal gespeichert), aber Sie können auch in einer Umgebung, in der die Locale nicht UTF-8 ist, beispielsweise in einer leeren Umgebung (hier, mysql oder mariadb.
verwenden. Wenn Sie sich entscheiden, Keycloak separat zu installieren, finden Sie detailliertere Anweisungen in offiziellen Dokumentation.

Einrichtung der Föderation

Zuerst erstellen wir ein neues Realm. Ein Realm ist ein Bereich unserer Anwendung. Jede Anwendung kann ihr eigenes Realm mit unterschiedlichen Benutzern und Authentifizierungseinstellungen haben. Das Master-Realm wird von Keycloak selbst verwendet, und es ist nicht richtig, es fĂŒr etwas anderes zu verwenden.

Klicken Sie auf Realm hinzufĂŒgen

Option
Wert

Name
Kubernetes

Anzeigename
Kubernetes

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

Kubernetes ĂŒberprĂŒft standardmĂ€ĂŸig, ob die E-Mail des Benutzers bestĂ€tigt ist oder nicht. Da wir einen eigenen LDAP-Server verwenden, wird diese ÜberprĂŒfung hier fast immer zurĂŒckgeben false. Lassen Sie uns die Anzeige dieser Einstellung in Kubernetes deaktivieren:

Client-Scopes —> E-Mail —> Mapper —> E-Mail verifiziert (Löschen)

Jetzt konfigurieren wir die Föderation. Gehen Sie dazu zu:

Benutzerföderation —> Anbieter hinzufĂŒgen 
 —> ldap

Ich gebe ein Beispiel fĂŒr die Konfiguration fĂŒr FreeIPA:

Option
Wert

Konsolenanzeigename
freeipa.example.org

Anbieter
Red Hat Directory Server

UUID-LDAP-Attribut
ipauniqueid

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

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

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

Bind-Anmeldeinformationen
<password>

Erlaube Kerberos-Authentifizierung:
on

Kerberos-Realm:
EXAMPLE.ORG

Server-Prinzipal:
HTTP/freeipa.example.org@EXAMPLE.ORG

KeyTab:
/etc/krb5.keytab

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

Im Falle von Active Directory reicht es aus, einfach auszuwÀhlen Anbieter: Active Directory Die erforderlichen Einstellungen werden automatisch in das Formular eingesetzt.

Klicken Sie auf Speichern

Jetzt gehen wir weiter:

Benutzerföderation —> freeipa.example.org —> Mapper —> Vorname

Option
Wert

Ldap Attribut
givenName

Jetzt aktivieren wir das Gruppemapping:

Benutzerföderation —> freeipa.example.org —> Mapper —> Erstellen

Option
Wert

Name
Gruppen

Mapper-Typ
group-ldap-mapper

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

Benutzergruppen Abrufstrategie
GET_GROUPS_FROM_USER_MEMBEROF_ATTRIBUTE

Damit ist die Konfiguration der Föderation abgeschlossen, wir gehen zur Konfiguration des Clients ĂŒber.

Client-Konfiguration

Wir erstellen einen neuen Client (eine Anwendung, die Benutzer aus Keycloak empfÀngt). Weiter:

Clients —> Erstellen

Option
Wert

Client-ID
Kubernetes

Zugriffsart
vertraulich

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

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

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

Wir erstellen auch einen Scope fĂŒr Gruppen:

Client-Scopes —> Erstellen

Option
Wert

Vorlage
Kein Template

Name
Gruppen

VollstÀndiger Gruppenpfad
false

Und wir konfigurieren den Mapper dafĂŒr:

Client-Scopes —> Gruppen —> Mapper —> Erstellen

Option
Wert

Name
Gruppen

Mapper-Typ
Gruppenmitgliedschaft

Token Anspruchsname
Gruppen

Jetzt mĂŒssen wir das Gruppemapping in unserem Client-Scope aktivieren:

Clients —> Kubernetes —> Client-Scopes —> Standard-Client-Scopes

WĂ€hlen Sie Gruppen in VerfĂŒgbare Client-Scopes, klicken Sie auf AusgewĂ€hlte hinzufĂŒgen

Jetzt konfigurieren wir die Authentifizierung unserer Anwendung, weiter:

Clients —> Kubernetes

Option
Wert

Autorisierung aktiviert
AN

Klicken Sie auf speichern und damit ist die Client-Konfiguration abgeschlossen, jetzt können Sie im Tab

Clients —> Kubernetes —> Anmeldeinformationen

erhalten Geheimnis das wir spÀter verwenden werden.

Kubernetes-Konfiguration

Die Konfiguration von Kubernetes fĂŒr OIDC-Authentifizierung ist ziemlich trivial und nicht sehr kompliziert. Alles, was Sie brauchen, ist, das CA-Zertifikat Ihres OIDC-Servers in /etc/kubernetes/pki/oidc-ca.pem einzufĂŒgen und die erforderlichen Optionen fĂŒr kube-apiserver hinzuzufĂŒgen.
Dazu aktualisieren Sie /etc/kubernetes/manifests/kube-apiserver.yaml auf all Ihren Master-Knoten:

...
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 bei einem Update 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-Konfiguration abgeschlossen. Sie können die gleichen Schritte in all Ihren Kubernetes-Clustern wiederholen.

Erste Autorisierung

Nach diesen Schritten haben Sie bereits einen Kubernetes-Cluster mit konfigurierte OIDC-Authentifizierung. Der einzige Punkt ist, dass Ihre Benutzer noch keinen Client und kein eigenes kubeconfig haben. Um dieses Problem zu lösen, sollte die automatische Ausgabe von kubeconfig an die Benutzer nach erfolgreicher Authentifizierung konfiguriert werden.

Dazu können spezielle Webanwendungen verwendet werden, die die Authentifizierung des Benutzers ermöglichen und dann das fertige kubeconfig herunterladen. Eine der praktischsten ist Kuberos, er ermöglicht es, alle Kubernetes-Cluster in einer Konfiguration zu beschreiben und leicht zwischen ihnen zu wechseln.

Um Kuberos einzurichten, reicht es aus, eine Vorlage fĂŒr die kubeconfig zu beschreiben und mit den folgenden Parametern zu starten:

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

FĂŒr detailliertere Informationen siehe Nutzung auf Github.

Es ist auch möglich, kubelogin , wenn Sie die Authentifizierung direkt auf dem Computer des Benutzers durchfĂŒhren möchten. In diesem Fall öffnet sich fĂŒr den Benutzer ein Browser mit einem Authentifizierungsformular auf localhost.

Die erhaltene kubeconfig kann auf der Website ĂŒberprĂŒft werden jwt.io. Kopieren Sie einfach den Wert users[].user.auth-provider.config.id-token aus Ihrer kubeconfig in das Formular auf der Website und erhalten Sie sofort die Dekodierung.

RBAC-Konfiguration

Bei der Einrichtung von RBAC kann sowohl auf den Benutzernamen (Feld name im jwt-Token), als auch auf die Benutzergruppe (Feld Gruppen im jwt-Token) verwiesen werden. Hier ist ein Beispiel fĂŒr die Berechtigungseinstellungen fĂŒr die 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

Mehr Beispiele fĂŒr RBAC finden Sie in der offiziellen Kubernetes-Dokumentation

Einrichtung des auth-proxy

Es gibt ein großartiges Projekt keycloak-gatekeeper, das es ermöglicht, jede Anwendung zu sichern, indem der Benutzer die Möglichkeit hat, sich beim OIDC-Server zu authentifizieren. Ich werde zeigen, wie man es mit dem Kubernetes-Dashboard einrichtet:

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=
        - --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

Quelle: habr.com

60GB SSD 8Gb DDR4