ProHoster > Blog > administração > Fixamos a autorização LDAP ao Kubernetes

Fixamos a autorização LDAP ao Kubernetes

Fixamos a autorização LDAP ao Kubernetes

Um breve tutorial sobre como você pode usar o Keycloak para conectar o Kubernetes ao seu servidor LDAP e configurar a importação de usuários e grupos. Isso permitirá que você configure o RBAC para seus usuários e use o auth-proxy para proteger o Kubernetes Dashboard e outros aplicativos que não conseguem se autenticar.

Instalação do Keycloak

Vamos supor que você já tenha um servidor LDAP. Pode ser Active Directory, FreeIPA, OpenLDAP ou qualquer outra coisa. Se você não possui um servidor LDAP, então, em princípio, você pode criar usuários diretamente na interface do Keycloak ou usar provedores OIDC públicos (Google, Github, Gitlab), o resultado será quase o mesmo.

Em primeiro lugar, vamos instalar o próprio Keycloak. A instalação pode ser realizada separadamente ou diretamente em um cluster Kubernetes. Via de regra, se você tiver vários clusters Kubernetes, será mais fácil instalá-los separadamente. Por outro lado, você sempre pode usar gráfico oficial do leme e instale-o diretamente em seu cluster.

Para armazenar dados do Keycloak você precisará de um banco de dados. O padrão é h2 (todos os dados são armazenados localmente), mas também é possível usar postgres, mysql ou mariadb.
Se você ainda decidir instalar o Keycloak separadamente, você encontrará instruções mais detalhadas em documentação oficial.

Configuração da federação

Primeiro de tudo, vamos criar um novo reino. Realm é o espaço da nossa aplicação. Cada aplicativo pode ter seu próprio domínio com diferentes usuários e configurações de autorização. O reino Master é usado pelo próprio Keycloak e é errado usá-lo para qualquer outra coisa.

Clique aqui Adicionar reino

Opção
Valor

Nome
kubernetes

Nome visível
Kubernetes

Nome de exibição HTML
<img src="https://kubernetes.io/images/nav_logo.svg" width="400" >

Por padrão, o Kubernetes verifica se o e-mail do usuário está confirmado ou não. Como usamos nosso próprio servidor LDAP, essa verificação quase sempre retornará false. Vamos desabilitar a representação desta opção no Kubernetes:

Escopos do cliente -> E-mail -> Mapeadores -> Email verificado (Excluir)

Agora vamos configurar a federação; para fazer isso, acesse:

Federação de usuários -> Adicionar provedor… -> ldap

Aqui está um exemplo de configurações para FreeIPA:

Opção
Valor

Nome de exibição do console
freeipa.example.org

Vendedor
Red Hat Directory Server

Atributo UUID LDAP
ipauniqueid

URL de conexão
ldaps://freeipa.example.org

DN de usuários
cn=users,cn=accounts,dc=example,dc=org

DN da ligação
uid=keycloak-svc,cn=users,cn=accounts,dc=example,dc=org

Vincular credencial
<password>

Permitir autenticação Kerberos:
on

Reino Kerberos:
EXAMPLE.ORG

Principal do servidor:
HTTP/[email protected]

Guia Chave:
/etc/krb5.keytab

Usuário keycloak-svc precisa ser criado antecipadamente em nosso servidor LDAP.

No caso do Active Directory, você só precisa selecionar Fornecedor: Active Directory e as configurações necessárias serão inseridas no formulário automaticamente.

Clique aqui Salvar

Agora vamos em frente:

Federação de usuários -> freeipa.exemplo.org -> Mapeadores -> Nome

Opção
Valor

Atributo Ldap
givenName

Agora vamos habilitar o mapeamento de grupo:

Federação de usuários -> freeipa.exemplo.org -> Mapeadores -> Crie

Opção
Valor

Nome
groups

Tipo de mapeador
group-ldap-mapper

DN de grupos LDAP
cn=groups,cn=accounts,dc=example,dc=org

