Wir verbinden die LDAP-Autorisierung mit Kubernetes

Ein kurzes Tutorial zur Verwendung von Kubernetes, um Kubernetes mit Ihrem LDAP-Server zu verbinden und den Import von Benutzern und Gruppen mithilfe von Keycloak zu konfigurieren. Auf diese Weise können Sie RBAC für Ihre Benutzer konfigurieren und mit auth-proxy das Kubernetes Dashboard und andere Anwendungen schützen, die sich nicht selbst autorisieren können.

Installieren Sie Keycloak

Angenommen, Sie haben bereits einen LDAP-Server. Dies kann Active Directory, FreeIPA, OpenLDAP oder etwas anderes 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 ist nahezu dasselbe.

Zunächst werden wir Keycloak selbst installieren. Die Installation kann separat und sofort im Kubernetes-Cluster durchgeführt werden. Wenn Sie mehrere Kubernetes-Cluster haben, ist es in der Regel einfacher, sie separat zu installieren. Auf der anderen Seite können Sie immer die offizielle Steuerkarte verwenden und direkt in Ihrem Cluster installieren.

Zum Speichern von Keycloak-Daten benötigen Sie eine Datenbank. Standardmäßig wird h2 verwendet (alle Daten werden lokal gespeichert), es ist jedoch auch möglich, postgres , mysql oder mariadb .
Wenn Sie Keycloak dennoch separat installieren möchten, finden Sie detailliertere Anweisungen in der offiziellen Dokumentation .

Föderations-Setup

Erstellen Sie zunächst ein neues Reich. Realm ist der Raum unserer Anwendung. Jede Anwendung kann einen eigenen Bereich mit unterschiedlichen Benutzern und Berechtigungseinstellungen haben. Master Realm wird von Keycloak selbst verwendet und es ist nicht richtig, es für irgendetwas anderes zu verwenden.

Klicken Sie auf Realm hinzufügen

Kubernetes prüft standardmäßig, ob der Benutzer eine E-Mail hat oder nicht. Da wir unseren eigenen LDAP-Server verwenden, gibt diese Prüfung fast immer false . Deaktivieren wir die Darstellung dieses Parameters in Kubernetes:

Client-Bereiche -> E-Mail -> Mapper -> E-Mail überprüft (Löschen)

Konfigurieren Sie nun den Verbund. Gehen Sie dazu zu:

Benutzerverband -> Anbieter hinzufügen ... -> ldap

Hier ist ein Beispiel für die Einrichtung von FreeIPA:

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

Bei Active Directory wählen Sie einfach Anbieter: Active Directory. Die erforderlichen Einstellungen werden automatisch in das Formular eingefügt.

Klicken Sie auf Speichern

Nun gehen wir weiter:

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

Aktivieren Sie nun die Gruppenzuordnung:

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

Damit ist die Konfiguration des Verbunds abgeschlossen. Fahren Sie mit dem Einrichten des Clients fort.

Client-Setup

Erstellen Sie einen neuen Client (eine Anwendung, die Benutzer von Keycloak empfängt). Wir passieren:

Kunden -> Erstellen

Erstellen Sie auch einen Bereich für Gruppen:

Client-Bereiche -> Erstellen

Und konfigurieren Sie den Mapper für sie:

Client-Bereiche -> Gruppen -> Mapper -> Erstellen

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

Clients -> Kubernetes -> Client- Bereiche -> Standard-Client-Bereiche

Wählen Sie Gruppen unter Verfügbare Clientbereiche aus und klicken Sie auf Ausgewählte hinzufügen

Konfigurieren Sie nun die Authentifizierung unserer Anwendung und gehen Sie zu:

Kunden -> Kubernetes

Klicken Sie auf Speichern. Damit ist die Client-Einrichtung auf der Registerkarte abgeschlossen

Clients -> Kubernetes -> Anmeldeinformationen

Sie können Secret bekommen, das wir in Zukunft verwenden werden.

Konfigurieren Sie Kubernetes

Das Konfigurieren von Kubernetes für die OIDC-Authentifizierung ist recht trivial und nicht sehr kompliziert. Sie müssen lediglich das CA-Zertifikat Ihres OIDC-Servers in /etc/kubernetes/pki/oidc-ca.pem und die erforderlichen Optionen für kube-apiserver hinzufügen.
Aktualisieren Sie dazu /etc/kubernetes/manifests/kube-apiserver.yaml auf allen Ihren Assistenten:

 ... 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 außerdem die kubeadm-Konfiguration im Cluster, um diese Einstellungen beim Aktualisieren 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 das Kubernetes-Setup abgeschlossen. Sie können diese Schritte in allen Ihren Kubernetes-Clustern wiederholen.

Erstautorisierung

Nach diesen Schritten verfügen Sie bereits über einen Kubernetes-Cluster mit konfigurierter OIDC-Authentifizierung. Der einzige Punkt ist, dass Ihre Benutzer noch keinen Client sowie 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.

Zu diesem Zweck können Sie spezielle Webanwendungen verwenden, mit denen Sie den Benutzer authentifizieren und dann die fertige kubeconfig herunterladen können. Eines der bequemsten ist Kuberos , mit dem Sie alle Kubernetes-Cluster in einer Konfiguration beschreiben und einfach zwischen ihnen wechseln können.

Um Kuberos zu konfigurieren, beschreiben Sie einfach die Vorlage für kubeconfig und führen Sie sie mit den folgenden Parametern aus:

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

Weitere Informationen finden Sie unter Verwendung auf Github.

Es ist auch möglich, Kubelogin zu verwenden, wenn Sie direkt auf dem Computer des Benutzers autorisieren möchten. In diesem Fall öffnet der Benutzer einen Browser mit einem Autorisierungsformular auf localhost.

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

RBAC-Setup

Beim Einrichten von RBAC können Sie sowohl auf den Benutzernamen (das Namensfeld im JWT-Token) als auch auf die Benutzergruppe (das Gruppenfeld im JWT-Token) verweisen. Hier ist ein Beispiel für das Festlegen von Berechtigungen für die kubernetes-default-namespace-admins :

 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 der offiziellen Dokumentation von Kubernetes.

Konfigurieren Sie den Auth-Proxy

Es gibt ein wunderbares Keycloak-Gatekeeper- Projekt, mit dem Sie jede Anwendung schützen und dem Benutzer die Möglichkeit geben können, sich beim OIDC-Server zu authentifizieren. Ich werde zeigen, wie Sie es am Beispiel von Kubernetes Dashboard konfigurieren können:

 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