🥇Свързване на 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 chart и да го инсталирате направо в клъстера си.

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

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

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

Натискаме Добави област

Опция
Value

Name
kubernetes

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

Име за показване в HTML
<img src="https://kubernetes.io/images/nav_logo.svg" width="400" >

Kubernetes по подразбиране проверява дали имейлът на потребителя е потвърден. Тъй като използваме собствен LDAP сървър, проверката почти винаги ще връща false. Нека деактивираме представянето на този параметър в Kubernetes:

Клиентски обхвати —> Имейл —> Mapperи —> Потвърден имейл (Изтрий)

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

Федерация на потребители —> Добави доставчик... —> ldap

Ще дам пример за настройка за FreeIPA:

Опция
Value

Име за показване в конзолата
freeipa.example.org

Доставчик
Red Hat Directory Server

UUID LDAP атрибут
ipauniqueid

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 удостоверяване:
on

Kerberos Realm:
EXAMPLE.ORG

Сървърен Principal:
HTTP/freeipa.example.org@EXAMPLE.ORG

KeyTab:
/etc/krb5.keytab

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

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

Натискаме Save

Сега преминаваме на:

Федерация на потребители —> freeipa.example.org —> Mapperи —> Първо име

Опция
Value

LDAP атрибут
givenName

Сега ще включим мапинга на групи:

Федерация на потребители —> freeipa.example.org —> Mapperи —> Create

Опция
Value

Name
groups

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

LDAP Groups DN
cn=groups,cn=accounts,dc=example,dc=org

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

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

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

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

Клиенти —> Create

Опция
Value

Client secret
kubernetes

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

Основен URL
http://kubernetes.example.org/

Валидни URI за пренасочване
http://kubernetes.example.org/*

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

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

Обхвати на клиенти —> Create

Опция
Value

Шаблон
Няма шаблон

Name
groups

Цялостен път на групата
false

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

Обхвати на клиенти —> groups —> Mapperи —> Create

Опция
Value

Name
groups

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

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

Сега трябва да включим мапинга на групи в нашия клиентски обхват:

Клиенти —> kubernetes —> Обхвати на клиенти —> Основни клиентски обхвати

Избираме groups в Достъпни Client Scopes, натискаме Добави избраните

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

Клиенти —> kubernetes

Опция
Value

Активиране на авторизация
ДА

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

Клиенти —> kubernetes —> Удостоверения

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

Настройка на 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 можете да се позовавате както на името на потребителя (полето име в 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