{"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\/en\/blog\/administrirovanie\/prikruchivaem-ldap-avtorizacziyu-k-kubernetes","title":{"rendered":"Integrating LDAP Authentication with Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Integrating<\/p>\n

<\/p>\n

A short guide on how to link Kubernetes with your LDAP server using Keycloak and set up user and group imports. This will allow you to configure RBAC for your users and use auth-proxy to secure the Kubernetes Dashboard and other applications that cannot authenticate on their own.<\/p>\n

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

Installing Keycloak<\/h2>\n

<\/p>\n

Assuming you already have an LDAP server. This can be Active Directory, FreeIPA, OpenLDAP, or something else. If you don't have an LDAP server, you can create users directly in the Keycloak interface or use public OIDC providers (Google, GitHub, GitLab); the result will be almost the same.<\/p>\n

<\/p>\n

First, we'll install Keycloak itself; installation can be done separately or directly in the Kubernetes cluster. Generally, if you have multiple Kubernetes clusters, it would be easier to install it separately. On the other hand, you can always use the official helm chart<\/a><\/noindex> and install it directly in your cluster.<\/p>\n

<\/p>\n

To store Keycloak data, you will need a database. By default, it uses h2<\/code> (all data is stored locally), but you can also use postgres<\/code>, mysql<\/code> or mariadb<\/code>.
\nIf you decide to install Keycloak separately, you will find more detailed instructions in the official documentation.<\/a><\/noindex>.<\/p>\n

<\/p>\n

Setting Up Federation<\/h2>\n

<\/p>\n

First, let's create a new realm. A realm is the space for our application. Each application can have its own realm with different users and authorization settings. The master realm is used by Keycloak itself, and it is not appropriate to use it for anything else.<\/p>\n

<\/p>\n

Click Add realm<\/strong><\/p>\n

<\/p>\n

Option
\nValue<\/p>\n

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

Display Name<\/strong>
\nKubernetes<\/code><\/p>\n

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

<\/p>\n

Kubernetes checks whether the user's email is verified by default. Since we are using our own LDAP server, this check will almost always return false<\/code>. Let's disable the display of this parameter in Kubernetes:<\/p>\n

<\/p>\n

Client scopes<\/strong> \u2192 Email<\/strong> \u2192 Mappers<\/strong> \u2192 Email verified<\/strong> (Delete)<\/p>\n

<\/p>\n

Now let's configure federation; for this, we will go to:<\/p>\n

<\/p>\n

User federation<\/strong> \u2192 Add provider\u2026<\/strong> \u2192 ldap<\/strong><\/p>\n

<\/p>\n

Here's an example configuration for FreeIPA:<\/p>\n

<\/p>\n

Option
\nValue<\/p>\n

Console Display Name<\/strong>
\nfreeipa.example.org<\/code><\/p>\n

Vendor<\/strong>
\nRed Hat Directory Server<\/code><\/p>\n

UUID LDAP attribute<\/strong>
\nipauniqueid<\/code><\/p>\n

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

Users 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

Allow Kerberos authentication:<\/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

The user keycloak-svc<\/code> needs to be pre-created on our LDAP server.<\/p>\n

<\/p>\n

In the case of Active Directory, simply select Vendor: Active Directory<\/strong> and the necessary settings will automatically populate the form.<\/p>\n

<\/p>\n

Click Save<\/strong><\/p>\n

<\/p>\n

Now let's proceed:<\/p>\n

<\/p>\n

User federation<\/strong> \u2192 freeipa.example.org<\/strong> \u2192 Mappers<\/strong> \u2192 First Name<\/strong><\/p>\n

<\/p>\n

Option
\nValue<\/p>\n

Ldap attribute<\/strong>
\ngivenName<\/code><\/p>\n

<\/p>\n

Now we will enable group mapping:<\/p>\n

<\/p>\n

User federation<\/strong> \u2192 freeipa.example.org<\/strong> \u2192 Mappers<\/strong> \u2192 Create<\/strong><\/p>\n

<\/p>\n

Option
\nValue<\/p>\n

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

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

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

User Groups Retrieve Strategy<\/strong>
\nGET_GROUPS_FROM_USER_MEMBEROF_ATTRIBUTE<\/code><\/p>\n

<\/p>\n

With this, the federation setup is complete; let's move on to client configuration.<\/p>\n

<\/p>\n

Client Configuration<\/h2>\n

<\/p>\n

We'll create a new client (the application that will receive users from Keycloak). Let's go to:<\/p>\n

<\/p>\n

Clients<\/strong> \u2192 Create<\/strong><\/p>\n

<\/p>\n

Option
\nValue<\/p>\n

Client ID<\/strong>
\nkubernetes<\/code><\/p>\n

Access Type<\/strong>
\nconfidential<\/code><\/p>\n

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

Valid Redirect URIs<\/strong>
\nhttp:\/\/kubernetes.example.org\/*<\/code><\/p>\n

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

<\/p>\n

We will also create a scope for groups:<\/p>\n

<\/p>\n

Client Scopes<\/strong> \u2192 Create<\/strong><\/p>\n

<\/p>\n

Option
\nValue<\/p>\n

Template<\/strong>
\nNo template<\/code><\/p>\n

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

Full group path<\/strong>
\nfalse<\/code><\/p>\n

<\/p>\n

And we'll configure the mapper for them:<\/p>\n

<\/p>\n

Client Scopes<\/strong> \u2192 groups<\/strong> \u2192 Mappers<\/strong> \u2192 Create<\/strong><\/p>\n

<\/p>\n

Option
\nValue<\/p>\n

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

Mapper Type<\/strong>
\nGroup membership<\/code><\/p>\n

Token Claim Name<\/strong>
\ngroups<\/code><\/p>\n

<\/p>\n

Now we need to enable group mapping in our client scope:<\/p>\n

<\/p>\n

Clients<\/strong> \u2192 kubernetes<\/strong> \u2192 Client Scopes<\/strong> \u2192 Default Client Scopes<\/strong><\/p>\n

<\/p>\n

Select groups<\/strong> downward API support (simultaneously with this in Available Client Scopes<\/strong>, click Add selected<\/strong><\/p>\n

<\/p>\n

Now let's configure the authentication of our application by going to:<\/p>\n

<\/p>\n

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

<\/p>\n

Option
\nValue<\/p>\n

Authorization Enabled<\/strong>
\nON<\/code><\/p>\n

<\/p>\n

Click save<\/strong> and this completes the client configuration. Now on the tab<\/p>\n

<\/p>\n

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

<\/p>\n

you will be able to obtain Secret<\/strong> which we will use later.<\/p>\n

<\/p>\n

Kubernetes Configuration<\/h2>\n

<\/p>\n

Configuring Kubernetes for OIDC authorization is quite straightforward and not overly complex. All you need to do is place the CA certificate of your OIDC server in \/etc\/kubernetes\/pki\/oidc-ca.pem<\/code> and add the necessary options for kube-apiserver.
\nTo do this, update \/etc\/kubernetes\/manifests\/kube-apiserver.yaml<\/code> on all your masters:<\/p>\n

<\/p>\n

...\nspec:\n  containers:\n  - command:\n    - kube-apiserver\n...\n    - --oidc-ca-file=\/etc\/kubernetes\/pki\/oidc-ca.pem\n    - --oidc-client-id=kubernetes\n    - --oidc-groups-claim=groups\n    - --oidc-issuer-url=https:\/\/keycloak.example.org\/auth\/realms\/kubernetes\n    - --oidc-username-claim=email\n...<\/code><\/pre>\n
<\/p>\n
Also update the kubeadm config in the cluster to avoid losing these settings during upgrades:<\/p>\n
<\/p>\n
kubectl edit -n kube-system configmaps kubeadm-config<\/code><\/pre>\n
<\/p>\n
...\ndata:\n  ClusterConfiguration: |\n    apiServer:\n      extraArgs:\n        oidc-ca-file: \/etc\/kubernetes\/pki\/oidc-ca.pem\n        oidc-client-id: kubernetes\n        oidc-groups-claim: groups\n        oidc-issuer-url: https:\/\/keycloak.example.org\/auth\/realms\/kubernetes\n        oidc-username-claim: email\n...<\/code><\/pre>\n
<\/p>\n
With this, the Kubernetes setup is complete. You can repeat these actions across all your Kubernetes clusters.<\/p>\n
<\/p>\n
Initial Authorization<\/h2>\n
<\/p>\n
After these steps, you will have a Kubernetes cluster configured with OIDC authorization. The only thing is that your users do not yet have a configured client or their own kubeconfig. To resolve this issue, automatic kubeconfig issuance for users after successful authorization must be set up.<\/p>\n
<\/p>\n
You can use special web applications that allow user authentication and then download the ready kubeconfig. One of the most convenient is Kuberos<\/a><\/noindex>, which allows you to describe all Kubernetes clusters in one config and easily switch between them.<\/p>\n
<\/p>\n
To set up Kuberos, it is enough to describe the template for kubeconfig and run it with the following parameters:<\/p>\n
<\/p>\n
kuberos https:\/\/keycloak.example.org\/auth\/realms\/kubernetes kubernetes \/cfg\/secret \/cfg\/template<\/code><\/pre>\n
<\/p>\n
For more detailed information, see Usage<\/a><\/noindex> on Github.<\/p>\n
<\/p>\n
You can also use kubelogin<\/a><\/noindex> if you want to perform authentication directly on the user's computer. In this case, a browser will open for the user with an authorization form on localhost.<\/p>\n
<\/p>\n
The resulting kubeconfig can be checked on the website jwt.io<\/a><\/noindex>. Just copy the value users[].user.auth-provider.config.id-token<\/code> from your kubeconfig into the form on the site and you will immediately receive the decoding.<\/p>\n
<\/p>\n
RBAC Configuration<\/h2>\n
<\/p>\n
When configuring RBAC, you can refer to both the username (field name<\/code> in the jwt token) and the user group (field groups<\/code> in the jwt token). Here is an example of permission settings for the group 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
More examples for RBAC can be found in the official Kubernetes documentation<\/a><\/noindex><\/p>\n
<\/p>\n
auth-proxy Configuration<\/h2>\n
<\/p>\n
There is a wonderful project keycloak-gatekeeper<\/a><\/noindex>, which allows you to protect any application by providing the user with the ability to authenticate on the OIDC server. I will show how to configure it using the example of Kubernetes Dashboard:<\/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
Source: 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\udd47Integrating LDAP authentication with Kubernetes | ProHoster","description":"A brief guide on how to.","canonical_url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/prikruchivaem-ldap-avtorizacziyu-k-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"en_US","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.","og:url":"https:\/\/prohoster.info\/en\/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","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/70867","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/comments?post=70867"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/70867\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media\/70868"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media?parent=70867"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/categories?post=70867"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/tags?post=70867"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}