Integration der Active Directory-Authentifizierung in Kubernetes mit Keycloak.

Dieser Artikel wurde verfasst, um bestehendes Wissen zu erweitern, führt jedoch speziell in die Besonderheiten der Integration mit Microsoft Active Directory ein und ergänzt diese., sondern beschreibt die Besonderheiten der Verbindung speziell mit Microsoft ActiveDirectory und ergänzt diese.

In diesem Artikel erkläre ich, wie man einrichtet und konfiguriert:

• Keycloak — ein Open-Source-Projekt, das einen zentralen Zugangspunkt für Anwendungen bietet. Es unterstützt zahlreiche Protokolle, einschließlich LDAP und OpenID, die für uns von Interesse sind.
• Keycloak Gatekeeper — ein Reverse-Proxy-Anwendung, die die Autorisierung über Keycloak integriert.
• Gangway — eine Anwendung, die eine Konfiguration für kubectl generiert, mit der man sich über OpenID authentifizieren und mit der Kubernetes-API verbinden kann.

Wie Berechtigungen in Kubernetes funktionieren.

Die Benutzer- und Gruppenrechte können wir mithilfe von RBAC verwalten. Es gibt bereits zahlreiche Artikel zu diesem Thema, sodass ich nicht detailliert darauf eingehen möchte. Das Problem ist, dass Sie RBAC verwenden können, um die Benutzerrechte einzuschränken, aber Kubernetes weiß nichts über die Benutzer. Daher ist ein Mechanismus erforderlich, um Benutzer in Kubernetes zu integrieren. Dafür fügen wir einen OpenID-Provider in Kubernetes hinzu, der bestätigt, dass ein solcher Benutzer tatsächlich existiert, während Kubernetes die Rechte verwaltet.

Vorbereitung

• Sie benötigen einen Kubernetes-Cluster oder minikube.
• Active Directory
• Domänen:
  keycloak.example.org
  kubernetes-dashboard.example.org
  gangway.example.org
• Zertifikat für die Domänen oder ein selbst-signiertes Zertifikat.

Ich werde nicht im Detail darauf eingehen, wie man selbst-signierte Zertifikate erstellt. Sie müssen zwei Zertifikate erstellen: eines für die Root-CA (Zertifizierungsstelle) und ein Wildcard-Zertifikat für die Domain *.example.org.

Nachdem Sie die Zertifikate erhalten oder ausgegeben haben, müssen Sie das Client-Zertifikat zu Kubernetes hinzufügen. Dazu erstellen Sie einen Secret:

kubectl create secret tls tls-keycloak --cert=example.org.crt --key=example.org.pem

Anschließend werden wir es für unseren Ingress-Controller verwenden.

Installation von Keycloak

Ich habe beschlossen, dass es am einfachsten ist, vorgefertigte Lösungen zu verwenden, insbesondere Helm-Charts.

Wir fügen das Repository hinzu und aktualisieren es:

helm repo add codecentric https://codecentric.github.io/helm-charts
helm repo update

Erstellen Sie die Datei keycloak.yml mit folgendem Inhalt:

keycloak.yml

keycloak:
  # Administratorname
  username: "test_admin"
  # Administrationspasswort
  password: "admin"
  # Diese Flags sind notwendig, um das Hochladen von Skripten direkt über die Weboberfläche in Keycloak zu ermöglichen. Dies benötigen wir, um einen Fehler zu beheben, der weiter unten beschrieben ist.
  extraArgs: "-Dkeycloak.profile.feature.script=enabled -Dkeycloak.profile.feature.upload_scripts=enabled" 
  # Ingress aktivieren, Hostnamen und das Zertifikat angeben, das wir zuvor in den Secrets gespeichert haben
  ingress:
    enabled: true 
    path: /
    annotations:
      kubernetes.io/ingress.class: nginx
      ingress.kubernetes.io/affinity: cookie
    hosts:
      - keycloak.example.org
    tls:
    - hosts:
        - keycloak.example.org
      secretName: tls-keycloak
  # Keycloak benötigt für seinen Betrieb eine Datenbank. Zu Testzwecken setze ich PostgreSQL direkt in Kubernetes auf, was in der Produktion besser zu vermeiden ist!
  persistence:
    deployPostgres: true
    dbVendor: postgres

