ActiveDirectory-authenticatie aan Kubernetes koppelen met behulp van Keycloak

Dit artikel is geschreven met als doel het uitbreiden van de reeds bestaande, maar bespreekt de kenmerken van de integratie met Microsoft ActiveDirectory, en voegt daar ook extra informatie aan toe.

In dit artikel leg ik uit hoe je kunt installeren en configureren:

• Keycloak is een project met open source-code. Het biedt een enkele inlogpunt voor applicaties. Het werkt met verschillende protocollen, waaronder LDAP en OpenID die voor ons van belang zijn.
• Keycloak gatekeeper is een reverse proxy-applicatie die autorisatie via Keycloak mogelijk maakt.
• Gangway is een applicatie die een configuratie voor kubectl genereert waarmee je via OpenID kunt authenticeren en verbinding kunt maken met de Kubernetes API.

Hoe rechten werken in Kubernetes.

We kunnen gebruikersrechten/groepen beheren met RBAC, waarover al veel artikelen zijn geschreven; ik zal hier niet uitgebreid op ingaan. Het probleem is dat hoewel je met RBAC de rechten van een gebruiker kunt beperken, Kubernetes niets weet van gebruikers. Dit betekent dat er een mechanisme nodig is om een gebruiker naar Kubernetes te brengen. Hiervoor voegen we een OpenID-provider aan Kubernetes toe, die bevestigt dat zo'n gebruiker inderdaad bestaat, en Kubernetes zal zelf de rechten toekennen.

Voorbereiding

• Je hebt een Kubernetes-cluster of minikube nodig
• Active Directory
• Domeinen:
  keycloak.example.org
  kubernetes-dashboard.example.org
  gangway.example.org
• Certificaat voor de domeinen of een zelfondertekend certificaat

Ik zal niet in detail ingaan op het maken van een zelfondertekend certificaat; je moet 2 certificaten maken: een root (certificeringscentrum) en een wildcard-cliëntcertificaat voor het domein *.example.org

Nadat je de certificaten hebt ontvangen/uitgeschreven, moet je het cliëntcertificaat in Kubernetes toevoegen. Hiervoor maken we een secret aan:

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

Vervolgens zullen we deze gebruiken voor onze Ingress-controller

Installatie van Keycloak

Ik heb besloten dat het het eenvoudigst is om kant-en-klare oplossingen te gebruiken, namelijk helm-charts.

We voegen de repository toe en verversen deze:

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

We creëren het bestand keycloak.yml met de volgende inhoud:

keycloak.yml

keycloak:
  # Beheerdersnaam
  username: "test_admin"
  # Beheerderswachtwoord  
  password: "admin"
  # Deze vlaggen zijn nodig om het uploaden van scripts rechtstreeks via de webinterface naar Keycloak toe te staan. Dit hebben we nodig om een fout te verhelpen waarover hieronder meer.
  extraArgs: "-Dkeycloak.profile.feature.script=enabled -Dkeycloak.profile.feature.upload_scripts=enabled" 
  # We schakelen ingress in, geven de hostnaam op en het certificaat dat we vooraf in de geheimen hebben opgeslagen
  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 heeft een database nodig voor zijn werking; voor testdoeleinden draai ik Postgresql direct in Kubernetes, dit is niet aanbevolen voor productieomgevingen!
  persistence:
    deployPostgres: true
    dbVendor: postgres

postgresql:
  postgresUser: keycloak
  postgresPassword: ""
  postgresDatabase: keycloak
  persistence:
    enabled: true

Federatie-instellingen

Vervolgens gaan we naar de webinterface keycloak.example.org

In de linkerhoek klikken we op Voeg rijk toe

Key
Waarde

Naam
kubernetes

Weergavenaam
Kubernetes

We schakelen de bevestiging van gebruikers-e-mail uit:
Client scopes —> Email —> Mappers —> E-mailadres bevestigd (Verwijderen)

We configureren de federatie voor het importeren van gebruikers uit ActiveDirectory, hieronder laat ik screenshots zien zodat het duidelijker is.

Gebruikersfederatie —> Voeg aanbieder toe… —> ldap

Federatie-instellingen


