ProHoster > Блог > Администриране > Свързване на LDAP удостоверяване с Kubernetes

Свързване на LDAP удостоверяване с Kubernetes

Свързване на LDAP удостоверяване с Kubernetes

Невелика инструкция за това как с помощта на Keycloak можете да свържете Kubernetes с вашия LDAP-сървър и да настроите импорта на потребители и групи. Това ще ви позволи да конфигурирате RBAC за вашите потребители и да използвате auth-proxy за защита на Kubernetes Dashboard и други приложения, които не могат да извършват авторизация сами.

Инсталиране на Keycloak

Предполагаме, че вече разполагате с LDAP-сървър. Това може да бъде Active Directory, FreeIPA, OpenLDAP или нещо друго. Ако нямате LDAP-сървър, можете в действителност да създавате потребители директно в интерфейса на Keycloak или да използвате публични oidc-провайдери (Google, Github, Gitlab), резултатът ще бъде почти същият.

Първо, ще инсталираме самия Keycloak; инсталацията може да се извърши отделно или директно в Kubernetes клъстера. Обикновено, ако разполагате с няколко Kubernetes клъстера, би било по-лесно да го инсталирате отделно. От друга страна, винаги можете да използвате официалния helm-чарт и да го инсталирате направо в вашия клъстер.

За съхранение на данните на Keycloak ще ви е необходима база данни. По подразбиране се използва h2 (всички данни се съхраняват локално), но е възможно също да се използва postgres, mysql или mariadb.
Ако все пак сте решили да инсталирате Keycloak отделно, по-подробни инструкции можете да намерите в официалната документация.

Настройка на федерацията

Първо, ще създадем нов realm. Realm е пространството на нашето приложение. Всяко приложение може да има свой realm с различни потребители и настройки за авторизация. Master realm се използва от самия Keycloak и не е правилно да го използвате за нещо друго.

Натиснете Добавяне на област

Option
Стойност

Name
kubernetes

Показваме име
Kubernetes

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

Kubernetes по подразбиране проверява дали e-mail адресът на потребителя е потвърден. Понеже използваме собствен LDAP-сървър, тази проверка почти винаги ще връща неверно. Нека деактивираме показването на този параметър в Kubernetes:

Client scopes —> Email —> Mappers —> Email verified (Изтрий)

Сега ще настроим федерацията, за това ще отидем на:

User federation —> Добави провайдер… —> ldap

Пример за настройка за FreeIPA:

Option
Стойност

Console Display Name
freeipa.example.org

Продавач
Red Hat Directory Server

UUID LDAP attribute
ipauniqueid

Connection URL
ldaps://freeipa.example.org

Users 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 удостоверяване:
включено

Kerberos Realm:
EXAMPLE.ORG

Сървърен принципал:
HTTP/freeipa.example.org@EXAMPLE.ORG

KeyTab:
/etc/krb5.keytab

Потребителят keycloak-svc трябва да бъде създаден предварително на нашия LDAP-сървър.

В случая с Active Directory, просто изберете Vendor: Active Directory и необходимите настройки ще бъдат автоматично поставени в формуляра.

Натиснете Запази

Сега ще отидем на:

User federation —> freeipa.example.org —> Mappers —> Име

Option
Стойност

Ldap атрибут
givenName

Сега ще активираме мапинга на групи:

User federation —> freeipa.example.org —> Mappers —> Create

Option
Стойност

Name
groups

Тип на мапера
group-ldap-mapper

LDAP Groups DN
cn=групи,cn=акаунти,dc=example,dc=org

Стратегия за извличане на потребителски групи
GET_GROUPS_FROM_USER_MEMBEROF_ATTRIBUTE

С това настройката на федерацията приключва, преминаваме към настройката на клиента.

Настройка на клиента

Ще създадем нов клиент (приложение, което ще получава потребителите от Keycloak). Преминаваме към:

Клиенти —> Create

Option
Стойност

Client ID
kubernetes

Тип на достъпа
конфиденциален

Коренен URL
http://kubernetes.example.org/

Валидни редирект URIs
http://kubernetes.example.org/*

Административен URL
http://kubernetes.example.org/

Също така ще създадем scope за групи:

Client Scopes —> Create

Option
Стойност

Шаблон
Без шаблон

Name
groups

Пълен път на групата
неверно

И ще настроим маппер за тях:

Client Scopes —> groups —> Mappers —> Create

Option
Стойност

Name
groups

Тип на мапера
Членство в група

Име на токенен клейм
groups

Сега трябва да активираме мапинга на групи в нашия client scope:

Клиенти —> kubernetes —> Client Scopes —> Default Client Scopes

Избираме groups в Налични Client Scopes, натискаме Добави избраните

Сега ще настроим аутентификацията на нашето приложение, преминаваме към:

Клиенти —> kubernetes

Option
Стойност

Разрешена авторизация
ON

Натиснете запазване и с това настройката на клиента е завършена, сега в раздела

Клиенти —> kubernetes —> Credentials

можете да получите Secret което ще използваме по-късно.

Настройка на Kubernetes

Настройката на Kubernetes за OIDC-авторизация е достатъчно тривиална и не е нещо особено сложно. Всичко, което трябва да направите, е да поставите CA-сертификата на вашия OIDC-сървър в /etc/kubernetes/pki/oidc-ca.pem и да добавите необходимите опции за kube-apiserver.
За това актуализирайте /etc/kubernetes/manifests/kube-apiserver.yaml на всички ваши майстори:

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

И също така обновете kubeadm конфиг в клъстера, за да не загубите тези настройки при актуализиране:

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

С това настройката на Kubernetes приключва. Можете да повторите тези действия във всички ваши Kubernetes клъстери.

Начална авторизация

След тези действия вече ще имате Kubernetes клъстер с настроена OIDC авторизация. Единственото нещо е, че вашите потребители все още нямат настроен клиент, както и собствен kubeconfig. За да решите този проблем, трябва да настроите автоматично издаване на kubeconfig на потребителите след успешна авторизация.

За това можете да използвате специализирани уеб приложения, които позволяват аутентификация на потребителя, а след това да свалят готов kubeconfig. Едно от най-удобните е Kuberos, той позволява в един конфиг да опишете всички Kubernetes клъстери и лесно да превключвате между тях.

За настройка на Kuberos е достатъчно да опишете шаблон за kubeconfig и да стартирате с следните параметри:

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

За по-подробна информация вижте Използване на Github.

Също така е възможно да се използва kubelogin ако искате да извършите удостоверяване директно на компютъра на потребителя. В този случай на потребителя ще се отвори браузър с формуляр за удостоверяване на localhost.

Полученият kubeconfig може да бъде проверен на сайта jwt.io. Просто копирайте стойността users[].user.auth-provider.config.id-token от вашия kubeconfig във формуляра на сайта и незабавно ще получите декодирането.

Настройка на RBAC

При настройка на RBAC можете да се обръщате както към името на потребителя (полето name в jwt-токена), така и към групата потребители (полето groups в jwt-токена). Ето пример за настройка на правата за групата 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

Повече примери за RBAC можете да намерите в официалната документация на Kubernetes

Конфигуриране на auth-proxy

Има чудесен проект keycloak-gatekeeper, който позволява защита на всяко приложение, предоставяйки на потребителя възможността да се удостоверява на OIDC-сървера. Ще покажа как можете да го настроите на примера на Kubernetes Dashboard:

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

Източник: habr.com

Купете надежден хостинг за сайтове със защита от DDoS, VPS и VDS сървъри 🔥 Купете надежден хостинг за сайтове със защита от DDoS, VPS и VDS сървъри | ProHoster