Integrăm autentificarea LDAP în Kubernetes

O scurtă instrucțiune despre cum să folosiți Keycloak pentru a conecta Kubernetes cu serverul dvs. LDAP și a configura importul utilizatorilor și grupurilor. Acest lucru va permite configurarea RBAC pentru utilizatorii dvs. și utilizarea auth-proxy pentru a proteja Kubernetes Dashboard și alte aplicații care nu pot efectua autorizarea singure.

Instalarea Keycloak

Presupunem că aveți deja un server LDAP. Acesta poate fi Active Directory, FreeIPA, OpenLDAP sau altceva. Dacă nu aveți un server LDAP, puteți crea utilizatori direct în interfața Keycloak sau utiliza furnizori publici oidc (Google, Github, Gitlab); rezultatul va fi aproape același.

În primul rând, să instalăm Keycloak. Instalarea poate fi efectuată fie separat, fie direct în clusterul Kubernetes; de obicei, dacă aveți mai multe clustere Kubernetes, ar fi mai simplu să-l instalați separat. Pe de altă parte, puteți utiliza întotdeauna chartul oficial helm și să-l instalați direct în clusterul dvs.

Pentru stocarea datelor Keycloak, veți avea nevoie de o bază de date. Implicit, se folosește h2 (toate datele sunt stocate local), dar este posibil să folosiți de asemenea postgres, mysql sau mariadb.
Dacă ați decis să instalați Keycloak separat, veți găsi instrucțiuni mai detaliate în documentația oficială.

Configurarea federației

În primul rând, să creăm un nou realm. Realm-ul este spațiul aplicației noastre. Fiecare aplicație poate avea propriul său realm cu utilizatori și setări de autorizare diferite. Realm-ul Master este utilizat de Keycloak și nu ar trebui folosit pentru altceva.

Facem clic pe Adaugă domeniu

Opțiune
Value

Name
kubernetes

Numele afișat
Kubernetes

Numele de afişare HTML
<img src="https://kubernetes.io/images/nav_logo.svg" width="400" >

Kubernetes verifică din default dacă email-ul utilizatorului a fost confirmat sau nu. Deoarece folosim un server LDAP propriu, această verificare va returna aproape întotdeauna false. Să dezactivăm acest parametru în Kubernetes:

Sferă de clienți —> Email —> Mapperi —> Email verificat (Șterge)

Acum să configurăm federația, pentru aceasta mergem la:

Federația utilizatorului —> Adăugați furnizor… —> ldap

Voi da un exemplu de configurare pentru FreeIPA:

Opțiune
Value

Numele de afişare Console
freeipa.example.org

Furnizor
Red Hat Directory Server

Atribut LDAP UUID
ipauniqueid

URL de conexiune
ldaps://freeipa.example.org

DN Utilizatori
cn=users,cn=accounts,dc=example,dc=org

Bind DN
uid=keycloak-svc,cn=users,cn=accounts,dc=example,dc=org

Credential de conectare
<password>

Permite autentificarea Kerberos:
on

Realm Kerberos:
EXAMPLE.ORG

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

KeyTab:
/etc/krb5.keytab

Utilizatorul keycloak-svc trebuie creat anterior pe serverul nostru LDAP.

În cazul Active Directory, este suficient să alegi Furnizor: Active Directory iar setările necesare se vor completa automat în formular.

Facem clic pe Salvează

Acum mergem la:

Federația utilizatorului —> freeipa.example.org —> Mapperi —> First Name

Opțiune
Value

Atribut LDAP
givenName

Acum vom activa maparea grupurilor:

Federația utilizatorului —> freeipa.example.org —> Mapperi —> Creează

Opțiune
Value

Name
groups

Tipul mapper-ului
group-ldap-mapper

DN-uri de grup LDAP
cn=groups,cn=accounts,dc=example,dc=org

Strategia de recuperare a grupurilor utilizatorilor
GET_GROUPS_FROM_USER_MEMBEROF_ATTRIBUTE

Asta finalizează configurarea federației, acum vom trece la configurarea clientului.

Configurarea clientului

