🥇Vi fastgør ActiveDirectory-autorisation til Kubernetes ved hjælp af Keycloak

Denne artikel er skrevet for at udvide det allerede eksisterende, men taler om funktionerne i bundtet med Microsoft ActiveDirectory og supplerer det også.

I denne artikel vil jeg fortælle dig, hvordan du installerer og konfigurerer:

Nøglekappe er et open source-projekt. Hvilket giver et enkelt indgangspunkt for ansøgninger. Arbejder med mange protokoller, herunder LDAP og OpenID, som vi er interesserede i.
nøglekappe gatekeeper - Reverse proxy-applikation, der giver dig mulighed for at integrere autorisation gennem Keycloak.
Gangway - et program, der genererer en konfiguration for kubectl, som du kan logge på og oprette forbindelse til Kubernetes API med via OpenID.

Sådan fungerer tilladelser i Kubernetes.

Vi kan administrere bruger-/grupperettigheder ved hjælp af RBAC, en masse artikler er allerede blevet oprettet om dette, jeg vil ikke dvæle ved dette i detaljer. Problemet er, at du kan bruge RBAC til at begrænse brugerrettigheder, men Kubernetes ved ikke noget om brugere. Det viser sig, at vi har brug for en brugerleveringsmekanisme i Kubernetes. For at gøre dette vil vi tilføje en udbyder til Kuberntes OpenID, som vil sige, at sådan en bruger virkelig eksisterer, og Kubernetes selv vil give ham rettighederne.

Træning

Du skal bruge en Kubernetes-klynge eller minikube
Active Directory
Domæner:
keycloak.example.org
kubernetes-dashboard.example.org
gangway.example.org
Certifikat for domæner eller selvsigneret certifikat

Jeg vil ikke dvæle ved, hvordan man opretter et selvsigneret certifikat, du skal oprette 2 certifikater, dette er roden (Certificate Authority) og wildcard-klienten for *.example.org-domænet

Efter du har modtaget/udstedt certifikater, skal klienten føjes til Kubernetes, til dette opretter vi en hemmelighed for den:

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

Dernæst vil vi bruge det til vores Ingress-controller.

Keycloak installation

Jeg besluttede mig for, at den nemmeste måde er at bruge færdige løsninger til dette, nemlig ror charts.

Installer depotet og opdater det:

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

Opret en keycloak.yml-fil med følgende indhold:

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

Federation opsætning

Gå derefter til webgrænsefladen keycloak.example.org

Klik i venstre hjørne Tilføj rige

Nøgle
Værdi

Navn
guvernør

Visningsnavn
Kubernetes

Deaktiver bruger-e-mailbekræftelse:
Klientomfang —> E-mail —> Kortlæggere —> E-mail bekræftet (Slet)

Vi oprettede en føderation til at importere brugere fra ActiveDirectory, jeg vil efterlade skærmbilleder nedenfor, jeg tror, det vil være klarere.

Brugerføderation —> Tilføj udbyder... —> ldap

Federation opsætning

Hvis alt er godt, så efter at have trykket på knappen Synkroniser alle brugere du vil se en meddelelse om vellykket import af brugere.

Dernæst skal vi kortlægge vores grupper

Brugerføderation --> ldap_localhost --> Kortlæggere --> Opret

Oprettelse af en kortlægger

Klient opsætning

Det er nødvendigt at oprette en klient, med hensyn til Keycloak, dette er en applikation, der vil blive godkendt fra ham. Jeg vil fremhæve de vigtige punkter i skærmbilledet med rødt.

Kunder —> Opret

Klient opsætning

Lad os skabe scoupe for grupper:

Klientomfang —> Opret

Skab omfang

Og opsæt en mapper til dem:

Klientomfang —> grupper —> Kortlæggere —> Opret

Mapper

Tilføj kortlægningen af vores grupper til Standard Client Scopes:

Clients —> kubernetes —> Client Scopes —> Standard Client Scopes
Vælg grupper в Tilgængelige klientomfang, tryk på Tilføj valgte

Vi får hemmeligheden (og skriver den til tråden), som vi vil bruge til godkendelse i Keycloak:

Klienter —> kubernetes —> Oplysninger —> Hemmelighed
Dette fuldfører opsætningen, men jeg havde en fejl, da jeg efter vellykket godkendelse modtog en fejl 403. Fejlrapport.

Rette op:

Klientomfang —> roller —> Kortlæggere —> Opret

Mapper

Script kode

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

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

Konfiguration af Kubernetes

Vi skal specificere, hvor vores rodcertifikat fra webstedet ligger, og hvor OIDC-udbyderen er placeret.
For at gøre dette skal du redigere 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
...

Opdater kubeadm-konfigurationen 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
...

Indstilling af auth-proxy

Du kan bruge keycloak gatekeeper til at beskytte din webapplikation. Ud over det faktum, at denne omvendte proxy vil autorisere brugeren, før den viser siden, vil den også videregive oplysninger om dig til slutapplikationen i overskrifterne. Så hvis din applikation understøtter OpenID, er brugeren straks autoriseret. Overvej eksemplet med Kubernetes Dashboard

Installation af Kubernetes Dashboard


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

værdier_dashboard.yaml

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

Indstilling af adgangsrettigheder:

Lad os oprette en ClusterRoleBinding, der giver cluster admin rettigheder (standard ClusterRole cluster-admin) for brugere 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

værdier_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"

Efter det, når du forsøger at gå til kubernetes-dashboard.example.org, vil vi blive omdirigeret til Keycloak, og i tilfælde af vellykket autorisation vil vi komme til Dashboardet, der allerede er logget ind.

gangbroinstallation

For nemheds skyld kan du tilføje en gangway, der genererer en konfigurationsfil til kubectl, ved hjælp af hvilken vi kommer ind i Kubernetes under vores bruger.


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 sådan ud. Giver dig mulighed for straks at downloade konfigurationsfilen og generere den ved hjælp af et sæt kommandoer:

Kilde: www.habr.com

Vi fastgør ActiveDirectory-autorisation til Kubernetes ved hjælp af Keycloak