Ние закрепваме разрешението на ActiveDirectory към Kubernetes с помощта на Keycloak

Тази статия е написана, за да разшири вече съществуващи, но говори за функциите на пакета с Microsoft ActiveDirectory и също така го допълва.

В тази статия ще ви кажа как да инсталирате и конфигурирате:

• ключодържател е проект с отворен код. Което осигурява единна входна точка за приложения. Работи с много протоколи, включително LDAP и OpenID, които ни интересуват.
• ключодържател вратар - обратно прокси приложение, което ви позволява да интегрирате оторизация чрез Keycloak.
• щрек - приложение, което генерира конфигурация за kubectl, с която можете да влезете и да се свържете с Kubernetes API чрез OpenID.

Как работят разрешенията в Kubernetes.

Можем да управляваме потребителски / групови права с помощта на RBAC, вече са създадени куп статии за това, няма да се спирам на това подробно. Проблемът е, че можете да използвате RBAC, за да ограничите потребителските права, но Kubernetes не знае нищо за потребителите. Оказва се, че се нуждаем от механизъм за доставка на потребителите в Kubernetes. За да направим това, ще добавим доставчик към Kuberntes OpenID, който ще каже, че такъв потребител наистина съществува и самият Kubernetes ще му даде правата.

Обучение

• Ще ви трябва Kubernetes клъстер или minikube
• Active Directory
• Домейни:
  keycloak.example.org
  kubernetes-dashboard.example.org
  проход.example.org
• Сертификат за домейни или самоподписан сертификат

Няма да се спирам на това как да създадете самоподписан сертификат, трябва да създадете 2 сертификата, това е основният (сертифициращ орган) и клиент с заместващи символи за домейна *.example.org

След като получите / издадете сертификати, клиентът трябва да бъде добавен към Kubernetes, за това ние създаваме тайна за него:

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

След това ще го използваме за нашия Ingress контролер.

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

Реших, че най-лесно е да използвам готови решения за това, а именно helm charts.

Инсталирайте хранилището и го актуализирайте:

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

Създайте файл keycloak.yml със следното съдържание:

keycloak.yml

keycloak:
  # Имя администратора
  username: "test_admin"
  # Пароль администратор  
  password: "admin"
  # Эти флаги нужны что бы позволить загружать в Keycloak скрипты прямо через web морду. Это нам 
  понадобиться что бы починить один баг, о котором ниже.
  extraArgs: "-Dkeycloak.profile.feature.script=enabled -Dkeycloak.profile.feature.upload_scripts=enabled" 
  # Включаем ingress, указываем имя хоста и сертификат который мы предварительно сохранили в secrets
  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 для своей работы требует базу данных, в тестовых целях я разворачиваю Postgresql прямо в Kuberntes, в продакшене так лучше не делать!
  persistence:
    deployPostgres: true
    dbVendor: postgres

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

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

След това отидете на уеб интерфейса keycloak.example.org

Кликнете в левия ъгъл Добавете област

ключ
Стойност

Име
кубернети

Име за показване
Kubernetes

Деактивиране на проверката на потребителския имейл:
Клиентски обхват —> Имейл —> Картографи —> Проверен имейл (Изтриване)

Настроихме федерация за импортиране на потребители от ActiveDirectory, ще оставя екранни снимки по-долу, мисля, че ще бъде по-ясно.

Потребителска федерация —> Добавяне на доставчик… —> ldap

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


Ако всичко е наред, след натискане на бутона Синхронизирайте всички потребители ще видите съобщение за успешното импортиране на потребители.

След това трябва да картографираме нашите групи

Потребителска федерация --> ldap_localhost --> Mappers --> Create

Създаване на картограф

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

Необходимо е да създадете клиент, по отношение на Keycloak, това е приложение, което ще бъде разрешено от него. Ще подчертая важните точки в екранната снимка в червено.

Клиенти —> Създаване

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

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

Клиентски обхвати —> Създаване

Създайте обхват

И настройте картограф за тях:

Клиентски обхват —> групи —> Картографи —> Създаване

Картограф

Добавете картографирането на нашите групи към клиентските обхвати по подразбиране:

Клиенти —> kubernetes —> Клиентски обхвати —> Клиентски обхвати по подразбиране
Изберете групи в Налични клиентски обхватинатиснете Добавяне на избрани

Получаваме тайната (и я записваме в нишката), която ще използваме за оторизация в Keycloak:

Клиенти —> kubernetes —> Идентификационни данни —> Тайно
Това завършва настройката, но имах грешка, когато след успешно оторизиране получих грешка 403. Доклад за грешка.

Поправка:

Клиентски обхват —> роли —> Картографи —> Създаване

Картограф

Код на скрипта

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

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

Конфигуриране на Kubernetes

Трябва да посочим къде се намира основният ни сертификат от сайта и къде се намира доставчикът на OIDC.
За да направите това, редактирайте файла /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
...

Актуализирайте конфигурацията на kubeadm в клъстера:

kubeadmconfig

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

Настройка на прокси за удостоверяване

Можете да използвате keycloak gatekeeper, за да защитите вашето уеб приложение. В допълнение към факта, че този обратен прокси ще упълномощи потребителя, преди да покаже страницата, той също ще предаде информация за вас на крайното приложение в заглавките. По този начин, ако вашето приложение поддържа OpenID, тогава потребителят е незабавно упълномощен. Помислете за примера на Kubernetes Dashboard

Инсталиране на Kubernetes Dashboard

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'

Задаване на права за достъп:

Нека създадем ClusterRoleBinding, който ще даде администраторски права на клъстер (стандартен ClusterRole cluster-admin) за потребителите в групата DataOPS.

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

Инсталирайте 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"

След това, когато се опитате да отидете на kubernetes-dashboard.example.org, ще бъдем пренасочени към Keycloak и в случай на успешна авторизация ще стигнем до таблото за управление, вече влезли в системата.

монтаж на пътека

За удобство можете да добавите проход, който ще генерира конфигурационен файл за kubectl, с помощта на който ще влезем в Kubernetes под нашия потребител.

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

values_gangway.yaml

gangway:
  # Произвольное имя кластера
  clusterName: "my-k8s"
  # Где у нас OIDC провайдер
  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"
  # Теоритически сюда можно добавить groups которые мы замапили
  scopes: ["openid", "profile", "email", "offline_access"]
  redirectURL: "https://gangway.example.org/callback"
  # Имя клиента
  clientID: "kubernetes"
  # Секрет
  clientSecret: "c6ec03b8-d0b8-4cb6-97a0-03becba1d727"
  # Если оставить дефолтное значние, то за имя пользователя будет братья <b>Frist name</b> <b>Second name</b>, а при "sub" его логин
  usernameClaim: "sub"
  # Доменное имя или IP адресс API сервера
  apiServerURL: "https://192.168.99.111:8443"

# Включаем 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

# Если используем самоподписанный сертификат, то его(открытый корневой сертификат) надо указать.
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-----

Изглежда така. Позволява ви незабавно да изтеглите конфигурационния файл и да го генерирате с помощта на набор от команди:

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