ProHoster > Blog > Administration > LDAP-Authentifizierung zu Kubernetes hinzufĂŒgen

LDAP-Authentifizierung zu Kubernetes hinzufĂŒgen

LDAP-Authentifizierung zu Kubernetes hinzufĂŒgen

Eine kurze Anleitung, wie Sie Keycloak nutzen können, um Kubernetes mit Ihrem LDAP-Server zu verbinden und den Import von Benutzern und Gruppen einzurichten. Dies ermöglicht Ihnen, RBAC fĂŒr Ihre Benutzer zu konfigurieren und einen Auth-Proxydienst zu nutzen, um das Kubernetes-Dashboard und andere Anwendungen, die keine eigene Autorisierung unterstĂŒtzen, abzusichern.

Installation von Keycloak

Angenommen, Sie haben bereits einen LDAP-Server. Dies kann ein 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) verwenden; 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 ist es einfacher, es separat zu installieren, wenn Sie mehrere Kubernetes-Cluster haben. Auf der anderen Seite können Sie immer das offizielle Helm-Chart verwenden und es direkt in Ihrem Cluster installieren.

Zur Speicherung der Daten von Keycloak benötigen Sie eine Datenbank. StandardmĂ€ĂŸig wird h2 (alle Daten werden lokal gespeichert) verwendet, Sie können jedoch auch postgres, mysql oder mariadb.
Wenn Sie dennoch Keycloak separat installieren möchten, finden Sie detaillierte Anleitungen in offiziellen Dokumentation.

Federationseinrichtung

ZunĂ€chst erstellen wir ein neues Realm. Ein Realm ist der Raum unserer Anwendung. Jede Anwendung kann ihr eigenes Realm mit unterschiedlichen Benutzern und Authentifizierungseinstellungen haben. Das Master-Realm wird von Keycloak selbst verwendet, und es wĂ€re falsch, es fĂŒr etwas anderes zu nutzen.

Klicken Sie auf Realm hinzufĂŒgen

Option
Value

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 Option in Kubernetes deaktivieren:

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

Jetzt konfigurieren wir die Föderation, dafĂŒr gehen wir zu:

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

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

Option
Value

Konsole Anzeigename
freeipa.example.org

Anbieter
Red Hat Verzeichnisdienst

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 Credential
<password>

Kerberos-Authentifizierung erlauben:
on

Kerberos-Realm:
EXAMPLE.ORG

Server Principal:
HTTP/freeipa.example.org@EXAMPLE.ORG

KeyTab:
/etc/krb5.keytab

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

Im Fall von Active Directory reicht es aus, einfach auszuwĂ€hlen Anbieter: Active Directory und die erforderlichen Einstellungen werden automatisch in das Formular eingefĂŒgt.

Klicken Sie auf ), und klicken dann auf die SchaltflÀche

Gehen wir nun weiter:

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

Option
Value

Ldap-Attribut
givenName

Aktivieren wir nun das Gruppenmapping:

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

Option
Value

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 Federation-Konfiguration beendet, wir gehen zur Kundeneinrichtung ĂŒber.

Client-Konfiguration

Wir erstellen einen neuen Client (eine Anwendung, die Benutzer aus Keycloak abruft). Gehen wir weiter:

Clients —> Erstellen

Option
Value

Client-Geheimnis
kubernetes

Zugriffstyp
confidenzial

Root-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-Scope —> Erstellen

Option
Value

Vorlage
Kein Template

Name
Gruppen

Voller Gruppenspeicherpfad
false

Und wir konfigurieren den Mapper fĂŒr sie:

Client-Scope —> Gruppen —> Mapper —> Erstellen

Option
Value

Name
Gruppen

Mapper-Typ
Gruppenmitgliedschaft

Token-Anspruchsname
Gruppen

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

Clients —> kubernetes —> Client-Scope —> Standard-Client-Scope

WĂ€hlen Sie Gruppen in VerfĂŒgbare Client Scopes, drĂŒcken Sie AusgewĂ€hlte hinzufĂŒgen

Jetzt richten wir die Authentifizierung unserer Anwendung ein, weiter geht's:

Clients —> kubernetes

Option
Value

Autorisierung aktiviert
EIN

DrĂŒcken wir auf speichern und damit ist die Konfiguration des Clients abgeschlossen, nun auf dem Tab

Clients —> kubernetes —> Credentials

wird es möglich sein, Secret den wir spÀter verwenden werden.

Kubernetes-Konfiguration

Die Einrichtung von Kubernetes fĂŒr OIDC-Authentifizierung ist recht trivial und nicht besonders komplex. Alles, was Sie benötigen, ist das CA-Zertifikat Ihres OIDC-Servers in /etc/kubernetes/pki/oidc-ca.pem zu hinterlegen und die notwendigen Optionen fĂŒr kube-apiserver hinzuzufĂŒgen.
Aktualisieren Sie daher /etc/kubernetes/manifests/kube-apiserver.yaml auf all Ihren Master-Servern:

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

Aktualisieren Sie auch die kubeadm-Konfiguration im Cluster, um diese Einstellungen bei einem Upgrade 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 Konfiguration von Kubernetes abgeschlossen. Sie können diese Schritte in all Ihren Kubernetes-Clustern wiederholen.

Ersteinrichtung der Autorisierung

Nach diesen Schritten haben Sie bereits einen Kubernetes-Cluster mit aktivierter OIDC-Autorisierung. Ein wichtiger Punkt ist, dass Ihre Benutzer derzeit keinen konfigurierten Client oder eigenen kubeconfig haben. Um dieses Problem zu lösen, mĂŒssen Sie die automatische Bereitstellung von kubeconfig fĂŒr Benutzer nach erfolgreicher Autorisierung einrichten.

HierfĂŒr können spezielle Webanwendungen verwendet werden, die die Authentifizierung des Benutzers ermöglichen und dann das fertige kubeconfig zum Download bereitstellen. Eine der bequemsten Optionen ist Kuberos, er ermöglicht es, alle Kubernetes-Cluster in einer Konfiguration zu beschreiben und leicht zwischen ihnen zu wechseln.

FĂŒr die Konfiguration von Kuberos mĂŒssen Sie lediglich eine Vorlage fĂŒr kubeconfig beschreiben und mit den folgenden Parametern 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 zu verwenden, wenn Sie die Authentifizierung direkt auf dem Benutzercomputer durchfĂŒhren möchten. In diesem Fall wird dem Benutzer ein Browser mit dem Authentifizierungsformular auf localhost geöffnet.

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

RBAC-Konfiguration

Bei der Konfiguration 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 ein Beispiel fĂŒr die Rechtevergabe an 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

Weitere Beispiele fĂŒr RBAC finden Sie unter der offiziellen Kubernetes-Dokumentation

Einrichtung des Auth-Proxys

Es gibt ein großartiges Projekt keycloak-gatekeeper, das es ermöglicht, jede Anwendung zu sichern, indem es dem Benutzer die Authentifizierung ĂŒber einen OIDC-Server ermöglicht. Ich zeige Ihnen, wie Sie es am Beispiel des Kubernetes Dashboards einrichten können:

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

ZuverlĂ€ssiges Webhosting mit DDoS-Schutz, VPS- und VDS-Server kaufen đŸ”„ ZuverlĂ€ssiges Webhosting mit DDoS-Schutz, VPS- und VDS-Server kaufen | ProHoster