Esta página foi traduzida pela API Cloud Translation.

Configurar clusters membros da frota para autenticação LDAP

Este documento descreve como administradores de cluster ou operadores de aplicativos podem configurar clusters do Kubernetes para oferecer suporte à autenticação de um provedor Lightweight Directory Access Protocol (LDAP) de terceiros, como o Microsoft Entra ID ou o Google LDAP. Para mais informações, consulte Sobre a autenticação usando identidades de terceiros.

Limitações

Use um tipo de cluster compatível com LDAP.

Antes de começar

Install the Google Cloud CLI.
Ao usar um provedor de identidade (IdP) externo, primeiro faça login na gcloud CLI com sua identidade federada.
Para inicializar a gcloud CLI, execute o seguinte comando:
```
gcloud init
```
Depois que a gcloud CLI é inicializada, ela precisa ser atualizada e os componentes necessários instalados:
```
gcloud components update
gcloud components install kubectl
```
Verifique se o administrador da plataforma forneceu todas as informações necessárias do provedor. Para mais informações, consulte Configurar provedores LDAP para autenticar em clusters.

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

Seu cluster precisa de um secret da conta de serviço para se autenticar no servidor LDAP e recuperar os detalhes do usuário. A autenticação LDAP é compatível com os seguintes mecanismos:

Autenticação básica, em que você usa um nome de usuário e uma senha.
Autenticação de certificado do cliente, em que você usa uma chave privada e um certificado do cliente.

Você ou o administrador da plataforma precisam ter essas informações sobre seu provedor em Configurar provedores LDAP para autenticar em clusters. Para disponibilizar as informações de login do servidor LDAP para o cluster, crie um secret do Kubernetes com os detalhes de login do LDAP. Os exemplos a seguir mostram como configurar chaves secretas para os dois tipos de autenticação. Os exemplos mostram o secret sendo aplicado ao namespace anthos-identity-service.

Este é um exemplo de 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 sendo aplicado ao namespace anthos-identity-service. Por padrão, os componentes do sistema têm permissão para ler secrets nesse namespace. Para usar outro namespace, mude os metadados no secret e adicione uma nova política de RBAC para conceder à ServiceAccount default no namespace anthos-identity-service 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

Para configurar a autenticação em um cluster usando LDAP, adicione as seguintes informações a um recurso personalizado do Kubernetes chamado ClientConfig:

Informações sobre o provedor de identidade e os parâmetros necessários para retornar informações do usuário.
O nome e o namespace do secret que você criou e aplicou na etapa anterior, o que permite que o cluster se autentique no servidor LDAP.

Para configurar o cluster, edite o ClientConfig default 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.

Confira 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
    ldap:
      certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA
      connectionType: CONNECTION_TYPE
      host: HOST_NAME
      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

É possível adicionar várias configurações de provedores de identidade OIDC, LDAP e SAML ao mesmo ClientConfig. O cluster tenta se autenticar com cada configuração na ordem em que elas são definidas e para após a primeira autenticação bem-sucedida. O exemplo a seguir de ClientConfig define vários provedores de identidade em uma ordem específica:

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
  name: default
  namespace: kube-public
spec:
  authentication:
  - aws:
      region: us-west-2
    name: AWS Login
  - ldap:
  # Multiple lines are omitted here.
  - saml:
  # Multiple lines are omitted here.
  - azureAD:
  # Multiple lines are omitted here.
  - oidc:
    name: Okta OIDC
  # Multiple lines are omitted here.
  - oidc:
    name: Google OIDC
  # Multiple lines are omitted here.

Campos LDAP do ClientConfig

A tabela a seguir descreve os campos do objeto ldap do ClientConfig. Os campos que você precisa adicionar dependem dos tokens do provedor de identidade e de como o administrador da plataforma configurou o provedor.

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
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
Atributo do identificador	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 identifierAttribute 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
Atributo do identificador	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, defina o acesso do usuário de provedores externos a clusters.

Configurar clusters membros da frota para autenticação LDAP Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.