postgresql:
  postgresUser: keycloak
  postgresPassword: ""
  postgresDatabase: keycloak
  persistence:
    enabled: true

Federationseinrichtung

Nun gehen wir zur Weboberfläche keycloak.example.org

In der linken Ecke klicken wir auf Realm hinzufügen

Schlüssel
Value

Name
kubernetes

Anzeigename
Kubernetes

Wir deaktivieren die Bestätigungsüberprüfung der E-Mail des Benutzers:
Client Scopes —> E-Mail —> Mapper —> E-Mail verifiziert (Löschen)

Wir richten die Föderation für den Import von Benutzern aus ActiveDirectory ein. Ich lasse Screenshots unten, damit es verständlicher ist.

User Federation —> Anbieter hinzufügen… —> ldap

Federationseinrichtung


Wenn alles gut läuft, sehen Sie nach dem Drücken des Buttons Alle Benutzer synchronisieren die Nachricht über den erfolgreichen Benutzerimport.

Jetzt müssen wir unsere Gruppen zuordnen.

User Federation —> ldap_localhost —> Mapper —> Erstellen

Mapper erstellen

Client-Konfiguration

Wir müssen einen Client erstellen. In den Begriffen von Keycloak ist dies die Anwendung, die sich bei ihm anmelden wird. Wichtige Punkte hebe ich im Screenshot rot hervor.

Clients —> Erstellen

Client-Konfiguration

Wir erstellen einen Scope für Gruppen:

Client Scopes —> Erstellen

Scope erstellen

Und wir konfigurieren den Mapper für sie:

Client Scopes —> Gruppen —> Mapper —> Erstellen

Mapper

Wir fügen das Mapping unserer Gruppen zu den Standard Client Scopes hinzu:

Clients —> kubernetes —> Client Scopes —> Standard Client Scopes
Wählen Sie Gruppen in Verfügbare Client Scopes, drücken Sie Ausgewählte hinzufügen

Wir erhalten das Secret (und notieren es irgendwo), das wir für die Authentifizierung in Keycloak verwenden werden:

Clients —> kubernetes —> Anmeldeinformationen —> Secret
Damit ist die Einrichtung abgeschlossen, aber ich hatte einen Fehler, als ich nach einer erfolgreichen Authentifizierung einen 403-Fehler erhielt. Bug-Report.

Fix:

Kundenbereiche —> Rollen —> Mapper —> Erstellen

Mapper

Skriptcode

// add current client-id to token audience
token.addAudience(token.getIssuedFor());

// return token issuer as dummy result assigned to iss again
token.getIssuer();

Kubernetes-Konfiguration

Wir müssen angeben, wo unser Root-Zertifikat der Website gespeichert ist und wo sich der OIDC-Anbieter befindet.
Dafür bearbeiten wir die Datei /etc/kubernetes/manifests/kube-apiserver.yaml

kube-apiserver.yaml

...
spec:
  containers:
  - command:
    - kube-apiserver
...
    - --oidc-ca-file=/var/lib/minikube/certs/My_Root.crt
    - --oidc-client-id=kubernetes
    - --oidc-groups-claim=groups
    - --oidc-issuer-url=https://keycloak.example.org/auth/realms/kubernetes
    - --oidc-username-claim=email
...

Aktualisieren Sie die kubeadm-Konfiguration im Cluster:

kubeadm config

kubectl edit -n kube-system configmaps kubeadm-config

