Integrando a autenticação ActiveDirectory ao Kubernetes com o Keycloak

Este artigo foi escrito com o objetivo de expandir já existente, mas fala sobre as particularidades da integração especificamente com o Microsoft Active Directory, além de complementá-la.

Neste artigo, eu vou explicar como instalar e configurar:

• Keycloak — é um projeto de código aberto que proporciona um único ponto de entrada para aplicativos. Funciona com vários protocolos, incluindo LDAP e OpenID, que nos interessam.
• Keycloak gatekeeper — é um aplicativo de proxy reverso que permite integrar a autorização através do Keycloak.
• Gangway — é um aplicativo que gera a configuração para kubectl, com a qual você pode se autenticar via OpenID e se conectar à API do Kubernetes.

Como funcionam os direitos no Kubernetes.

Podemos gerenciar os direitos de usuários/grupos usando RBAC. Já existem muitos artigos sobre isso, então não vou me aprofundar nesse ponto. O problema é que, ao usar RBAC para restringir os direitos de um usuário, o Kubernetes não tem conhecimento dos usuários. Portanto, precisamos de um mecanismo para entregar o usuário ao Kubernetes. Para isso, adicionaremos um provedor OpenID ao Kubernetes, que informará que tal usuário realmente existe, e os direitos serão concedidos pelo próprio Kubernetes.

Preparação

• Você precisará de um cluster Kubernetes ou do minikube
• Active Directory
• Domínios:
  keycloak.example.org
  kubernetes-dashboard.example.org
  gangway.example.org
• Certificado para os domínios ou um certificado autoassinado

Não irei me aprofundar em como criar um certificado autoassinado, você precisará criar 2 certificados, um raiz (Centro de Certificação) e um wildcard para o domínio *.example.org

Depois que você obtiver/extrair os certificados, o cliente deve ser adicionado ao Kubernetes, para isso criamos um secret para ele:

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

Em seguida, vamos usá-lo para nosso controlador Ingress.

Instalação do Keycloak

Decidi que seria mais fácil usar soluções prontas para isso, especificamente charts do helm.

Adicionamos o repositório e o atualizamos:

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

Criamos o arquivo keycloak.yml com o seguinte conteúdo:

keycloak.yml

keycloak:
  # Nome do administrador
  username: "test_admin"
  # Senha do administrador
  password: "admin"
  # Essas flags são necessárias para permitir o upload de scripts para o Keycloak diretamente pela interface web. Isso será necessário para corrigir um bug mencionado abaixo.
  extraArgs: "-Dkeycloak.profile.feature.script=enabled -Dkeycloak.profile.feature.upload_scripts=enabled"
  # Ativamos o ingress, especificando o nome do host e o certificado que salvamos previamente nos segredos
  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 requer um banco de dados para funcionar, para fins de teste estou implantando o PostgreSQL diretamente no Kubernetes, em produção isso não é recomendado!
  persistence:
    deployPostgres: true
    dbVendor: postgres

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

Configuração da federação

Em seguida, acesse a interface web keycloak.example.org

No canto esquerdo, clique em Adicionar realm

Chave
Valor

Nome
kubernetes

Nome de exibição
Kubernetes

Desativar a verificação de confirmação do e-mail do usuário:
Client scopes —> Email —> Mappers —> Email verified (Excluir)

Configurando a federação para importar usuários do Active Directory, deixarei capturas de tela abaixo, acho que ficará mais claro.

User federation —> Adicionar provedor… —> ldap

Configuração da federação


Se tudo correr bem, após clicar no botão Sincronizar todos os usuários Você verá uma mensagem de importação bem-sucedida dos usuários.

Agora precisamos mapear nossos grupos

User federation —> ldap_localhost —> Mappers —> Criar

Criando mapper

Configuração do Cliente

É necessário criar um cliente, no contexto do Keycloak isso significa um aplicativo que irá se autenticar. Os pontos importantes estarão destacados na captura de tela em vermelho.

Clients —> Criar

Configuração do Cliente

Vamos criar um scope para grupos:

Client Scopes —> Criar

Criando scope

E vamos configurar o mapeador para eles:

Client Scopes —> groups —> Mappers —> Criar

Mapper

Adicionando o mapeamento de nossos grupos nos Default Client Scopes:

Clients —> kubernetes —> Client Scopes —> Default Client Scopes
Escolhendo grupos em Escopos de Cliente Disponíveis, clicamos em Adicionar selecionados

Obtemos um secret (e anotamos em algum lugar) que usaremos para autenticar no Keycloak:

Clients —> kubernetes —> Credentials —> Secret
A configuração está finalizada, mas encontrei um erro ao receber uma mensagem de erro 403 após a autenticação bem-sucedida. Relatório de bug.

Correção:

Client Scopes —> roles —> Mappers —> Criar

Mapper

Código do script

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

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

Configuração do Kubernetes

Precisamos indicar onde está nosso certificado raiz do site e onde se encontra o provedor OIDC.
Para isso, editamos o arquivo /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
...

Atualizando a configuração do kubeadm no cluster:

kubeadm config

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

Configuração do auth-proxy

Para proteger sua aplicação web, você pode usar o keycloak gatekeeper. Além de autorizar o usuário antes de exibir a página, ele também transmite informações sobre você para a aplicação final nos cabeçalhos. Assim, se sua aplicação suporta OpenID, o usuário será automaticamente autenticado. Vamos considerar o exemplo do Kubernetes Dashboard.

Instalação do 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'

Configuração de permissões:

Vamos criar um ClusterRoleBinding que concederá permissões de administrador do cluster (ClusterRole padrão cluster-admin) para usuários que estão no grupo DataOPS.

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

Instalação do 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

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"

Após isso, ao tentar acessar o kubernetes-dashboard.example.org, haverá um redirecionamento para o Keycloak e, em caso de autenticação bem-sucedida, chegaremos ao Dashboard já logado.

Instalação do gangway

Para maior conveniência, podemos adicionar o gangway que gerará um arquivo de configuração para kubectl, com o qual já poderemos acessar o Kubernetes com nosso usuário.

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

values_gangway.yaml

gangway:
  # Nome do cluster arbitrário
  clusterName: "my-k8s"
  # Onde está o provedor 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"
  # Teoricamente, podemos adicionar grupos que mapeamos aqui
  scopes: ["openid", "profile", "email", "offline_access"]
  redirectURL: "https://gangway.example.org/callback"
  # Nome do cliente
  clientID: "kubernetes"
  # Segredo
  clientSecret: "c6ec03b8-d0b8-4cb6-97a0-03becba1d727"
  # Se deixar o valor padrão, o nome de usuário será usado <b>Primeiro nome</b> <b>Segundo nome</b>, e no campo "sub" seu login
  usernameClaim: "sub"
  # Nome de domínio ou endereço IP do servidor API
  apiServerURL: "https://192.168.99.111:8443"

# Habilitando o 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

# Se usarmos um certificado autoassinado, seu (certificado raiz público) deve ser indicado.
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-----

Aparece mais ou menos assim. Permite tanto baixar o arquivo de configuração quanto formá-lo usando um conjunto de comandos:

Fonte: habr.com