ProHoster > Blog > administracja > Przypinamy autoryzację LDAP do Kubernetes

Przypinamy autoryzację LDAP do Kubernetes

Przypinamy autoryzację LDAP do Kubernetes

Krótki samouczek na temat wykorzystania Keycloak do połączenia Kubernetes z serwerem LDAP i skonfigurowania importu użytkowników i grup. Umożliwi to skonfigurowanie kontroli RBAC dla użytkowników i użycie uwierzytelniania proxy do ochrony Kubernetes Dashboard i innych aplikacji, które nie mogą się samodzielnie uwierzytelnić.

Instalacja klucza

Załóżmy, że masz już serwer LDAP. Może to być Active Directory, FreeIPA, OpenLDAP lub cokolwiek innego. Jeśli nie masz serwera LDAP, to w zasadzie możesz tworzyć użytkowników bezpośrednio w interfejsie Keycloak lub korzystać z publicznych dostawców oidc (Google, Github, Gitlab), wynik będzie prawie taki sam.

Na początek zainstalujmy sam Keycloak, instalację można przeprowadzić osobno lub bezpośrednio do klastra Kubernetes, z reguły jeśli mamy kilka klastrów Kubernetes, łatwiej byłoby zainstalować go osobno. Z drugiej strony zawsze możesz skorzystać oficjalny wykres steru i zainstaluj go bezpośrednio w klastrze.

Aby przechowywać dane Keycloak, będziesz potrzebować bazy danych. Wartość domyślna to h2 (wszystkie dane są przechowywane lokalnie), ale można je również wykorzystać postgres, mysql lub mariadb.
Jeśli nadal zdecydujesz się zainstalować Keycloak osobno, bardziej szczegółowe instrukcje znajdziesz w oficjalna dokumentacja.

Konfiguracja federacji

Przede wszystkim stwórzmy nową krainę. Dziedzina to przestrzeń naszej aplikacji. Każda aplikacja może mieć własną dziedzinę z różnymi użytkownikami i ustawieniami autoryzacji. Królestwo Master jest używane przez samego Keycloaka i niewłaściwe jest używanie go do czegokolwiek innego.

Kliknij Dodaj dziedzinę

Option
wartość

Imię
kubernetes

Wyświetlana nazwa
Kubernetes

Nazwa wyświetlana HTML
<img src="https://kubernetes.io/images/nav_logo.svg" width="400" >

Kubernetes domyślnie sprawdza, czy adres e-mail użytkownika został potwierdzony, czy nie. Ponieważ korzystamy z własnego serwera LDAP, to sprawdzenie prawie zawsze będzie zwracane false. Wyłączmy reprezentację tego ustawienia w Kubernetes:

Zakresy klienta -> E-mail -> Twórcy map -> e-mail zweryfikowany (Kasować)

Teraz załóżmy federację, w tym celu przechodzimy do:

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

Oto przykładowa konfiguracja dla FreeIPA:

Option
wartość

Nazwa wyświetlana konsoli
freeipa.example.org

Sprzedawca
Red Hat Directory Server

Atrybut UUID LDAP
ipauniqueid

Adres URL połączenia
ldaps://freeipa.example.org

Nazwa wyróżniająca użytkownika
cn=users,cn=accounts,dc=example,dc=org

Wiązanie DN
uid=keycloak-svc,cn=users,cn=accounts,dc=example,dc=org

Powiąż poświadczenie
<password>

Zezwalaj na uwierzytelnianie Kerberos:
on

Królestwo Kerberos:
EXAMPLE.ORG

Główny serwer:
HTTP/[email protected]

zakładka kluczowa:
/etc/krb5.keytab

Użytkownicy keycloak-svc należy wcześniej utworzyć na naszym serwerze LDAP.

W przypadku Active Directory wystarczy wybrać Dostawca: Active Directory a niezbędne ustawienia zostaną automatycznie wstawione do formularza.

Kliknij Zapisz

Teraz przejdźmy dalej:

Federacja użytkowników -> freeipa.example.org -> Twórcy map -> Imię

Option
wartość

Atrybuty Ldapa
givenName

Teraz włącz mapowanie grupowe:

Federacja użytkowników -> freeipa.example.org -> Twórcy map -> Stwórz

Option
wartość

Imię
groups

Typ mapera
group-ldap-mapper

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

Strategia odzyskiwania grupy użytkowników
GET_GROUPS_FROM_USER_MEMBEROF_ATTRIBUTE

To kończy konfigurację federacji, przejdźmy do konfiguracji klienta.

