{"id":70867,"date":"2020-02-22T06:40:58","date_gmt":"2020-02-22T03:40:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/prikruchivaem-ldap-avtorizacziyu-k-kubernetes"},"modified":"2020-03-03T16:14:36","modified_gmt":"2020-03-03T13:14:36","slug":"prikruchivaem-ldap-avtorizacziyu-k-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/prikruchivaem-ldap-avtorizacziyu-k-kubernetes","title":{"rendered":"LDAP-Authentifizierung zu Kubernetes hinzuf\u00fcgen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"LDAP-Authentifizierung<\/p>\n

<\/p>\n

Eine kurze Anleitung, wie Sie Keycloak nutzen k\u00f6nnen, um Kubernetes mit Ihrem LDAP-Server zu verbinden und den Import von Benutzern und Gruppen einzurichten. Dies erm\u00f6glicht Ihnen, RBAC f\u00fcr Ihre Benutzer zu konfigurieren und einen Auth-Proxydienst zu nutzen, um das Kubernetes-Dashboard und andere Anwendungen, die keine eigene Autorisierung unterst\u00fctzen, abzusichern.<\/p>\n

<\/a><\/noindex><\/p>\n

Installation von Keycloak<\/h2>\n

<\/p>\n

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\u00f6nnen Sie Benutzer direkt \u00fcber die Keycloak-Oberfl\u00e4che erstellen oder \u00f6ffentliche OIDC-Anbieter (Google, Github, Gitlab) verwenden; das Ergebnis wird fast dasselbe sein.<\/p>\n

<\/p>\n

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\u00f6nnen Sie immer das offizielle Helm-Chart<\/a><\/noindex> verwenden und es direkt in Ihrem Cluster installieren.<\/p>\n

<\/p>\n

Zur Speicherung der Daten von Keycloak ben\u00f6tigen Sie eine Datenbank. Standardm\u00e4\u00dfig wird h2<\/code> (alle Daten werden lokal gespeichert) verwendet, Sie k\u00f6nnen jedoch auch postgres<\/code>, mysql<\/code> oder mariadb<\/code>.
\nWenn Sie dennoch Keycloak separat installieren m\u00f6chten, finden Sie detaillierte Anleitungen in offiziellen Dokumentation<\/a><\/noindex>.<\/p>\n

<\/p>\n

Federationseinrichtung<\/h2>\n

<\/p>\n

Zun\u00e4chst 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\u00e4re falsch, es f\u00fcr etwas anderes zu nutzen.<\/p>\n

<\/p>\n

Klicken Sie auf Realm hinzuf\u00fcgen<\/strong><\/p>\n

<\/p>\n

Option
\nValue<\/p>\n

Name<\/strong>
\nkubernetes<\/code><\/p>\n

Anzeigename<\/strong>
\nKubernetes<\/code><\/p>\n

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

<\/p>\n

Kubernetes \u00fcberpr\u00fcft standardm\u00e4\u00dfig, ob die E-Mail des Benutzers best\u00e4tigt ist oder nicht. Da wir einen eigenen LDAP-Server verwenden, wird diese \u00dcberpr\u00fcfung hier fast immer zur\u00fcckgeben false<\/code>. Lassen Sie uns die Anzeige dieser Option in Kubernetes deaktivieren:<\/p>\n

<\/p>\n

Client-Bereiche<\/strong> \u2014> E-Mail<\/strong> \u2014> Mapper<\/strong> \u2014> E-Mail verifiziert<\/strong> (L\u00f6schen)<\/p>\n

<\/p>\n

Jetzt konfigurieren wir die F\u00f6deration, daf\u00fcr gehen wir zu:<\/p>\n

<\/p>\n

Benutzerf\u00f6deration<\/strong> \u2014> Provider hinzuf\u00fcgen\u2026<\/strong> \u2014> ldap<\/strong><\/p>\n

<\/p>\n

Ich gebe ein Beispiel f\u00fcr die Konfiguration von FreeIPA:<\/p>\n

<\/p>\n

Option
\nValue<\/p>\n

Konsole Anzeigename<\/strong>
\nfreeipa.example.org<\/code><\/p>\n

Anbieter<\/strong>
\nRed Hat Verzeichnisdienst<\/code><\/p>\n

UUID LDAP-Attribut<\/strong>
\nipauniqueid<\/code><\/p>\n

Verbindungs-URL<\/strong>
\nldaps:\/\/freeipa.example.org<\/code><\/p>\n

Benutzer-DN<\/strong>
\ncn=users,cn=accounts,dc=example,dc=org<\/code><\/p>\n

Bind DN<\/strong>
\nuid=keycloak-svc,cn=users,cn=accounts,dc=example,dc=org<\/code><\/p>\n

Bind Credential<\/strong>
\n<password><\/code><\/p>\n

Kerberos-Authentifizierung erlauben:<\/strong>
\non<\/code><\/p>\n

Kerberos-Realm:<\/strong>
\nEXAMPLE.ORG<\/code><\/p>\n

Server Principal:<\/strong>
\nHTTP\/freeipa.example.org@EXAMPLE.ORG<\/code><\/p>\n

KeyTab:<\/strong>
\n\/etc\/krb5.keytab<\/code><\/p>\n

<\/p>\n

Benutzer keycloak-svc<\/code> muss im Voraus auf unserem LDAP-Server erstellt werden.<\/p>\n

<\/p>\n

Im Fall von Active Directory reicht es aus, einfach auszuw\u00e4hlen Anbieter: Active Directory<\/strong> und die erforderlichen Einstellungen werden automatisch in das Formular eingef\u00fcgt.<\/p>\n

<\/p>\n

Klicken Sie auf ), und klicken dann auf die Schaltfl\u00e4che<\/strong><\/p>\n

