Configure o serviço de identidade do GKE com LDAP

Este documento destina-se a administradores de clusters ou operadores de aplicações que configuram o serviço de identidade do GKE nos respetivos clusters. Indica-lhe como configurar o GKE Identity Service nos seus clusters com o seu fornecedor do Lightweight Directory Access Protocol (LDAP) preferido, incluindo o Microsoft Active Directory. Parte do princípio de que já tem os detalhes de início de sessão do seu fornecedor de LDAP ou o administrador da plataforma, seguindo as instruções em Configure um fornecedor de LDAP para o serviço de identidade do GKE. Para saber mais sobre o funcionamento do serviço de identidade do GKE e outras opções de configuração, consulte a vista geral. Para saber como aceder a um cluster através deste serviço como programador ou outro utilizador do cluster, consulte o artigo Aceda a clusters com o GKE Identity Service. O GKE Identity Service com LDAP pode ser usado com implementações do Google Distributed Cloud no VMware (clusters de utilizadores) e no bare metal apenas.

Antes de começar

1. Certifique-se de que tem as seguintes ferramentas de linha de comandos instaladas:
   • A versão mais recente da CLI do Google Cloud, que inclui o gcloud, a ferramenta de linha de comandos para interagir com o Google Cloud. Se precisar de instalar a CLI do Google Cloud, consulte o guia de instalação.
   • kubectl para executar comandos em clusters do Kubernetes. Se precisar de instalar o kubectl, consulte o guia de instalação. Se estiver a usar o Cloud Shell como ambiente de shell para interagir com o Google Cloud, estas ferramentas são instaladas automaticamente.
2. Certifique-se de que inicializou a CLI gcloud para utilização com o seu projeto.

Ao longo desta configuração, pode ter de consultar a documentação do seu servidor LDAP. Os seguintes guias do administrador explicam a configuração de alguns fornecedores de LDAP populares, incluindo onde encontrar as informações necessárias para iniciar sessão no servidor LDAP e configurar os seus clusters:

• OpenLDAP
• Azure AD
• Microsoft Active Directory
• LDAP da Google

Preencha o segredo da conta de serviço LDAP

O GKE Identity Service precisa de um segredo da conta de serviço para autenticar no servidor LDAP e obter detalhes do utilizador. Existem dois tipos de contas de serviço permitidas na autenticação LDAP: autenticação básica (através de um nome de utilizador e uma palavra-passe para autenticação no servidor) ou certificado de cliente (através de uma chave privada do cliente e um certificado de cliente). Você ou o administrador da plataforma devem ter estas informações sobre o fornecedor seguindo o artigo Configure um fornecedor LDAP para o GKE Identity Service. Para disponibilizar as informações de início de sessão do servidor LDAP ao GKE Identity Service, tem de criar um recurso Kubernetes Secret com os detalhes de início de sessão de Configurar um fornecedor LDAP para o GKE Identity Service. Os exemplos seguintes mostram como configurar segredos para ambos os tipos de contas de serviço. Os exemplos mostram o segredo a ser aplicado ao espaço de nomes anthos-identity-service.

Segue-se um exemplo de uma configuração de segredo de autenticação básica:

apiVersion: v1
kind: Secret
metadata:
  name: SERVICE_ACCOUNT_SECRET_NAME
  namespace: "anthos-identity-service"
type: kubernetes.io/basic-auth     # Make sure the type is correct
data:
  username: USERNAME  # Use a base64-encoded username
  password: PASSWORD  # Use a base64-encoded password

onde, SERVICE_ACCOUNT_SECRET_NAME é o nome que escolheu para este Secret. Substitua os valores do nome de utilizador e da palavra-passe pelo nome de utilizador e pela palavra-passe que obteve no passo anterior. USERNAME é um nome de utilizador codificado em base64 PASSWORD é uma palavra-passe codificada em base64

Segue-se um exemplo de uma configuração de segredo do certificado de cliente:

apiVersion: v1
kind: Secret
metadata:
  name: SERVICE_ACCOUNT_SECRET_NAME
  namespace: anthos-identity-service
type: kubernetes.io/tls            # Make sure the type is correct
data:
  # the data is abbreviated in this example
  tls.crt: |
       MIIC2DCCAcCgAwIBAgIBATANBgkqh ...
  tls.key: |
       MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ...

Substitua SERVICE_ACCOUNT_SECRET_NAME pelo nome que escolheu para este Secret. Substitua os valores da chave e do certificado TLS pelos valores da chave e do certificado codificados que obteve no passo anterior.

Os exemplos mostram o segredo a ser aplicado ao espaço de nomes anthos-identity-service, que é a nossa abordagem recomendada. Isto deve-se ao facto de, por predefinição, o GKE Identity Service ter autorização para ler segredos em anthos-identity-service. Se quiser usar outro espaço de nomes, altere os metadados no segredo e, em seguida, adicione uma nova política de RBAC para conceder autorização ao serviço de identidade do GKE para ler segredos nesse espaço de nomes, da seguinte forma:

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: NAMESPACE
  name: ais-secret-reader-role
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get","list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ais-secret-reader-role-binding
  namespace: NAMESPACE
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: ais-secret-reader-role
subjects:
- kind: ServiceAccount
  name: default
  namespace: anthos-identity-service
---

Configure o cluster

O GKE Identity Service usa um tipo de recurso personalizado especial do Kubernetes (CRD) para configurar os seus clusters denominado ClientConfig, com campos para informações sobre o fornecedor de identidade e os parâmetros de que precisa para devolver informações do utilizador. A configuração ClientConfig também inclui o nome e o espaço de nomes do Secret que criou e aplicou na secção anterior, o que permite ao GKE Identity Service autenticar-se no servidor LDAP.

Para aplicar a configuração ao cluster, edite o objeto predefinido do KRM do tipo clientconfig no espaço de nomes kube-public:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-public edit clientconfig default

Substitua USER_CLUSTER_KUBECONFIG pelo caminho para o ficheiro kubeconfig do cluster. Se existirem vários contextos no kubeconfig, é usado o contexto atual. Pode ter de repor o contexto atual para o cluster correto antes de executar o comando.

O exemplo seguinte mostra o formato da configuração ClientConfig:

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
  name: default
  namespace: kube-public
spec:
  authentication:
    - name: NAME_STRING
      ldap:
        host: HOST_NAME
        certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA
        connectionType: CONNECTION_TYPE
        serviceAccountSecret:
          name: SERVICE_ACCOUNT_SECRET_NAME
          namespace: NAMESPACE
          type: SECRET_FORMAT
        user:
          baseDN: BASE_DN
          filter: FILTER
          identifierAttribute: IDENTIFIER_ATTRIBUTE
          loginAttribute: LOGIN_ATTRIBUTE
        group:
          baseDN: BASE_DN
          filter: FILTER
          identifierAttribute: IDENTIFIER_ATTRIBUTE

Sugestão: o GKE Identity Service permite-lhe configurar várias configurações de fornecedores de identidade OIDC, LDAP e SAML num único ClientConfig recurso personalizado (CRD) para autenticação de clientes. O serviço de identidade do GKE tenta a autenticação com cada CRD na ordem em que são definidos e para após a primeira autenticação bem-sucedida.

Pode configurar vários fornecedores de identidade no seu ClientConfig de acordo com os seus requisitos. Isto simplifica a gestão e oferece flexibilidade, permitindo-lhe configurar vários métodos de autenticação num recurso de configuração unificado. O exemplo seguinte ClientConfig define vários fornecedores de identidade na ordem necessária de precedência da autenticação.

  apiVersion: v1
  items:
  - apiVersion: authentication.gke.io/v2alpha1
    kind: ClientConfig
  ...
    spec:
      authentication:
      - aws:
          region: us-west-2
        name: AWS Login
      - ldap:
      ...
      - saml:
        ...
      - azureAD:
        ...
      - oidc:
        name: Okta OIDC
        ...
      -oidc:
        name: Google OIDC
        ...

