Esta página foi traduzida pela API Cloud Translation.

Configurar o serviço de identidade do GKE com o LDAP

Este documento é destinado a administradores de cluster ou operadores de aplicativos que configuram o GKE Identity Service nos clusters deles. Ele informa como configurar o serviço de identidade do GKE nos clusters com o provedor de protocolo de acesso leve ao diretório (LDAP), incluindo o Microsoft Active Directory. Ele pressupõe que você ou o administrador da plataforma já recebeu os detalhes de login do seu provedor LDAP de acordo com as instruções em Configurar um provedor LDAP para o GKE Identity Service.

Para saber mais sobre como o GKE Identity Service funciona e outras opções de configuração, consulte a visão geral. Para saber como acessar um cluster usando esse serviço como um desenvolvedor ou outro usuário do cluster, consulte Acessar clusters com o GKE Identity Service.

No momento, o Serviço de identidade do GKE com LDAP pode ser usado apenas com o GKE on VMware (clusters de usuário) e o GKE em Bare Metal.

Antes de começar

Verifique se você tem as seguintes ferramentas de linha de comando instaladas:
- A versão mais recente da Google Cloud CLI, que inclui gcloud, a ferramenta de linha de comando para interagir com o Google Cloud. Se você precisar instalar a Google Cloud CLI, consulte o guia de instalação.
- kubectl para executar comandos em clusters do Kubernetes. Se precisar instalar kubectl, consulte o guia de instalação
Se você estiver usando o Cloud Shell como ambiente shell para interagir com o Google Cloud, essas ferramentas estarão instaladas.
Verifique se você inicializou a ferramenta CLI gcloud para usar com seu projeto.

Durante essa configuração, talvez seja necessário consultar a documentação do seu servidor LDAP. Os guias do administrador a seguir explicam a configuração de alguns provedores LDAP conhecidos, inclusive onde encontrar as informações necessárias para fazer login no servidor LDAP e configurar os clusters:

Preencher o secret da conta de serviço LDAP

O Serviço de identidade do GKE precisa de um secret da conta de serviço para se autenticar no servidor LDAP e recuperar os detalhes do usuário. Há dois tipos de contas de serviço permitidas na autenticação LDAP: autenticação básica (com um nome de usuário e senha para autenticação no servidor) ou certificado do cliente (chave privada do cliente e certificado do cliente). Você ou o administrador da plataforma precisam ter essas informações sobre seu provedor em Configurar um provedor LDAP para o GKE Identity Service.

Para disponibilizar as informações de login do servidor LDAP para o GKE Identity Service, você precisa criar um recurso secret do Kubernetes com os detalhes de login de Configurar um provedor LDAP para o GKE Identity Service. de dados.

Os exemplos a seguir mostram como configurar chaves secretas para os dois tipos de conta de serviço. Os exemplos mostram o secret sendo aplicado ao namespace anthos-identity-service.

Este é um exemplo de uma configuração de chave secreta 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

em que SERVICE_ACCOUNT_SECRET_NAME é o nome que você escolheu para este secret. Substitua os valores de nome de usuário e senha pelo nome de usuário e senha que você salvou na etapa anterior. USERNAME é um nome de usuário codificado em base64 PASSWORD é uma senha codificada em base64

Este é um exemplo de configuração de um secret de certificado do 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 ...

...em que SERVICE_ACCOUNT_SECRET_NAME é o nome que você escolheu para este secret. Substitua os valores de chave e certificado TLS pelos valores de chave e certificado codificados recebidos na etapa anterior.

Os exemplos mostram o secret que está sendo aplicado ao namespace anthos-identity-service, que é nossa abordagem recomendada. Isso ocorre porque, por padrão, o GKE Identity Service tem permissão para ler secrets no anthos-identity-service. Se você quiser usar outro namespace, altere os metadados no secret e adicione uma nova política do RBAC para conceder ao serviço de identidade do GKE a permissão para ler secrets nesse namespace, da seguinte maneira:

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

Configurar o cluster

O serviço de identidade do GKE usa um tipo de recurso personalizado (CRD, na sigla em inglês) especial do Kubernetes para configurar os clusters, chamado ClientConfig, com campos de informações sobre o provedor de identidade e os parâmetros necessários para retornar informações do usuário. A configuração do ClientConfig também inclui o nome e o namespace do secret que você criou e aplicou na seção anterior, permitindo que o GKE Identity Service se autentique no servidor LDAP.

