Esta página foi traduzida pela API Cloud Translation.

Configure clusters de membros da frota para autenticação LDAP

Este documento descreve como os administradores de clusters ou os operadores de aplicações podem configurar clusters do Kubernetes para suportar a autenticação de um fornecedor de protocolo LDAP (Lightweight Directory Access Protocol) de terceiros, como o Microsoft Entra ID ou o Google LDAP. Para mais informações, consulte o artigo Acerca da autenticação através de identidades de terceiros.

Limitações

Tem de usar um tipo de cluster que suporte LDAP.

Antes de começar

Install the Google Cloud CLI.
Se estiver a usar um fornecedor de identidade (IdP) externo, tem primeiro de iniciar sessão na CLI gcloud com a sua identidade federada.
Para inicializar a CLI gcloud, execute o seguinte comando:
```
gcloud init
```
Depois de inicializar a CLI gcloud, atualize-a e instale os componentes necessários:
```
gcloud components update
gcloud components install kubectl
```
Certifique-se de que o administrador da plataforma lhe deu todas as informações de fornecedor de que precisa. Para mais informações, consulte o artigo Configure fornecedores LDAP para autenticação em clusters.

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 LDAP populares, incluindo onde encontrar as informações necessárias para iniciar sessão no servidor LDAP e configurar os seus clusters:

Preencha o segredo da conta de serviço LDAP

O cluster precisa de um segredo da conta de serviço para autenticar no servidor LDAP e obter detalhes do utilizador. A autenticação LDAP suporta os seguintes mecanismos:

Autenticação básica, em que usa um nome de utilizador e uma palavra-passe.
Autenticação de certificado de cliente, em que usa uma chave privada de cliente e um certificado de cliente.

O administrador da plataforma ou o utilizador deve ter estas informações acerca do fornecedor seguindo os passos descritos no artigo Configure fornecedores LDAP para autenticação em clusters. Para disponibilizar as informações de início de sessão do servidor LDAP ao cluster, tem de criar um segredo do Kubernetes com os detalhes de início de sessão do LDAP. Os exemplos seguintes mostram como configurar segredos para ambos os tipos de autenticação. Os exemplos mostram o Secret a ser aplicado ao espaço de nomes anthos-identity-service.

Este é 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 segredo. 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. Por predefinição, os componentes do sistema têm autorização para ler segredos neste espaço de nomes. Para usar outro espaço de nomes, altere os metadados no segredo e, em seguida, adicione uma nova política de RBAC para conceder a autorização para ler segredos nesse espaço de nomes à default ServiceAccount no espaço de nomes anthos-identity-service, 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

Para configurar a autenticação num cluster através do LDAP, adicione as seguintes informações a um recurso personalizado do Kubernetes denominado ClientConfig:

Informações acerca do fornecedor de identidade e dos parâmetros de que necessita para devolver informações do utilizador.
O nome e o espaço de nomes do Secret que criou e aplicou no passo anterior, o que permite ao cluster autenticar-se no servidor LDAP.

Para configurar o cluster, edite o default ClientConfig no kube-public namespace:

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

Pode adicionar várias configurações de fornecedores de identidade OIDC, LDAP e SAML à mesma ClientConfig. O cluster tenta autenticar-se com cada configuração pela ordem em que são definidas e para após a primeira autenticação bem-sucedida. O exemplo ClientConfig seguinte define vários fornecedores de identidade numa 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 ClientConfig

A tabela seguinte descreve os campos do objeto ClientConfig ldap. Os campos que tem de adicionar dependem dos tokens do seu fornecedor de identidade e da forma como o administrador da plataforma configurou o fornecedor.

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 com autorização para 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, se definir loginAttribute como `sAMAccountName` e identifierAttribute como `userPrincipalName` , um utilizador pode iniciar sessão como `bsmith`, mas as políticas de RBAC reais para o utilizador seriam escritas como `bsmith@example.com`. 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 corresponder explicitamente apenas 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 de fornecedores externos aos clusters.

Configure clusters de 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.