A tabela seguinte descreve os campos no ClientConfig CRD:

Campo	Obrigatória	Descrição	Formato
nome	sim	Um nome para identificar esta configuração LDAP	de string
anfitrião	sim	Nome do anfitrião ou endereço IP do servidor LDAP. A porta é opcional e a predefinição é 389, se não for especificada. Por exemplo, ldap.server.example.com ou 10.10.10.10:389.	de string
certificateAuthorityData	Obrigatório para determinados tipos de ligação LDAP	Contém um certificado da autoridade de certificação em formato PEM codificado em Base64 para o servidor LDAP. Tem de ser fornecido apenas para ligações ldaps e startTLS.	de string
connectionType	sim	Tipo de ligação LDAP a usar quando se liga ao servidor LDAP. A predefinição é startTLS. O modo insecure só deve ser usado para desenvolvimento, uma vez que toda a comunicação com o servidor é feita em texto simples.	de string
serviceAccountSecret
nome	sim	Nome do segredo do Kubernetes que armazena as credenciais da conta de serviço LDAP.	de string
espaço de nome	sim	Espaço de nomes do segredo do Kubernetes que armazena as credenciais da conta de serviço LDAP.	de string
escrever	sim	Define o formato do segredo da conta de serviço para suportar diferentes tipos de segredos. Se especificou basic-auth na configuração do segredo, deve ser basic. Caso contrário, deve ser tls. Se não for especificado, o fuso horário predefinido é basic.	de string
utilizador
baseDN	sim	A localização da subárvore no diretório LDAP para pesquisar entradas de utilizadores.	de string
filtrar	não	Filtro opcional a aplicar quando pesquisa o utilizador. Isto pode ser usado para restringir ainda mais as contas de utilizador autorizadas a iniciar sessão. Se não for especificado, o fuso horário predefinido é (objectClass=User).	de string
identifierAttribute	não	Determina que atributo usar como identidade do utilizador após a autenticação. Isto é diferente do campo loginAttribute para permitir que os utilizadores iniciem sessão com um nome de utilizador, mas que o respetivo identificador real seja um endereço de email ou um nome distinto (DN) completo. Por exemplo, definir loginAttribute como sAMAccountName e identifierAttribute como userPrincipalName permitiria que um utilizador iniciasse sessão como bsmith, mas as políticas de RBAC reais para o utilizador seriam escritas como [e-mail]. Recomendamos a utilização de userPrincipalName, uma vez que este valor é exclusivo para cada utilizador. Se não for especificado, a predefinição é userPrincipalName.	de string
loginAttribute	não	O nome do atributo que corresponde ao nome de utilizador introduzido. É usado para encontrar o utilizador na base de dados LDAP, por exemplo, (<LoginAttribute>=<username>), e é combinado com o campo de filtro opcional. A predefinição é userPrincipalName.	de string
group (Campo opcional)
baseDN	sim	A localização da subárvore no diretório LDAP para pesquisar entradas de grupos.	de string
filtrar	não	Filtro opcional a usar quando pesquisar grupos aos quais um utilizador pertence. Isto pode ser usado para fazer a correspondência explícita apenas de determinados grupos, de modo a reduzir a quantidade de grupos devolvidos para cada utilizador. A predefinição é (objectClass=Group).	de string
identifierAttribute	não	O nome de identificação de cada grupo ao qual um utilizador pertence. Por exemplo, se esta opção estiver definida como distinguishedName, os RBACs e outras expetativas de grupos devem ser escritos como DNs completos. Se não for especificado, a predefinição é distinguishedName.	de string

O que se segue?

Depois de aplicar a configuração, continue a configurar o acesso dos utilizadores aos clusters com o GKE Identity Service.