Konfiguracja klienta

Stwórzmy nowego klienta (aplikację, która będzie przyjmować użytkowników z Keycloak). Chodźmy:

Klienci -> Stwórz

Option
wartość

identyfikator klienta
kubernetes

Typ dostępu
confidenrial

Główny adres URL
http://kubernetes.example.org/

Prawidłowe identyfikatory URI przekierowania
http://kubernetes.example.org/*

Adres URL administratora
http://kubernetes.example.org/

Stworzymy również zakres dla grup:

Zakresy klienta -> Stwórz

Option
wartość

szablon
No template

Imię
groups

Pełna ścieżka grupowa
false

I skonfiguruj dla nich narzędzie do mapowania:

Zakresy klienta -> grupy -> Twórcy map -> Stwórz

Option
wartość

Imię
groups

Typ mapera
Group membership

Nazwa żądania tokenu
groups

Teraz musimy włączyć mapowanie grupowe w zakresie naszego klienta:

Klienci -> Kubernetes -> Zakresy klienta -> Domyślne zakresy klienta

wybierać grupy в Dostępne zakresy klienta, naciskać Dodaj zaznaczone

Teraz skonfigurujmy uwierzytelnianie naszej aplikacji, przejdźmy do:

Klienci -> Kubernetes

Option
wartość

Autoryzacja włączona
ON

Pchnijmy zapisać i to kończy konfigurację klienta, teraz na karcie

Klienci -> Kubernetes -> Listy uwierzytelniające

możesz dostać Tajemnica z którego skorzystamy później.

Konfigurowanie Kubernetesa

Konfiguracja Kubernetesa do autoryzacji OIDC jest dość banalna i niezbyt skomplikowana. Wszystko, co musisz zrobić, to umieścić certyfikat CA swojego serwera OIDC /etc/kubernetes/pki/oidc-ca.pem i dodaj niezbędne opcje dla kube-apiserver.
Aby to zrobić, zaktualizuj /etc/kubernetes/manifests/kube-apiserver.yaml na wszystkich twoich panach:

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

Zaktualizuj także konfigurację kubeadm w klastrze, aby nie stracić tych ustawień podczas aktualizacji:

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

To kończy konfigurację Kubernetes. Możesz powtórzyć te kroki we wszystkich klastrach Kubernetes.

Wstępna autoryzacja

Po wykonaniu tych kroków będziesz mieć już skonfigurowany klaster Kubernetes ze skonfigurowaną autoryzacją OIDC. Problem w tym, że Twoi użytkownicy nie mają jeszcze skonfigurowanego klienta ani własnego kubeconfig. Aby rozwiązać ten problem, musisz skonfigurować automatyczne wydawanie kubeconfig użytkownikom po pomyślnej autoryzacji.

Można w tym celu skorzystać ze specjalnych aplikacji webowych, które pozwalają na uwierzytelnienie użytkownika, a następnie pobranie gotowego kubeconfig. Jednym z najwygodniejszych jest Kuberospozwala opisać wszystkie klastry Kubernetes w jednej konfiguracji i łatwo przełączać się między nimi.

Aby skonfigurować Kuberos, wystarczy opisać szablon kubeconfig i uruchomić go z następującymi parametrami:

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

Więcej szczegółów znajdziesz Stosowanie na Github.

Można również skorzystać kubelogin jeśli chcesz dokonać autoryzacji bezpośrednio na komputerze użytkownika. W takim przypadku użytkownik otworzy przeglądarkę z formularzem autoryzacji na localhost.

Wynikowy kubeconfig można sprawdzić na stronie jwt.io. Po prostu skopiuj wartość users[].user.auth-provider.config.id-token z kubeconfig do formularza na stronie i od razu uzyskaj transkrypcję.

Konfiguracja RBAC

Konfigurując RBAC, możesz odwołać się zarówno do nazwy użytkownika (pole name w tokenie jwt) i dla grupy użytkowników (pole groups w tokenie jwt). Oto przykład ustawienia uprawnień dla grupy 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

Więcej przykładów RBAC można znaleźć w oficjalna dokumentacja Kubernetesa

Ustawianie uwierzytelniającego proxy

Jest wspaniały projekt klucznik-strażnik, co pozwala zabezpieczyć dowolną aplikację poprzez umożliwienie użytkownikowi uwierzytelnienia się na serwerze OIDC. Pokażę Ci, jak możesz to skonfigurować na przykładzie 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=<your-client-secret-here>
        - --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

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

Dodaj komentarz