<\/p>\n

Gehen wir nun weiter:<\/p>\n

<\/p>\n

Benutzerf\u00f6deration<\/strong> \u2014> freeipa.example.org<\/strong> \u2014> Mapper<\/strong> \u2014> Vorname<\/strong><\/p>\n

<\/p>\n

Option
\nValue<\/p>\n

Ldap-Attribut<\/strong>
\ngivenName<\/code><\/p>\n

<\/p>\n

Aktivieren wir nun das Gruppenmapping:<\/p>\n

<\/p>\n

Benutzerf\u00f6deration<\/strong> \u2014> freeipa.example.org<\/strong> \u2014> Mapper<\/strong> \u2014> Erstellen<\/strong><\/p>\n

<\/p>\n

Option
\nValue<\/p>\n

Name<\/strong>
\nGruppen<\/code><\/p>\n

Mapper-Typ<\/strong>
\ngroup-ldap-mapper<\/code><\/p>\n

LDAP-Gruppen DN<\/strong>
\ncn=groups,cn=accounts,dc=example,dc=org<\/code><\/p>\n

Benutzergruppen-Abrufstrategie<\/strong>
\nGET_GROUPS_FROM_USER_MEMBEROF_ATTRIBUTE<\/code><\/p>\n

<\/p>\n

Damit ist die Federation-Konfiguration beendet, wir gehen zur Kundeneinrichtung \u00fcber.<\/p>\n

<\/p>\n

Client-Konfiguration<\/h2>\n

<\/p>\n

Wir erstellen einen neuen Client (eine Anwendung, die Benutzer aus Keycloak abruft). Gehen wir weiter:<\/p>\n

<\/p>\n

Clients<\/strong> \u2014> Erstellen<\/strong><\/p>\n

<\/p>\n

Option
\nValue<\/p>\n

Client-Geheimnis<\/strong>
\nkubernetes<\/code><\/p>\n

Zugriffstyp<\/strong>
\nconfidenzial<\/code><\/p>\n

Root-URL<\/strong>
\nhttp:\/\/kubernetes.example.org\/<\/code><\/p>\n

