🥇Integrujemy autoryzację LDAP z Kubernetes

Mała instrukcja, jak za pomocą Keycloak połączyć Kubernetes z Twoim serwerem LDAP oraz skonfigurować import użytkowników i grup. Pozwoli to na skonfigurowanie RBAC dla Twoich użytkowników i użycie auth-proxy do zabezpieczenia Kubernetes Dashboard oraz innych aplikacji, które nie potrafią same przeprowadzać autoryzacji.

Instalacja Keycloak

Zakładamy, że masz już serwer LDAP. Może to być Active Directory, FreeIPA, OpenLDAP lub coś innego. Jeśli nie masz serwera LDAP, 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ątku zainstalujemy sam Keycloak; instalacja może przebiegać osobno lub od razu w klastrze Kubernetes. Zazwyczaj, jeśli posiadasz kilka klastrów Kubernetes, łatwiej byłoby zainstalować go osobno. Z drugiej strony, zawsze możesz użyć oficjalnego szablonu helm i zainstalować go bezpośrednio w swoim klastrze.

Aby przechowywać dane Keycloak, potrzebujesz bazy danych. Domyślnie wykorzystywana jest h2 (wszystkie dane są przechowywane lokalnie), ale możesz również użyć postgres, mysql lub mariadb.
Jeśli jednak zdecydujesz się zainstalować Keycloak osobno, bardziej szczegółowe instrukcje znajdziesz w oficjalnej dokumentacji.

Konfigurowanie federacji

Na początku stwórzmy nowy realm. Realm to przestrzeń naszej aplikacji. Każda aplikacja może mieć swój realm z różnymi użytkownikami i ustawieniami autoryzacji. Realm główny jest używany przez sam Keycloak i nie powinno się go używać do innych celów.

Klikamy Dodaj realm

Opcja
@Value

Nazwa
kubernetes

Nazwa wyświetlana
Kubernetes

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

Kubernetes domyślnie sprawdza, czy użytkownik potwierdził swój email. Ponieważ używamy własnego serwera LDAP, ta weryfikacja prawie zawsze zwróci false. Wyłączmy wyświetlanie tego parametru w Kubernetes:

Zakresy klientów —> Email —> Mapery —> Email zweryfikowany (Usuń)

Teraz skonfigurujemy federację, przejdźmy do:

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

Podam przykład konfiguracji dla FreeIPA:

Opcja
@Value

Nazwa wyświetlana w konsoli
freeipa.example.org

Dostawca
Red Hat Directory Server

Atrybut UUID LDAP
ipauniqueid

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

DN użytkowników
cn=użytkownicy,cn=accounts,dc=example,dc=org

Bind DN
uid=keycloak-svc,cn=użytkownicy,cn=accounts,dc=example,dc=org

Bind Credential
<password>

Zezwól na uwierzytelnienie Kerberos:
włączony

Realm Kerberos:
EXAMPLE.ORG

Principal serwera:
HTTP/freeipa.example.org@EXAMPLE.ORG

KeyTab:
/etc/krb5.keytab

Użytkownik keycloak-svc musi być wcześniej utworzony na naszym serwerze LDAP.

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

Klikamy Zapisz

Teraz przejdźmy do:

Federacja użytkowników —> freeipa.example.org —> Mapery —> Imię

Opcja
@Value

Atrybut Ldap
givenName

Teraz włączymy mapowanie grup:

Federacja użytkowników —> freeipa.example.org —> Mapery —> Utwórz

Opcja
@Value

Nazwa
groups

Typ mappera
group-ldap-mapper

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

Strategia pobierania grup użytkowników
GET_GROUPS_FROM_USER_MEMBEROF_ATTRIBUTE

Na tym konfiguracja federacji jest zakończona, przechodzimy do ustawienia klienta.

Konfiguracja klienta

Utworzymy nowego klienta (aplikacja, która będzie pobierać użytkowników z Keycloak). Przechodzimy do:

Klienci —> Utwórz

Opcja
@Value

