ProHoster > Log > administrasjon > Vi fester LDAP-autorisasjon til Kubernetes

Vi fester LDAP-autorisasjon til Kubernetes

Vi fester LDAP-autorisasjon til Kubernetes

En liten opplæring om hvordan du bruker Keycloak til å koble Kubernetes til LDAP-serveren din og sette opp import av brukere og grupper. Dette vil tillate deg å sette opp RBAC for brukerne dine og bruke auth-proxy for å beskytte Kubernetes Dashboard og andre applikasjoner som ikke vet hvordan de skal autorisere seg selv.

Keycloak installasjon

La oss anta at du allerede har en LDAP-server. Det kan være Active Directory, FreeIPA, OpenLDAP eller hva som helst. Hvis du ikke har en LDAP-server, så kan du i prinsippet opprette brukere direkte i Keycloak-grensesnittet, eller bruke offentlige oidc-leverandører (Google, Github, Gitlab), resultatet blir nesten det samme.

Først av alt, la oss installere Keycloak selv, installasjonen kan utføres separat, eller direkte til Kubernetes-klyngen, som regel, hvis du har flere Kubernetes-klynger, ville det være lettere å installere det separat. På den annen side kan du alltids bruke offisielle rordiagram og installer den direkte i klyngen din.

For å lagre Keycloak-data trenger du en database. Standard er h2 (alle data lagres lokalt), men det er også mulig å bruke postgres, mysql eller mariadb.
Hvis du likevel bestemmer deg for å installere Keycloak separat, kan du finne mer detaljerte instruksjoner i offisiell dokumentasjon.

Forbundsoppsett

Først av alt, la oss skape et nytt rike. Realm er plassen for applikasjonen vår. Hver applikasjon kan ha sin egen verden med forskjellige brukere og autorisasjonsinnstillinger. Mesterriket brukes av Keycloak selv, og å bruke det til noe annet er feil.

Klikk her Legg til rike

Alternativ
Verdi

Navn
kubernetes

Visningsnavn
Kubernetes

HTML-visningsnavn
<img src="https://kubernetes.io/images/nav_logo.svg" width="400" >

Kubernetes sjekker som standard om brukerens e-post er bekreftet eller ikke. Siden vi bruker vår egen LDAP-server, vil denne sjekken nesten alltid komme tilbake false. La oss deaktivere representasjonen av denne innstillingen i Kubernetes:

Klientomfang -> Epost -> Kartleggere -> e-post bekreftet (Slett)

La oss nå sette opp føderasjonen, for dette går vi til:

Brukerforbund -> Legg til leverandør... -> ldap

Her er et eksempeloppsett for FreeIPA:

Alternativ
Verdi

Visningsnavn for konsoll
freeipa.example.org

Leverandør
Red Hat Directory Server

UUID LDAP-attributt
ipauniqueid

Tilkoblings-URL
ldaps://freeipa.example.org

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

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

Bind legitimasjon
<password>

Tillat Kerberos-autentisering:
on

Kerberos Realm:
EXAMPLE.ORG

Server rektor:
HTTP/[email protected]

nøkkelfane:
/etc/krb5.keytab

bruker keycloak-svc må opprettes på forhånd på vår LDAP-server.

Når det gjelder Active Directory, trenger du bare å velge Leverandør: Active Directory og de nødvendige innstillingene vil automatisk legges inn i skjemaet.

Klikk her Spar

La oss nå gå videre:

Brukerforbund -> freeipa.example.org -> Kartleggere -> Fornavn

Alternativ
Verdi

Ldap-attributter
givenName

La oss nå aktivere gruppekartlegging:

Brukerforbund -> freeipa.example.org -> Kartleggere -> Opprett

Alternativ
Verdi

Navn
groups

Mapper type
group-ldap-mapper

LDAP-grupper DN
cn=groups,cn=accounts,dc=example,dc=org

Hent strategi for brukergrupper
GET_GROUPS_FROM_USER_MEMBEROF_ATTRIBUTE

Dette fullfører føderasjonsoppsettet, la oss gå videre til å sette opp klienten.

Klientoppsett