Als alles goed gaat, zien we na het klikken op de knop Synchroniseer alle gebruikers een bericht over succesvolle gebruikersimport verschijnen.

Daarna moeten we onze groepen mappen

Gebruikersfederatie —> ldap_localhost —> Mappers —> Maak aan

Mapper aanmaken

Configuratie van de cliënt

We moeten een client aanmaken, in de termen van Keycloak is dit de applicatie die geauthenticeerd zal worden. Belangrijke punten zal ik in de screenshot rood markeren.

Clients —> Maak aan

Configuratie van de cliënt

Laten we een scope voor groepen aanmaken:

Client Scopes —> Maak aan

Scope aanmaken

En we configureren een mapper voor hen:

Client Scopes —> groepen —> Mappers —> Maak aan

Mapper

We voegen de mapping van onze groepen toe aan de Default Client Scopes:

Clients —> kubernetes —> Client Scopes —> Default Client Scopes
We kiezen groepen in Beschikbare Client Scopes, we drukken op Voeg geselecteerde toe

We krijgen een secret (en schrijven het ergens op) dat we gaan gebruiken voor authenticatie in Keycloak:

Clients —> kubernetes —> Credentials —> Secret
Dit is het einde van de configuratie, maar ik kreeg een foutmelding toen ik na een succesvolle authenticatie een fout 403 ontving. Bugrapport.

Fix:

Client Scopes —> rollen —> Mappers —> Maak aan

Mapper

Scriptcode

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

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

Kubernetes-instellingen

We moeten opgeven waar ons root-certificaat van de site zich bevindt, en waar de OIDC-provider zich bevindt.
Hiervoor bewerken we het bestand \/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
...

We werken de kubeadm-configuratie in de cluster bij:

kubeadm-configuratie

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

Configuratie van auth-proxy

Voor het beveiligen van uw webapplicatie kunt u Keycloak Gatekeeper gebruiken. Deze reverse proxy autoriseert de gebruiker voordat de pagina wordt weergegeven en verzendt informatie over u in de headers naar de eindtoepassing. Als uw applicatie OpenID ondersteunt, wordt de gebruiker direct geautoriseerd. Laten we het als voorbeeld bij het Kubernetes Dashboard bekijken.

Kubernetes Dashboard installeren

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'

Configuratie van toegangsrechten:

We creëren een ClusterRoleBinding die admin rechten aan de cluster (standaard ClusterRole cluster-admin) geeft voor gebruikers die lid zijn van de DataOPS-groep.

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

Keycloak Gatekeeper installeren:

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

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

Daarna, wanneer we proberen toegang te krijgen tot kubernetes-dashboard.example.org, wordt er doorgestuurd naar Keycloak en na succesvolle autorisatie komen we al ingelogd op het Dashboard.

Gangway installeren

Voor het gemak kunnen we Gangway toevoegen, dat een config-bestand voor kubectl genereert, waarmee we als onze gebruiker toegang krijgen tot Kubernetes.

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

values_gangway.yaml

gangway:
  # Arbitrair cluster naam
  clusterName: "my-k8s"
  # Waar we onze OIDC-provider hebben
  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"
  # Theoretisch kunnen we hier de groepen toevoegen die we gemapt hebben
  scopes: ["openid", "profile", "email", "offline_access"]
  redirectURL: "https://gangway.example.org/callback"
  # Clientnaam
  clientID: "kubernetes"
  # Geheim
  clientSecret: "c6ec03b8-d0b8-4cb6-97a0-03becba1d727"
  # Als je de standaardwaarde laat, wordt de gebruikersnaam genomen <b>Voornaam</b> <b>Achternaam</b>, en bij "sub" zijn login
  usernameClaim: "sub"
  # Domeinnaam of IP-adres van de API-server
  apiServerURL: "https://192.168.99.111:8443"

# Ingress inschakelen
  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

# Als we een zelfondertekend certificaat gebruiken, moet dit (de openbare rootcertificaat) worden opgegeven.
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-----

Het ziet er ongeveer zo uit. Hiermee kunt u zowel het config-bestand direct downloaden als het vormen via een reeks opdrachten:

Bron: habr.com