G\u00fcltige Weiterleitungs-URIs<\/strong>
\nhttp:\/\/kubernetes.example.org\/*<\/code><\/p>\n

Admin-URL<\/strong>
\nhttp:\/\/kubernetes.example.org\/<\/code><\/p>\n

<\/p>\n

Wir erstellen auch einen Scope f\u00fcr Gruppen:<\/p>\n

<\/p>\n

Client-Scope<\/strong> \u2014> Erstellen<\/strong><\/p>\n

<\/p>\n

Option
\nValue<\/p>\n

Vorlage<\/strong>
\nKein Template<\/code><\/p>\n

Name<\/strong>
\nGruppen<\/code><\/p>\n

Voller Gruppenspeicherpfad<\/strong>
\nfalse<\/code><\/p>\n

<\/p>\n

Und wir konfigurieren den Mapper f\u00fcr sie:<\/p>\n

<\/p>\n

Client-Scope<\/strong> \u2014> Gruppen<\/strong> \u2014> Mapper<\/strong> \u2014> Erstellen<\/strong><\/p>\n

<\/p>\n

Option
\nValue<\/p>\n

Name<\/strong>
\nGruppen<\/code><\/p>\n

Mapper-Typ<\/strong>
\nGruppenmitgliedschaft<\/code><\/p>\n

Token-Anspruchsname<\/strong>
\nGruppen<\/code><\/p>\n

<\/p>\n

Jetzt m\u00fcssen wir das Gruppenmapping in unserem Client-Scope aktivieren:<\/p>\n

<\/p>\n

Clients<\/strong> \u2014> kubernetes<\/strong> \u2014> Client-Scope<\/strong> \u2014> Standard-Client-Scope<\/strong><\/p>\n

<\/p>\n

W\u00e4hlen Sie Gruppen<\/strong> in Verf\u00fcgbare Client Scopes<\/strong>, dr\u00fccken Sie Ausgew\u00e4hlte hinzuf\u00fcgen<\/strong><\/p>\n

<\/p>\n

Jetzt richten wir die Authentifizierung unserer Anwendung ein, weiter geht's:<\/p>\n

<\/p>\n

Clients<\/strong> \u2014> kubernetes<\/strong><\/p>\n

<\/p>\n

Option
\nValue<\/p>\n

Autorisierung aktiviert<\/strong>
\nEIN<\/code><\/p>\n

<\/p>\n

Dr\u00fccken wir auf speichern<\/strong> und damit ist die Konfiguration des Clients abgeschlossen, nun auf dem Tab<\/p>\n

<\/p>\n

Clients<\/strong> \u2014> kubernetes<\/strong> \u2014> Credentials<\/strong><\/p>\n

<\/p>\n

wird es m\u00f6glich sein, Secret<\/strong> den wir sp\u00e4ter verwenden werden.<\/p>\n

<\/p>\n

Kubernetes-Konfiguration<\/h2>\n

<\/p>\n

Die Einrichtung von Kubernetes f\u00fcr OIDC-Authentifizierung ist recht trivial und nicht besonders komplex. Alles, was Sie ben\u00f6tigen, ist das CA-Zertifikat Ihres OIDC-Servers in \/etc\/kubernetes\/pki\/oidc-ca.pem<\/code> zu hinterlegen und die notwendigen Optionen f\u00fcr kube-apiserver hinzuzuf\u00fcgen.
\nAktualisieren Sie daher \/etc\/kubernetes\/manifests\/kube-apiserver.yaml<\/code> auf all Ihren Master-Servern:<\/p>\n

<\/p>\n

...
spec:
  containers:
  - command:
    - kube-apiserver
...\n    - --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
...<\/code><\/pre>\n
<\/p>\n
Aktualisieren Sie auch die kubeadm-Konfiguration im Cluster, um diese Einstellungen bei einem Upgrade nicht zu verlieren:<\/p>\n
<\/p>\n
kubectl edit -n kube-system configmaps kubeadm-config<\/code><\/pre>\n
<\/p>\n
...
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
...<\/code><\/pre>\n
<\/p>\n
Damit ist die Konfiguration von Kubernetes abgeschlossen. Sie k\u00f6nnen diese Schritte in all Ihren Kubernetes-Clustern wiederholen.<\/p>\n
<\/p>\n
Ersteinrichtung der Autorisierung<\/h2>\n
<\/p>\n
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\u00f6sen, m\u00fcssen Sie die automatische Bereitstellung von kubeconfig f\u00fcr Benutzer nach erfolgreicher Autorisierung einrichten.<\/p>\n
<\/p>\n
Hierf\u00fcr k\u00f6nnen spezielle Webanwendungen verwendet werden, die die Authentifizierung des Benutzers erm\u00f6glichen und dann das fertige kubeconfig zum Download bereitstellen. Eine der bequemsten Optionen ist Kuberos<\/a><\/noindex>, er erm\u00f6glicht es, alle Kubernetes-Cluster in einer Konfiguration zu beschreiben und leicht zwischen ihnen zu wechseln.<\/p>\n
<\/p>\n
F\u00fcr die Konfiguration von Kuberos m\u00fcssen Sie lediglich eine Vorlage f\u00fcr kubeconfig beschreiben und mit den folgenden Parametern starten:<\/p>\n
<\/p>\n
kuberos https:\/\/keycloak.example.org\/auth\/realms\/kubernetes kubernetes \/cfg\/secret \/cfg\/template<\/code><\/pre>\n
<\/p>\n
F\u00fcr detailliertere Informationen siehe Nutzung<\/a><\/noindex> auf Github.<\/p>\n
<\/p>\n
Es ist auch m\u00f6glich, kubelogin<\/a><\/noindex> zu verwenden, wenn Sie die Authentifizierung direkt auf dem Benutzercomputer durchf\u00fchren m\u00f6chten. In diesem Fall wird dem Benutzer ein Browser mit dem Authentifizierungsformular auf localhost ge\u00f6ffnet.<\/p>\n
<\/p>\n
Der erhaltene kubeconfig kann auf der Website \u00fcberpr\u00fcft werden jwt.io<\/a><\/noindex>. Kopieren Sie einfach den Wert users[].user.auth-provider.config.id-token<\/code> aus Ihrem kubeconfig in das Formular auf der Website und Sie erhalten sofort die Entschl\u00fcsselung.<\/p>\n
<\/p>\n
RBAC-Konfiguration<\/h2>\n
<\/p>\n
Bei der Konfiguration von RBAC kann sowohl auf den Benutzernamen (Feld name<\/code> im jwt-Token) als auch auf die Benutzergruppe (Feld Gruppen<\/code> im jwt-Token) verwiesen werden. Hier ein Beispiel f\u00fcr die Rechtevergabe an die Gruppe kubernetes-default-namespace-admins<\/code>:<\/p>\n
\nkubernetes-default-namespace-admins.yaml<\/b><\/p>\n
apiVersion: rbac.authorization.k8s.io\/v1\nkind: Role\nmetadata:\n  name: default-admins\n  namespace: default\nrules:\n- apiGroups:\n  - '*'\n  resources:\n  - '*'\n  verbs:\n  - '*'\n---\napiVersion: rbac.authorization.k8s.io\/v1\nkind: RoleBinding\nmetadata:\n  name: kubernetes-default-namespace-admins\n  namespace: default\nroleRef:\n  apiGroup: rbac.authorization.k8s.io\n  kind: Role\n  name: default-admins\nsubjects:\n- apiGroup: rbac.authorization.k8s.io\n  kind: Group\n  name: kubernetes-default-namespace-admins<\/code><\/pre>\n
<\/p>\n
Weitere Beispiele f\u00fcr RBAC finden Sie unter der offiziellen Kubernetes-Dokumentation<\/a><\/noindex><\/p>\n
<\/p>\n
Einrichtung des Auth-Proxys<\/h2>\n
<\/p>\n
Es gibt ein gro\u00dfartiges Projekt keycloak-gatekeeper<\/a><\/noindex>, das es erm\u00f6glicht, jede Anwendung zu sichern, indem es dem Benutzer die Authentifizierung \u00fcber einen OIDC-Server erm\u00f6glicht. Ich zeige Ihnen, wie Sie es am Beispiel des Kubernetes Dashboards einrichten k\u00f6nnen:<\/p>\n
\ndashboard-proxy.yaml<\/b><\/p>\n
apiVersion: extensions\/v1beta1\nkind: Deployment\nmetadata:\n  name: kubernetes-dashboard-proxy\nspec:\n  replicas: 1\n  template:\n    metadata:\n      labels:\n        app: kubernetes-dashboard-proxy\n    spec:\n      containers:\n      - args:\n        - --listen=0.0.0.0:80\n        - --discovery-url=https:\/\/keycloak.example.org\/auth\/realms\/kubernetes\n        - --client-id=kubernetes\n        - --client-secret=\n        - --redirection-url=https:\/\/kubernetes-dashboard.example.org\n        - --enable-refresh-tokens=true\n        - --encryption-key=ooTh6Chei1eefooyovai5ohwienuquoh\n        - --upstream-url=https:\/\/kubernetes-dashboard.kube-system\n        - --resources=uri=\/*\n        image: keycloak\/keycloak-gatekeeper\n        name: kubernetes-dashboard-proxy\n        ports:\n        - containerPort: 80\n          livenessProbe:\n            httpGet:\n              path: \/oauth\/health\n              port: 80\n            initialDelaySeconds: 3\n            timeoutSeconds: 2\n          readinessProbe:\n            httpGet:\n              path: \/oauth\/health\n              port: 80\n            initialDelaySeconds: 3\n            timeoutSeconds: 2\n---\napiVersion: v1\nkind: Service\nmetadata:\n  name: kubernetes-dashboard-proxy\nspec:\n  ports:\n  - port: 80\n    protocol: TCP\n    targetPort: 80\n  selector:\n    app: kubernetes-dashboard-proxy\n  type: ClusterIP<\/code><\/pre>\n
Quelle: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u041d\u0435\u0431\u043e\u043b\u044c\u0448\u0430\u044f \u0438\u043d\u0441\u0442\u0440\u0443\u043a\u0446\u0438\u044f \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u044f Keycloak \u043c\u043e\u0436\u043d\u043e \u0441\u0432\u044f\u0437\u0430\u0442\u044c Kubernetes \u0441 \u0432\u0430\u0448\u0438\u043c LDAP-\u0441\u0435\u0440\u0432\u0435\u0440\u043e\u043c \u0438 \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u0442\u044c \u0438\u043c\u043f\u043e\u0440\u0442 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0438 \u0433\u0440\u0443\u043f\u043f. \u042d\u0442\u043e \u043f\u043e\u0437\u0432\u043e\u043b\u0438\u0442 \u043d\u0430\u0441\u0442\u0440\u0430\u0438\u0432\u0430\u0442\u044c RBAC \u0434\u043b\u044f \u0432\u0430\u0448\u0438\u0445 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0438 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c auth-proxy \u0447\u0442\u043e\u0431\u044b \u0437\u0430\u0449\u0438\u0442\u0438\u0442\u044c Kubernetes Dashboard \u0438 \u0434\u0440\u0443\u0433\u0438\u0435 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043d\u0435 \u0443\u043c\u0435\u044e\u0442 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u044c \u0430\u0432\u0442\u043e\u0440\u0438\u0437\u0430\u0446\u0438\u044e \u0441\u0430\u043c\u043e\u0441\u0442\u043e\u044f\u0442\u0435\u043b\u044c\u043d\u043e. \u0423\u0441\u0442\u0430\u043d\u043e\u0432\u043a\u0430 Keycloak \u041f\u0440\u0435\u0434\u043f\u043e\u043b\u043e\u0436\u0438\u043c \u0447\u0442\u043e \u0443 \u0432\u0430\u0441 \u0443\u0436\u0435 \u0435\u0441\u0442\u044c LDAP-\u0441\u0435\u0440\u0432\u0435\u0440. \u042d\u0442\u043e \u043c\u043e\u0436\u0435\u0442 \u0431\u044b\u0442\u044c Active […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":70868,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-70867","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Integration der LDAP-Authentifizierung in Kubernetes | ProHoster","description":"Eine kurze Anleitung, wie Sie mit Keycloak Kubernetes mit Ihrem LDAP-Server verbinden und den Import von Benutzern und Gruppen konfigurieren k\u00f6nnen. Dies erm\u00f6glicht die Einrichtung von RBAC f\u00fcr Ihre Benutzer und die Verwendung eines Auth-Proxys, um das Kubernetes Dashboard und andere Anwendungen zu sch\u00fctzen, die keine eigene Authentifizierung durchf\u00fchren k\u00f6nnen. Installation von Keycloak Angenommen, Sie haben bereits einen LDAP-Server. Dies kann Active sein.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/prikruchivaem-ldap-avtorizacziyu-k-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041f\u0440\u0438\u043a\u0440\u0443\u0447\u0438\u0432\u0430\u0435\u043c LDAP-\u0430\u0432\u0442\u043e\u0440\u0438\u0437\u0430\u0446\u0438\u044e \u043a Kubernetes | ProHoster","og:description":"\u041d\u0435\u0431\u043e\u043b\u044c\u0448\u0430\u044f \u0438\u043d\u0441\u0442\u0440\u0443\u043a\u0446\u0438\u044f \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u044f Keycloak \u043c\u043e\u0436\u043d\u043e \u0441\u0432\u044f\u0437\u0430\u0442\u044c Kubernetes \u0441 \u0432\u0430\u0448\u0438\u043c LDAP-\u0441\u0435\u0440\u0432\u0435\u0440\u043e\u043c \u0438 \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u0442\u044c \u0438\u043c\u043f\u043e\u0440\u0442 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0438 \u0433\u0440\u0443\u043f\u043f. \u042d\u0442\u043e \u043f\u043e\u0437\u0432\u043e\u043b\u0438\u0442 \u043d\u0430\u0441\u0442\u0440\u0430\u0438\u0432\u0430\u0442\u044c RBAC \u0434\u043b\u044f \u0432\u0430\u0448\u0438\u0445 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0438 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c auth-proxy \u0447\u0442\u043e\u0431\u044b \u0437\u0430\u0449\u0438\u0442\u0438\u0442\u044c Kubernetes Dashboard \u0438 \u0434\u0440\u0443\u0433\u0438\u0435 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043d\u0435 \u0443\u043c\u0435\u044e\u0442 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u044c \u0430\u0432\u0442\u043e\u0440\u0438\u0437\u0430\u0446\u0438\u044e \u0441\u0430\u043c\u043e\u0441\u0442\u043e\u044f\u0442\u0435\u043b\u044c\u043d\u043e. \u0423\u0441\u0442\u0430\u043d\u043e\u0432\u043a\u0430 Keycloak \u041f\u0440\u0435\u0434\u043f\u043e\u043b\u043e\u0436\u0438\u043c \u0447\u0442\u043e \u0443 \u0432\u0430\u0441 \u0443\u0436\u0435 \u0435\u0441\u0442\u044c LDAP-\u0441\u0435\u0440\u0432\u0435\u0440. \u042d\u0442\u043e \u043c\u043e\u0436\u0435\u0442 \u0431\u044b\u0442\u044c Active","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/prikruchivaem-ldap-avtorizacziyu-k-kubernetes","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-02-22T03:40:58+00:00","article:modified_time":"2020-03-03T13:14:36+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"70867","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 19:12:23","updated":"2022-09-28 01:58:51"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/70867","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=70867"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/70867\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/70868"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=70867"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=70867"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=70867"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}