Vom crea un nou client (aplicația care va obține utilizatorii din Keycloak). Trecem la:

Clienți —> Creează

Opțiune
Value

ID-ul Clientului
kubernetes

Tip de acces
confidențial

URL rădăcină
http://kubernetes.example.org/

URI-uri de redirecționare valide
http://kubernetes.example.org/*

URL de administrare
http://kubernetes.example.org/

De asemenea, vom crea un scope pentru grupuri:

Scope-uri Client —> Creează

Opțiune
Value

Șablon
Fără șablon

Name
groups

Calea completă a grupului
false

Și să configurăm mapperul pentru ele:

Scope-uri Client —> groups —> Mapperi —> Creează

Opțiune
Value

Name
groups

Tipul Mapper-ului
Apartenența la grup

Numele revendicării token-ului
groups

Acum trebuie să activăm maparea grupurilor în scope-ul nostru de client:

Clienți —> kubernetes —> Scope-uri Client —> Scope-uri implicite de client

Alegem groups în Available Client Scopes, dăm clic pe Adaugă selecționate

Acum să configurăm autentificarea aplicației noastre, trecem la:

Clienți —> kubernetes

Opțiune
Value

Autorizare activată
DA

Vom apăsa salvează și astfel se finalizează configurarea clientului, acum pe tab-ul

Clienți —> kubernetes —> Credențiale

veți putea obține Secret pe care îl vom folosi mai departe.

Kubernetes Setup

Configurarea Kubernetes pentru autorizarea OIDC este destul de trivială și nu este ceva foarte complicat. Tot ce trebuie să faceți este să plasați certificatul CA al serverului OIDC în /etc/kubernetes/pki/oidc-ca.pem și să adăugați opțiunile necesare pentru kube-apiserver.
Pentru asta, actualizați /etc/kubernetes/manifests/kube-apiserver.yaml pe toate masterele dvs.:

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

Și, de asemenea, actualizați configurația kubeadm în cluster, pentru a nu pierde aceste setări la actualizare:

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

Asta finalizează configurarea Kubernetes. Puteți repeta aceste acțiuni în toate cluster-ele dvs. Kubernetes.

Autorizare inițială

După aceste acțiuni, veți avea deja un cluster Kubernetes cu autorizarea OIDC configurată. Singurul aspect este că utilizatorii dvs. nu au un client configurat sau propriul kubeconfig. Pentru a rezolva această problemă, trebuie să configurați emiterea automată a kubeconfig-ului utilizatorilor după autorizarea cu succes.

Pentru aceasta, puteți folosi aplicații web speciale, care permit autentificarea utilizatorului și apoi descărcarea kubeconfig-ului finalizat. Una dintre cele mai convenabile este Kuberos, care permite descrierea tuturor cluster-elor Kubernetes într-o singură configurație și comutarea ușoară între ele.

Pentru a configura Kuberos, este suficient să descrieți un șablon pentru kubeconfig și să rulați cu următoarele parametri:

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

Pentru informații mai detaliate, consultați Utilizare pe Github.

De asemenea, este posibil să utilizați kubelogin dacă doriți să efectuați autentificarea direct pe computerul utilizatorului. În acest caz, utilizatorului i se va deschide un browser cu un formular de autentificare pe localhost.

Kubeconfig-ul obținut poate fi verificat pe site-ul jwt.io. Pur și simplu copiați valoarea users[].user.auth-provider.config.id-token din kubeconfig-ul dumneavoastră în formularul de pe site și veți obține imediat decriptarea.

Configurarea RBAC

La configurarea RBAC, se poate face referire atât la numele utilizatorului (câmpul name din jwt-token), cât și la grupul de utilizatori (câmpul groups din jwt-token). Iată un exemplu de configurare a drepturilor pentru grupul 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

Mai multe exemple pentru RBAC pot fi găsite în documentației oficiale Kubernetes

Configurarea auth-proxy

Există un proiect excelent keycloak-gatekeeper, care permite să protejați orice aplicație, oferindu-le utilizatorilor posibilitatea să se autentifice pe serverul OIDC. Voi arăta cum se poate configura pe exemplul 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

Sursa: habr.com