ID klienta
kubernetes

Typ dostępu
confidenrial

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

Poprawne adresy URL przekierowania
http://kubernetes.example.org/*

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

Utworzymy także zakres dla grup:

Zakresy klienta —> Utwórz

Opcja
@Value

Szablon
Brak szablonu

Nazwa
groups

Pełna ścieżka grupy
false

I skonfigurujemy mapper dla nich:

Zakresy klienta —> groups —> Mapery —> Utwórz

Opcja
@Value

Nazwa
groups

Typ mappera
Członkostwo grupowe

Nazwa roszczenia tokena
groups

Teraz musimy włączyć mapowanie grup w naszym zakresie klienta:

Klienci —> kubernetes —> Zakresy klienta —> Domyślne zakresy klienta

Wybieramy groups do Dostępne zakresy klienta, klikamy Dodaj wybrane

Teraz skonfigurujemy autoryzację naszej aplikacji, przechodzimy do:

Klienci —> kubernetes

Opcja
@Value

Autoryzacja włączona
WŁĄCZONE

Klikamy zapisz i na tym ustawienie klienta zostało zakończone, teraz na zakładce

Klienci —> kubernetes —> Poświadczenia

będziecie mogli uzyskać Secret który będziemy używać w przyszłości.

Konfiguracja Kubernetes

Konfiguracja Kubernetes dla autoryzacji OIDC jest wystarczająco prosta i nie jest zbyt skomplikowana. Wszystko, co musisz zrobić, to umieścić certyfikat CA swojego serwera OIDC w /etc/kubernetes/pki/oidc-ca.pem i dodać niezbędne opcje do kube-apiserver.
W tym celu zaktualizuj /etc/kubernetes/manifests/kube-apiserver.yaml na wszystkich swoich węzłach master:

...
spec:
  kontenery:
  - komenda:
    - 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 również 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
...

Na tym konfiguracja Kubernetes jest zakończona. Możesz powtórzyć te same działania we wszystkich swoich klastrach Kubernetes.

Wstępna autoryzacja

Po tych działaniach będziesz mieć klaster Kubernetes z skonfigurowaną autoryzacją OIDC. Jedyną kwestią jest to, że twoi użytkownicy na razie nie mają skonfigurowanego klienta ani własnego kubeconfig. Aby rozwiązać ten problem, musisz skonfigurować automatyczne wydawanie kubeconfig użytkownikom po pomyślnej autoryzacji.

Możesz do tego użyć specjalnych aplikacji webowych, które umożliwiają przeprowadzenie autoryzacji użytkownika, a następnie pobranie gotowego kubeconfigu. Jedna z najdogodniejszych to Kuberos, umożliwia opisanie wszystkich klastrów Kubernetes w jednej konfiguracji i łatwe przełączanie się między nimi.

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

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

Aby uzyskać bardziej szczegółowe informacje, zobacz Usage na Githubie.

Można również użyć kubelogin , jeśli chcesz przeprowadzić autoryzację bezpośrednio na komputerze użytkownika. W takim przypadku przeglądarka użytkownika otworzy stronę z formularzem autoryzacji na localhost.

Otrzymany kubeconfig można sprawdzić na stronie jwt.io. Wystarczy skopiować wartość users[].user.auth-provider.config.id-token z twojego kubeconfig do formularza na stronie, aby natychmiast uzyskać rozszyfrowanie.

Konfiguracja RBAC

Podczas konfigurowania RBAC można odnosić się zarówno do nazwy użytkownika (pola name w tokenie jwt), jak i do grupy użytkowników (pola groups w tokenie jwt). Oto przykład konfiguracji 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 dla RBAC można znaleźć w oficjalnej dokumentacji Kubernetes

Konfiguracja auth-proxy

Istnieje wspaniały projekt keycloak-gatekeeper, który pozwala zabezpieczyć dowolną aplikację, dając użytkownikowi możliwość uwierzytelnienia na serwerze OIDC. Pokażę, jak można go 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=
        - --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: habr.com