La oss lage en ny klient (en applikasjon som vil motta brukere fra Keycloak). La oss gå:

Klenter -> Opprett

Alternativ
Verdi

kunde-ID
kubernetes

Tilgangstype
confidenrial

Rot-URL
http://kubernetes.example.org/

Gyldige omdirigerings-URIer
http://kubernetes.example.org/*

Administrator-URL
http://kubernetes.example.org/

Vi vil også lage et omfang for grupper:

Klientomfang -> Opprett

Alternativ
Verdi

Mal
No template

Navn
groups

Full gruppevei
false

Og sett opp en kartlegger for dem:

Klientomfang -> grupper -> Kartleggere -> Opprett

Alternativ
Verdi

Navn
groups

Mapper Type
Group membership

Navn på tokenkrav
groups

Nå må vi aktivere gruppekartlegging i vårt kundeomfang:

Klenter -> Kubernetes -> Klientomfang -> Standard klientomfang

Velg grupper в Tilgjengelige klientomfang, trykk Legg til valgte

La oss nå sette opp autentiseringen av applikasjonen vår, gå til:

Klenter -> Kubernetes

Alternativ
Verdi

Autorisasjon aktivert
ON

La oss trykke redde og dette fullfører klientoppsettet, nå på fanen

Klenter -> Kubernetes -> Credentials

du kan få Secret som vi skal bruke videre.

Konfigurere Kubernetes

Å sette opp Kubernetes for OIDC-autorisasjon er ganske trivielt og ikke veldig komplisert. Alt du trenger å gjøre er å legge inn CA-sertifikatet til OIDC-serveren din /etc/kubernetes/pki/oidc-ca.pem og legg til de nødvendige alternativene for kube-apiserver.
For å gjøre dette, oppdater /etc/kubernetes/manifests/kube-apiserver.yaml på alle dine herrer:

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

Og oppdater også kubeadm-konfigurasjonen i klyngen for ikke å miste disse innstillingene under oppdateringen:

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

Dette fullfører Kubernetes-oppsettet. Du kan gjenta disse trinnene på tvers av alle Kubernetes-klyngene dine.

Innledende autorisasjon

Etter disse trinnene vil du allerede ha en Kubernetes-klynge med OIDC-autorisasjon konfigurert. Det eneste poenget er at brukerne dine ennå ikke har en klient konfigurert, så vel som sin egen kubeconfig. For å løse dette problemet må du konfigurere den automatiske utstedelsen av kubeconfig til brukere etter vellykket godkjenning.

For å gjøre dette kan du bruke spesielle nettapplikasjoner som lar deg autentisere brukeren og deretter laste ned den ferdige kubeconfig. En av de mest praktiske er Kuberos, lar den deg beskrive alle Kubernetes-klynger i én konfigurasjon og enkelt bytte mellom dem.

For å konfigurere Kuberos er det nok å beskrive malen for kubeconfig og kjøre den med følgende parametere:

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

For flere detaljer se bruk på Github.

Det er også mulig å bruke kubelogin hvis du ønsker å autorisere direkte på brukerens datamaskin. I dette tilfellet vil brukeren åpne en nettleser med et autorisasjonsskjema på localhost.

Den resulterende kubeconfig kan sjekkes på nettstedet jwt.io. Bare kopier verdien users[].user.auth-provider.config.id-token fra kubeconfig til skjemaet på nettsiden og motta umiddelbart en utskrift.

RBAC oppsett

Når du konfigurerer RBAC, kan du referere til både brukernavnet (felt name i jwt-tokenet) og for en gruppe brukere (felt groups i jwt-token). Her er et eksempel på å angi tillatelser for en gruppe 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

Flere eksempler for RBAC finner du i offisiell Kubernetes-dokumentasjon

Innstilling av auth-proxy

Det er et fantastisk prosjekt keycloak-portvakt, som lar deg sikre enhver applikasjon ved å la brukeren autentisere seg til OIDC-serveren. Jeg skal vise deg hvordan du kan sette opp det ved å bruke Kubernetes Dashboard som et eksempel:

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

Kilde: www.habr.com

Legg til en kommentar