Para aplicar a configuração ao cluster, edite o objeto padrão KRM do tipo clientconfig no namespace kube-public:

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

…em que USER_CLUSTER_KUBECONFIG é o caminho do arquivo kubeconfig do cluster. Se houver vários contextos no kubeconfig, o contexto atual será usado. Talvez seja necessário redefinir o contexto atual para o cluster correto antes de executar o comando.

Veja a seguir o formato da configuração ClientConfig:

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

A tabela a seguir descreve os campos no CRD ClientConfig:

Campo	Obrigatório	Descrição	Formato
Nome	sim	Um nome para identificar essa configuração LDAP	string
host	sim	Nome do host ou endereço IP do servidor LDAP. A porta é opcional e o padrão será 389, se não for especificada. Por exemplo, `ldap.server.example.com` ou `10.10.10.10:389`.	string
certificateAuthorityData	Obrigatório para determinados tipos de conexão LDAP	Contém um certificado de autoridade de certificação no formato PEM codificado em Base64 para o servidor LDAP. Isso precisa ser fornecido apenas para conexões `ldaps` e `startTLS`.	string
connectionType	sim	Tipo de conexão LDAP a ser usada na conexão com o servidor LDAP. O padrão é `startTLS`. O modo `insecure` só deve ser usado para desenvolvimento, já que toda a comunicação com o servidor será em texto simples.	string
serviceAccountSecret
Nome	sim	O nome do secret do Kubernetes que armazena as credenciais da conta de serviço LDAP.	string
namespace	yes	Namespace do secret do Kubernetes que armazena as credenciais da conta de serviço LDAP.	string
tipo	sim	Define o formato do secret da conta de serviço para aceitar diferentes tipos de secret. Se você especificou `basic-auth` na configuração do secret, use `basic`, caso contrário, use `tls`. Se não for especificado, o padrão será `basic`.	string
usuário
baseDN	sim	O local da subárvore no diretório LDAP para pesquisar entradas de usuário.	string
filter	não	Filtro opcional a ser aplicado ao pesquisar o usuário. Isso pode ser usado para restringir ainda mais as contas de usuário que têm permissão para fazer login. Se não for especificado, `(objectClass=User)` assumirá como padrão.	string
identifierAttribute	não	Determina qual atributo usar como identidade do usuário depois de ser autenticado. Ele é diferente do campo loginAttribute para permitir que os usuários façam login com um nome de usuário, mas tenham o identificador real como um endereço de e-mail ou Nome distinto (DN) completo. Por exemplo, definir "loginAttribute" como `sAMAccountName` e "AttributeAttribute" como `userPrincipalName` permitiria que um usuário fizesse login como `bsmith`, mas as políticas reais do RBAC para o usuário seriam gravadas como `bsmith@example.com`. É recomendável usar `userPrincipalName`, pois ele será exclusivo para cada usuário. Se não for especificado, o padrão será `userPrincipalName`.	string
loginAttribute	não	O nome do atributo que corresponde ao nome de usuário de entrada. Isso é usado para encontrar o usuário no banco de dados LDAP, por exemplo, `(<LoginAttribute>=<username>)` e é combinado com o campo de filtro opcional. O padrão é `userPrincipalName`.	string
grupo (campo opcional)
baseDN	sim	O local da subárvore no diretório LDAP para pesquisar as entradas do grupo.	string
filter	não	Filtro opcional a ser usado ao pesquisar grupos a que um usuário pertence. Isso pode ser usado para corresponder explicitamente apenas a determinados grupos de modo a reduzir a quantidade de grupos retornados para cada usuário. O padrão é `(objectClass=Group)`.	string
identifierAttribute	não	O nome de identificação de cada grupo a que um usuário pertence. Por exemplo, se isso for definido como `distinguishedName`, os RBACs e outras expectativas do grupo serão gravados como DNs completos. Se não for especificado, o padrão será `distinguishedName`.	string

A seguir

Depois que a configuração for aplicada, continue para definir o acesso do usuário a clusters com o GKE Identity Service.