Estratégia de recuperação de grupos de usuários
GET_GROUPS_FROM_USER_MEMBEROF_ATTRIBUTE

Agora que a configuração da federação foi concluída, vamos prosseguir com a configuração do cliente.

Configuração do cliente

Vamos criar um novo cliente (uma aplicação que receberá usuários do Keycloak). Vamos continuar:

Clientes -> Crie

Opção
Valor

ID do cliente
kubernetes

Tipo de acesso
confidenrial

URL raiz
http://kubernetes.example.org/

URIs de redirecionamento válidos
http://kubernetes.example.org/*

URL do administrador
http://kubernetes.example.org/

Vamos também criar um escopo para grupos:

Escopos do cliente -> Crie

Opção
Valor

Modelo
No template

Nome
groups

Caminho completo do grupo
false

E configure um mapeador para eles:

Escopos do cliente -> grupos -> Mapeadores -> Crie

Opção
Valor

Nome
groups

Tipo de mapeador
Group membership

Nome da reivindicação de token
groups

Agora precisamos habilitar o grupo de mapeamento em nosso escopo de cliente:

Clientes -> kubernetes -> Escopos do cliente -> Escopos de cliente padrão

selecionar grupos в Escopos de cliente disponíveisempurrar Adicionar selecionado

Agora vamos configurar a autenticação da nossa aplicação, acesse:

Clientes -> kubernetes

Opção
Valor

Autorização habilitada
ON

Vamos pressionar salvar e com isso a configuração do cliente está concluída, agora na aba

Clientes -> kubernetes -> Credenciais

você pode ter Segredo que usaremos mais adiante.

Configurando o Kubernetes

Configurar o Kubernetes para autorização OIDC é bastante trivial e não muito complicado. Tudo que você precisa fazer é colocar o certificado CA do seu servidor OIDC em /etc/kubernetes/pki/oidc-ca.pem e adicione as opções necessárias para kube-apiserver.
Para fazer isso, atualize /etc/kubernetes/manifests/kube-apiserver.yaml em todos os seus mestres:

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

Além disso, atualize a configuração do kubeadm no cluster para não perder essas configurações durante a atualização:

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

Isso conclui a configuração do Kubernetes. Você pode repetir essas etapas em todos os clusters do Kubernetes.

Autorização inicial

Após essas etapas, você já terá um cluster Kubernetes com autorização OIDC configurada. A única coisa é que seus usuários ainda não possuem um cliente configurado ou seu próprio kubeconfig. Para resolver este problema, você precisa configurar a distribuição automática do kubeconfig aos usuários após autorização bem-sucedida.

Para fazer isso, você pode usar aplicativos da web especiais que permitem autenticar o usuário e depois baixar o kubeconfig pronto. Um dos mais convenientes é Kuberos, permite descrever todos os clusters Kubernetes em uma configuração e alternar facilmente entre eles.

Para configurar o Kuberos, basta descrever o template do kubeconfig e executá-lo com os seguintes parâmetros:

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

Para informações mais detalhadas consulte Uso no Github.

Também é possível usar Kubelogin se você deseja autorizar diretamente no computador do usuário. Neste caso, o usuário abrirá um navegador com um formulário de autorização no localhost.

O kubeconfig resultante pode ser verificado no site jwt.io. Basta copiar o valor users[].user.auth-provider.config.id-token do seu kubeconfig para o formulário no site e receba imediatamente uma transcrição.

Configurando o RBAC

Ao configurar o RBAC, você pode consultar o nome de usuário (campo name no token jwt) e por grupo de usuários (campo groups no token jwt). Aqui está um exemplo de configuração de direitos para um grupo 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

Mais exemplos de RBAC podem ser encontrados em documentação oficial do Kubernetes

Configurando o proxy de autenticação

Existe um projeto maravilhoso keycloak-gatekeeper, que permite proteger qualquer aplicativo, fornecendo ao usuário a capacidade de autenticação no servidor OIDC. Vou mostrar como configurá-lo usando o Kubernetes Dashboard como exemplo:

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

Fonte: habr.com

Adicionar um comentário