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. O serviço de identidade do GKE com LDAP só pode ser usado com implantações do Google Distributed Cloud no VMware (clusters de usuários) e em bare metal.

Antes de começar

  1. 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 o kubectl, consulte o guia de instalação. Se você estiver usando o Cloud Shell como seu ambiente shell para interagir com o Google Cloud, essas ferramentas estarão instaladas para você.
  2. Verifique se você inicializou a 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 ...

Substitua SERVICE_ACCOUNT_SECRET_NAME pelo nome que você escolheu para o 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 GKE Identity Service usa um tipo de recurso personalizado (CRD, na sigla em inglês) especial do Kubernetes para configurar os clusters chamados ClientConfig, com campos para informações sobre o provedor de identidade e os parâmetros necessários para retornar as 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

Substitua USER_CLUSTER_KUBECONFIG pelo 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:

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

A tabela a seguir descreve os campos no CRD ClientConfig:

Campo Obrigatório Descrição Formato
name 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
name sim O nome do secret do Kubernetes que armazena as credenciais da conta de serviço LDAP. string
namespace sim 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
filtro 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
filtro 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.