🥇Przypinamy autoryzację ActiveDirectory do Kubernetes za pomocą Keycloak

Ten artykuł został napisany w celu rozwinięcia już istniejący, ale mówi o funkcjach pakietu z Microsoft ActiveDirectory, a także go uzupełnia.

W tym artykule powiem ci, jak zainstalować i skonfigurować:

Keyclock jest projektem typu open source. Który zapewnia pojedynczy punkt wejścia dla aplikacji. Działa z wieloma protokołami, w tym z interesującymi nas LDAP i OpenID.
odźwierny klucznik - aplikacja odwrotnego proxy, która pozwala na integrację autoryzacji poprzez Keycloak.
Przejście - aplikacja, która generuje konfigurację dla kubectl, za pomocą której możesz się zalogować i połączyć z Kubernetes API przez OpenID.

Jak działają uprawnienia w Kubernetes.

Możemy zarządzać prawami użytkowników / grup za pomocą RBAC, powstało już kilka artykułów na ten temat, nie będę się nad tym szczegółowo rozwodził. Problem polega na tym, że możesz użyć RBAC do ograniczenia praw użytkowników, ale Kubernetes nic nie wie o użytkownikach. Okazuje się, że potrzebujemy mechanizmu dostarczania użytkownika w Kubernetes. W tym celu do Kubernetes OpenID dodamy dostawcę, który powie, że taki użytkownik naprawdę istnieje, a sam Kubernetes nada mu uprawnienia.

Szkolenie

Będziesz potrzebować klastra Kubernetes lub minikube
Active Directory
Domeny:
keycloak.example.org
kubernetes-dashboard.example.org
przejście.przykład.org
Certyfikat dla domen lub certyfikat z podpisem własnym

Nie będę rozwodził się nad tym, jak utworzyć certyfikat z podpisem własnym, musisz utworzyć 2 certyfikaty, to jest klient root (Certificate Authority) i wieloznaczny dla domeny *.example.org

Po otrzymaniu/wydaniu certyfikatów klient musi zostać dodany do Kubernetes, w tym celu tworzymy dla niego sekret:

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

Następnie użyjemy go dla naszego kontrolera Ingress.

Instalacja klucza

Uznałem, że najprościej będzie wykorzystać do tego gotowe rozwiązania, a mianowicie wykresy sterowe.

Zainstaluj repozytorium i zaktualizuj je:

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

Utwórz plik keycloak.yml o następującej zawartości:

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

Konfiguracja federacji

Następnie przejdź do interfejsu internetowego keycloak.example.org

Kliknij w lewym rogu Dodaj dziedzinę

Klawisz
wartość

Imię
Kubernetes

Wyświetlana nazwa
Kubernetes

Wyłącz weryfikację adresu e-mail użytkownika:
Zakresy klienta —> E-mail —> Mapery —> E-mail zweryfikowany (Usuń)

Skonfigurowaliśmy federację, aby importować użytkowników z ActiveDirectory, poniżej zostawię zrzuty ekranu, myślę, że będzie to bardziej przejrzyste.

Federacja użytkowników —> Dodaj dostawcę… —> ldap

Konfiguracja federacji

Jeśli wszystko jest w porządku, to po naciśnięciu przycisku Synchronizuj wszystkich użytkowników zobaczysz komunikat o pomyślnym imporcie użytkowników.

Następnie musimy zmapować nasze grupy

Federacja użytkowników --> ldap_localhost --> Mappers --> Utwórz

Tworzenie mapera

Konfiguracja klienta

Konieczne jest stworzenie klienta, jeśli chodzi o Keycloak, jest to aplikacja, która będzie od niego autoryzowana. Zaznaczę na czerwono ważne punkty na zrzucie ekranu.

Klienci —> Utwórz

Konfiguracja klienta

Stwórzmy scoupe dla grup:

Zakresy klienta —> Utwórz

Utwórz zakres

I skonfiguruj dla nich narzędzie do mapowania:

Zakresy klientów —> grupy —> Mappery —> Utwórz

Odwzorowujący

Dodaj mapowanie naszych grup do domyślnych zakresów klienta:

Klienci —> kubernetes —> Zakresy klienta —> Domyślne zakresy klienta
wybierać grupy в Dostępne zakresy klienta, naciskać Dodaj zaznaczone

Otrzymujemy sekret (i wpisujemy go do wątku), którego użyjemy do autoryzacji w Keycloak:

Klienci —> kubernetes —> Poświadczenia —> Tajne
To kończy konfigurację, ale wystąpił błąd, gdy po udanej autoryzacji otrzymałem błąd 403. Zgłoszenie błędu.

Naprawić:

Zakresy klientów —> role —> Mappery —> Utwórz

Twórca map

Kod skryptu

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

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

Konfigurowanie Kubernetesa

Musimy określić, gdzie znajduje się nasz certyfikat główny z witryny i gdzie znajduje się dostawca OIDC.
W tym celu edytuj plik /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
...

Zaktualizuj konfigurację kubeadm w klastrze:

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

Ustawianie uwierzytelniającego proxy

Możesz użyć keycloak gatekeeper do ochrony swojej aplikacji internetowej. Oprócz tego, że ten odwrotny proxy dokona autoryzacji użytkownika przed wyświetleniem strony, przekaże również informacje o Tobie do aplikacji końcowej w nagłówkach. Tak więc, jeśli Twoja aplikacja obsługuje OpenID, to użytkownik jest natychmiast autoryzowany. Rozważ przykład pulpitu nawigacyjnego Kubernetes

Instalowanie pulpitu nawigacyjnego Kubernetes


helm install stable/kubernetes-dashboard --name dashboard -f values_dashboard.yaml

wartości_dashboard.yaml

enableInsecureLogin: true
service:
  externalPort: 80
rbac:
  clusterAdminRole: true
  create: true
serviceAccount:
  create: true
  name: 'dashboard-test'

Ustawianie praw dostępu:

Utwórzmy powiązanie ClusterRoleBinding, które zapewni uprawnienia administratora klastra (standardowy administrator klastra ClusterRole) dla użytkowników w grupie 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

Zainstaluj strażnika klucza:


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

wartości_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"

Po tym, kiedy spróbujesz iść do kubernetes-dashboard.example.org, zostaniemy przekierowani do Keycloak iw przypadku udanej autoryzacji przejdziemy do Pulpitu już zalogowanego.

montaż przejścia

Dla wygody można dodać trap, który wygeneruje plik konfiguracyjny dla kubectl, za pomocą którego dostaniemy się do Kubernetes pod naszym użytkownikiem.


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

wartości_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-----

Wygląda tak. Umożliwia natychmiastowe pobranie pliku konfiguracyjnego i wygenerowanie go za pomocą zestawu poleceń:

Źródło: www.habr.com

Przypinamy autoryzację ActiveDirectory do Kubernetes za pomocą Keycloak