...
data:
  ClusterConfiguration: |
    apiServer:
      extraArgs:
        oidc-ca-file: /var/lib/minikube/certs/My_Root.crt
        oidc-client-id: kubernetes
        oidc-groups-claim: groups
        oidc-issuer-url: https://keycloak.example.org/auth/realms/kubernetes
        oidc-username-claim: email
...

Einrichtung des Auth-Proxys

Zum Schutz Ihrer Webanwendung können Sie den Keycloak Gatekeeper verwenden. Dieser Reverse-Proxy autorisiert nicht nur den Benutzer, bevor die Seite angezeigt wird, sondern überträgt auch Informationen über Sie in den Header des Endanwendungs. Wenn Ihre Anwendung OpenID unterstützt, wird der Benutzer sofort autorisiert. Lassen Sie uns dies am Beispiel des Kubernetes Dashboards ansehen.

Installation des Kubernetes Dashboards

helm install stable/kubernetes-dashboard --name dashboard -f values_dashboard.yaml

values_dashboard.yaml

enableInsecureLogin: true
service:
  externalPort: 80
rbac:
  clusterAdminRole: true
  create: true
serviceAccount:
  create: true
  name: 'dashboard-test'

Zugriffsrechte konfigurieren:

Wir erstellen ein ClusterRoleBinding, das Admin-Rechte (Standard-ClusterRole cluster-admin) für Benutzer in der DataOPS-Gruppe gewährt.

kubectl apply -f rbac.yaml

rbac.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: dataops_group
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: DataOPS

Installation von Keycloak Gatekeeper:

helm repo add gabibbo97 https://gabibbo97.github.io/charts/
helm repo update
helm install gabibbo97/keycloak-gatekeeper --version 2.1.0 --name keycloak-gatekeeper -f values_proxy.yaml

values_proxy.yaml

# Включаем ingress
ingress:
  enabled: true
  annotations:
    kubernetes.io/ingress.class: nginx
  path: /
  hosts:
    - kubernetes-dashboard.example.org
  tls:
   - secretName: tls-keycloak
     hosts:
       - kubernetes-dashboard.example.org

# Говорим где мы будем авторизовываться у OIDC провайдера
discoveryURL: "https://keycloak.example.org/auth/realms/kubernetes"
# Имя клиента которого мы создали в Keycloak
ClientID: "kubernetes"
# Secret который я просил записать
ClientSecret: "c6ec03b8-d0b8-4cb6-97a0-03becba1d727"
# Куда перенаправить в случае успешной авторизации. Формат <SCHEMA>://<SERVICE_NAME>.><NAMESAPCE>.<CLUSTER_NAME>
upstreamURL: "http://dashboard-kubernetes-dashboard.default.svc.cluster.local"
# Пропускаем проверку сертификата, если у нас самоподписанный
skipOpenidProviderTlsVerify: true
# Настройка прав доступа, пускаем на все path если мы в группе DataOPS
rules:
  - "uri=/*|groups=DataOPS"

Nach dieser Installation wird bei dem Versuch, sich einzuloggen kubernetes-dashboard.example.org, eine Weiterleitung zu Keycloak erfolgen, und bei erfolgreicher Authentifizierung gelangen wir bereits eingeloggt zum Dashboard.

Installation von Gangway

Zur Erleichterung kann Gangway hinzugefügt werden, das eine Konfigurationsdatei für kubectl generiert, mit der wir als unser Benutzer in Kubernetes gelangen können.

helm install --name gangway stable/gangway -f values_gangway.yaml

values_gangway.yaml

