🥇Vi fester ActiveDirectory-autorisasjonen til Kubernetes ved å bruke Keycloak

Denne artikkelen er skrevet for å utvide det allerede eksisterende, men snakker om funksjonene til pakken med Microsoft ActiveDirectory, og utfyller den også.

I denne artikkelen vil jeg fortelle deg hvordan du installerer og konfigurerer:

Nøkkelkappe er et åpen kildekode-prosjekt. Som gir ett enkelt inngangspunkt for søknader. Fungerer med mange protokoller, inkludert LDAP og OpenID som vi er interessert i.
keycloak portvakt - omvendt proxy-applikasjon som lar deg integrere autorisasjon gjennom Keycloak.
Gangway - en applikasjon som genererer en konfigurasjon for kubectl som du kan logge på og koble til Kubernetes API via OpenID.

Hvordan tillatelser fungerer i Kubernetes.

Vi kan administrere bruker-/grupperettigheter ved å bruke RBAC, det er allerede laget en haug med artikler om dette, jeg vil ikke dvele ved dette i detalj. Problemet er at du kan bruke RBAC til å begrense brukerrettigheter, men Kubernetes vet ikke noe om brukere. Det viser seg at vi trenger en brukerleveringsmekanisme i Kubernetes. For å gjøre dette vil vi legge til en leverandør til Kuberntes OpenID, som vil si at en slik bruker virkelig eksisterer, og Kubernetes selv vil gi ham rettighetene.

Trening

Du trenger en Kubernetes-klynge eller minikube
Active Directory
Domener:
keycloak.example.org
kubernetes-dashboard.example.org
gangway.example.org
Sertifikat for domener eller selvsignert sertifikat

Jeg vil ikke dvele ved hvordan du oppretter et selvsignert sertifikat, du må opprette 2 sertifikater, dette er roten (sertifikatmyndigheten) og jokertegnklienten for *.example.org-domenet

Etter at du har mottatt / utstedt sertifikater, må klienten legges til Kubernetes, for dette lager vi en hemmelighet for den:

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

Deretter vil vi bruke den for vår Ingress-kontroller.

Keycloak installasjon

Jeg bestemte meg for at den enkleste måten er å bruke ferdige løsninger for dette, nemlig rorkart.

Installer depotet og oppdater det:

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

Lag en keycloak.yml-fil med følgende innhold:

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

Forbundsoppsett

Gå deretter til nettgrensesnittet keycloak.example.org

Klikk i venstre hjørne Legg til rike

nøkkel
Verdi

Navn
Kubernetes

Visningsnavn
Kubernetes

Deaktiver brukerens e-postbekreftelse:
Klientomfang —> E-post —> Kartleggere —> E-post bekreftet (Slett)

Vi satte opp føderasjon for å importere brukere fra ActiveDirectory, jeg vil legge igjen skjermbilder nedenfor, jeg tror det blir klarere.

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

Forbundsoppsett

Hvis alt er bra, etter å ha trykket på knappen Synkroniser alle brukere du vil se en melding om vellykket import av brukere.

Deretter må vi kartlegge gruppene våre

Brukerføderasjon --> ldap_localhost --> Kartleggere --> Opprett

Opprette en kartlegger

Klientoppsett

Det er nødvendig å opprette en klient, når det gjelder Keycloak, dette er en applikasjon som vil bli autorisert fra ham. Jeg vil fremheve de viktige punktene i skjermbildet i rødt.

Klienter —> Opprett

Klientoppsett

La oss lage scoupe for grupper:

Klientomfang —> Opprett

Skap omfang

Og sett opp en kartlegger for dem:

Klientomfang —> grupper —> Kartleggere —> Opprett

Kartlegger

Legg til kartleggingen av gruppene våre til Standard Client Scopes:

Clients —> kubernetes —> Client Scopes —> Standard Client Scopes
Velg grupper в Tilgjengelige klientomfang, trykk Legg til valgte

Vi får hemmeligheten (og skriver den til tråden) som vi vil bruke for autorisasjon i Keycloak:

Klienter —> kubernetes —> Legitimasjon —> Hemmelig
Dette fullfører oppsettet, men jeg fikk en feil da jeg, etter vellykket godkjenning, fikk feil 403. Feilrapport.

Fastsette:

Klientomfang —> roller —> Kartleggere —> Opprett

Kartlegger

Skriptkode

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

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

Konfigurere Kubernetes

Vi må spesifisere hvor rotsertifikatet vårt fra nettstedet ligger, og hvor OIDC-leverandøren befinner seg.
For å gjøre dette, rediger filen /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
...

Oppdater kubeadm-konfigurasjonen i klyngen:

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

Innstilling av auth-proxy

Du kan bruke keycloak gatekeeper for å beskytte webapplikasjonen din. I tillegg til at denne omvendte proxyen vil autorisere brukeren før siden vises, vil den også sende informasjon om deg til sluttapplikasjonen i overskriftene. Derfor, hvis applikasjonen din støtter OpenID, blir brukeren umiddelbart autorisert. Tenk på eksemplet med Kubernetes Dashboard

Installere Kubernetes Dashboard


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

values_dashboard.yaml

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

Angi tilgangsrettigheter:

La oss lage en ClusterRoleBinding som vil gi cluster admin rettigheter (standard ClusterRole cluster-admin) for brukere i DataOPS-gruppen.


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

Installer keycloak gatekeeper:


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

verdier_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"

Etter det, når du prøver å gå til kubernetes-dashboard.example.org, vil vi bli omdirigert til Keycloak, og i tilfelle vellykket autorisasjon vil vi komme til dashbordet som allerede er pålogget.

gangbroinstallasjon

For enkelhets skyld kan du legge til en landgang som vil generere en konfigurasjonsfil for kubectl, ved hjelp av denne kommer vi inn i Kubernetes under brukeren vår.


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

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

Ser slik ut. Lar deg umiddelbart laste ned konfigurasjonsfilen og generere den ved hjelp av et sett med kommandoer:

Kilde: www.habr.com

Vi fester ActiveDirectory-autorisasjon til Kubernetes ved hjelp av Keycloak