gangway:
  # Beliebiger Name für den Cluster
  clusterName: "my-k8s"
  # Hier steht unser OIDC-Anbieter
  authorizeURL: "https://keycloak.example.org/auth/realms/kubernetes/protocol/openid-connect/auth"
  tokenURL: "https://keycloak.example.org/auth/realms/kubernetes/protocol/openid-connect/token"
  audience: "https://keycloak.example.org/auth/realms/kubernetes/protocol/openid-connect/userinfo"
  # Theoretisch könnten hier Gruppen hinzugefügt werden, die wir zugeordnet haben
  scopes: ["openid", "profile", "email", "offline_access"]
  redirectURL: "https://gangway.example.org/callback"
  # Kundenname
  clientID: "kubernetes"
  # Geheimnis
  clientSecret: "c6ec03b8-d0b8-4cb6-97a0-03becba1d727"
  # Wenn der Standardwert beibehalten wird, wird der Benutzername übernommen <b>Vorname</b> <b>Nachname</b>, und bei "sub" sein Login
  usernameClaim: "sub"
  # Domainname oder IP-Adresse des API-Servers
  apiServerURL: "https://192.168.99.111:8443"

# Aktivieren von Ingress
ingress:
  enabled: true
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/proxy-buffer-size: "64k"
  path: /
  hosts:
  - gangway.example.org
  tls:
  - secretName: tls-keycloak
    hosts:
      - gangway.example.org

# Wenn ein selbstsigniertes Zertifikat verwendet wird, muss das (öffentliche Root-Zertifikat) angegeben werden.
trustedCACert: |-
 -----BEGIN CERTIFICATE-----
 MIIDVzCCAj+gAwIBAgIBATANBgkqhkiG9w0BAQsFADA1MQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRGF0YU9QUzEUMBIGA1UEAxMLbXkgcm9vdCBrZXkwHhcNMjAwMjE0MDkxODAwWhcNMzAwMjE0MDkxODAwWjA1MQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRGF0YU9QUzEUMBIGA1UEAxMLbXkgcm9vdCBrZXkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDyP749PqqIRwNSqaK6qr0Zsi03G4PTCUlgaYTPZuMrwUVPK8xX2dWWs9MPRMOdXpgr8aSTZnVfmelIlVz4D7o2vK5rfmAe9GPcK0WbwKwXyhFU0flS9sU/g46ogHFrk03SZxQAeJhMLfEmAJm8LF5HghtGDs3t4uwGsB95o+lqPLiBvxRB8ZS3jSpYpvPgXAuZWKdZUQ3UUZf0X3hGLp7uIcIwJ7i4MduOGaQEO4cePeEJy9aDAO6qV78YmHbyh9kaW+1DL/Sgq8NmTgHGV6UOnAPKHTnMKXl6KkyUz8uLBGIdVhPxrlzG1EzXresJbJenSZ+FZqm3oLqZbw54Yp5hAgMBAAGjcjBwMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFHISTOU/6BQqqnOZj+1xJfxpjiG0MAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEEBAMCAAcwHgYJYIZIAYb4QgENBBEWD3hjYSBjZXJ0aWZpY2F0ZTANBgkqhkiG9w0BAQsFAAOCAQEAj7HC8ObibwOLT4ZYmISJZwub9lcE0AZ5cWkPW39j/syhdbbqjK/6jy2D3WUEbR+s1Vson5Ov7JhN5In2yfZ/ByDvBnoj7CP8Q/ZMjTJgwN7j0rgmEb3CTZvnDPAz8Ijw3FP0cjxfoZ1Z0V2F44Ry7gtLJWr06+MztXVyto3aIz1/XbMQnXYlzc3c3B5yUQIy44Ce5aLRVsAjmXNqVRmDJ2QPNLicvrhnUJsO0zFWI+zZ2hc4Ge1RotCrjfOc9hQY63jZJ17myCZ6QCD7yzMzAob4vrgmkD4q7tpGrhPY/gDcE+lUNhC7DO3l0oPy2wsnT2TEn87eyWmDiTFG9zWDew==
 -----END CERTIFICATE-----

Sieht etwa so aus. Ermöglicht das sofortige Herunterladen der Konfigurationsdatei sowie die Erstellung dieser durch einen Befehlssatz:

Quelle: habr.com