Configure fornecedores OIDC para autenticar em clusters

Este documento destina-se a administradores da plataforma ou a quem gere a configuração de identidade na sua organização. Explica como configurar o fornecedor de identidade OpenID Connect (OIDC) escolhido para autenticação em clusters do Kubernetes que não estão no Google Cloud.

Registe uma aplicação cliente junto do seu fornecedor

Durante o fluxo de autenticação para utilizadores, o cluster usa um ID de cliente e um segredo para se ligar ao seu fornecedor de identidade. Pode obter um ID de cliente e um segredo do seu fornecedor de identidade configurando uma aplicação cliente para o Kubernetes. O procedimento para configurar uma aplicação cliente depende do seu fornecedor. Pode encontrar alguns detalhes de registo específicos de fornecedores populares na secção seguinte.

Para URLs de redirecionamento, especifique os seguintes valores:

  • https://console.cloud.google.com/kubernetes/oidc é o URL de redirecionamento da Google Cloud consola.
  • http://localhost:PORT/callback é o URL de redirecionamento para a CLI gcloud. Pode especificar qualquer número de porta superior a 1024.
  • APISERVER_URL:11001/finish-login é o URL de redirecionamento se optar por autenticar através do acesso FQDN. Substitua APISERVER_URL pelo FQDN do servidor da API Kubernetes do cluster. Por exemplo, se o APISERVER_URL for https://apiserver.company.com, o redirect_uri deve ser https://apiserver.company.com:11001/finish-login.

Guarde o ID de cliente e o segredo que recebe no passo de registo. Partilhe estes detalhes com os administradores do cluster que precisam de configurar os respetivos clusters.

Informações de configuração do Fornecedor de identidade

Esta secção fornece passos para registar uma aplicação cliente com os Microsoft Active Directory Federation Services (AD FS) ou com o Microsoft Entra ID.

Microsoft AD FS

Use um conjunto de assistentes de gestão do AD FS para configurar o servidor AD FS e a base de dados de utilizadores do AD.

  1. Abra o painel de gestão do AD FS.

  2. Selecione Grupos de aplicações > Ações > Adicionar um grupo de aplicações.

  3. Selecione Aplicação de servidor. Introduza um nome e uma descrição à sua escolha. Clique em Seguinte.

  4. Introduza os dois URLs de redirecionamento, conforme especificado acima. É-lhe atribuído um ID de cliente. O AD FS identifica o cluster através deste ID de cliente. Guarde o ID do cliente para mais tarde.

  5. Selecione Gerar um segredo partilhado. O mecanismo de autenticação do Kubernetes usa este segredo para autenticar no servidor do AD FS. Guarde o segredo para mais tarde.

Configurar grupos de segurança (opcional)

  1. Na gestão do AD FS, selecione Relying party trusts > Add a new relying party trust.

  2. Selecione Reivindicações ativadas e clique em Iniciar.

  3. Selecione Introduzir dados sobre a entidade fidedigna manualmente.

  4. Introduza um nome a apresentar.

  5. Ignore os dois passos seguintes.

  6. Introduza um identificador de confiança da parte fidedigna. Sugestão: token-groups-claim.

  7. Para Política de controlo de acesso, selecione Permitir a todos. Isto significa que todos os utilizadores partilham as informações do respetivo grupo de segurança com a CLI gcloud e a consolaGoogle Cloud .

  8. Clique em Concluir.

Mapeamento de atributos LDAP para nomes de reivindicações

  1. Na gestão do AD FS, selecione Relying party trusts > Edit claim issuance policy.

  2. Selecione Enviar atributos LDAP como reivindicações e clique em Seguinte.

  3. Em Nome da regra de reivindicação, introduza groups.

  4. Para Armazenamento de atributos, selecione Active Directory.

  5. Na tabela, para Atributo LDAP, selecione:

    • AD FS versão 5.0 e posterior: grupos de tokens qualificados pelo nome do domínio
    • Versões do AD FS anteriores à 5.0: Token Groups - Qualified Names

  6. Para Tipo de reivindicação de saída, selecione:

    • Versão 5.0 e posterior do AD FS: Grupo
    • Versões do AD FS anteriores à 5.0: grupos

  7. Clique em Concluir e, de seguida, em Aplicar.

Registar a aplicação cliente Kubernetes com o AD FS

Abra uma janela do PowerShell no modo de administrador e introduza este comando:

Grant-AD FSApplicationPermission `
  -ClientRoleIdentifier "[CLIENT_ID]" `
 -ServerRoleIdentifier [SERVER_ROLE_IDENTIFIER] `
  -ScopeName "allatclaims", "openid"

Substitua o seguinte:

  • [CLIENT_ID] é o ID de cliente que obteve anteriormente.

  • [SERVER_ROLE_IDENTIFIER] é o identificador da reivindicação que introduziu anteriormente. Lembre-se de que o identificador sugerido era token-groups-claim.

Microsoft Entra ID

Para registar um cliente OAuth com o Microsoft Entra ID, conclua os passos nos seguintes links:

  1. Se ainda não o fez, Configure um inquilino do Microsoft Entra.

  2. Registe uma aplicação no Microsoft Entra ID.

  3. No centro de administração do Microsoft Entra, abra a página Registos de apps e selecione a sua aplicação. É aberta a página de vista geral da aplicação.

  4. Crie um segredo do cliente:

    1. No menu de navegação, clique em Certificados e segredos.
    2. Clique no separador Segredos do cliente.
    3. Clique em Novo segredo do cliente. Atribua um nome ao segredo e clique em Adicionar.
    4. Guarde o Valor do segredo num local seguro. Não vai poder recuperá-lo depois de fechar ou atualizar a página.

    Para mais informações, consulte o artigo Adicione e faça a gestão de credenciais de aplicações no Microsoft Entra ID.

  5. Adicione URIs de redirecionamento:

    1. No menu de navegação, clique em Autenticação.
    2. Na secção Configurações da plataforma, clique em Adicionar uma plataforma. É aberto o painel Configurar plataformas.
    3. Clique em Web.
    4. No campo URIs de redirecionamento, introduza http://localhost:PORT/callback para o fluxo de início de sessão da CLI gcloud. Escolha um PORT superior a 1024.
    5. Clique em Configurar.
    6. Clique em Adicionar URI para adicionar outro URI.
    7. Introduza https://console.cloud.google.com/kubernetes/oidc para o fluxo de início de sessão da consola.Google Cloud
    8. Guarde a configuração.

    Para mais informações, consulte o artigo Como adicionar um URI de redirecionamento à sua aplicação.

O registo do cliente está agora concluído. Deve ter as seguintes informações para partilhar com o administrador do cluster:

  • URI do emissor: https://login.microsoftonline.com/TENANT_ID/v2.0. O ID do inquilino é apresentado como Directory (tenant) ID na página de vista geral da aplicação no centro de administração do Microsoft Entra.

  • ID de cliente: o ID de cliente é apresentado como Application (client) ID na página de vista geral da aplicação no centro de administração do Microsoft Entra.

  • Segredo do cliente: o valor do segredo do cliente que criou quando registou a aplicação cliente. Se não tiver acesso a este valor, gere um novo secret.

Configuração avançada do Microsoft Entra ID

Considere usar esta configuração avançada apenas quando quiser configurar clusters com políticas de autorização baseadas em grupos do Microsoft Entra ID em que os utilizadores dos clusters pertencem a mais de 200 grupos do Microsoft Entra ID. A configuração avançada do Microsoft Entra ID é compatível com as seguintes plataformas:

  • Google Distributed Cloud nas instalações (VMware e Bare Metal): a partir da versão 1.14
  • GKE no AWS: a partir da versão 1.14 (versão do Kubernetes 1.25 ou posterior)
  • GKE no Azure: a partir da versão 1.14 (versão 1.25 ou posterior do Kubernetes)

Antes de começar, certifique-se de que cada utilizador tem um endereço de email associado configurado como o respetivo identificador no Microsoft Entra ID. Este endereço de email é usado para afirmar a identidade do utilizador e autenticar o pedido.

Tem de garantir que o cliente que registou na secção anterior delegou autorizações para obter informações de utilizadores e grupos da API Microsoft Graph. Estas autorizações permitem que o mecanismo de autenticação do Kubernetes aceda aos endpoints da API Microsoft Graph a partir dos quais as informações do grupo são obtidas. Sem este passo, o cluster não consegue obter informações do grupo para o utilizador, o que faz com que as políticas de autorização RBAC baseadas em grupos não funcionem como esperado.

Tem de ter autorizações de administrador global ou administrador da organização para executar este passo de configuração.

  1. Inicie sessão no centro de administração do Microsoft Entra.
  2. Selecione o inquilino do Microsoft Entra que tem a sua aplicação cliente.
  3. Selecione Registos de apps e, de seguida, selecione a sua aplicação cliente.
  4. Selecione Autorizações da API – Adicionar uma autorização – Microsoft Graph – Autorizações delegadas.
  5. No separador Grupo, selecione Group.Read.All. No separador Utilizador, selecione User.Read.All.
  6. Clique em Adicionar autorizações para concluir o processo.
  7. Conceda consentimento em nome de todos os utilizadores clicando em Conceder consentimento de administrador para…. Para mais informações, consulte o artigo Mais informações sobre as autorizações da API e o consentimento do administrador.

Partilhe os detalhes do Fornecedor de identidade

Partilhe as seguintes informações do fornecedor com o administrador do cluster para a configuração do cluster:

  • O URI do emissor do fornecedor
  • O segredo do cliente
  • O ID de cliente
  • O URI de redirecionamento e a porta que especificou para a CLI gcloud
  • O campo (afirmação) do nome de utilizador que o seu fornecedor usa para identificar os utilizadores nos respetivos tokens (o valor predefinido assumido ao configurar clusters é sub)
  • O campo (reivindicação) do nome do grupo que o seu fornecedor usa para devolver grupos de segurança, se aplicável.
  • Quaisquer âmbitos ou parâmetros adicionais específicos do seu fornecedor, conforme descrito na secção anterior. Por exemplo, se o seu servidor de autorização pedir consentimento para autenticação com o Microsoft Entra ID e o Okta, o administrador do cluster tem de especificar prompt=consent como parâmetro. Se configurou o AD FS para fornecer informações do grupo de segurança, o parâmetro adicional relevante é resource=token-groups-claim (ou o que escolheu como identificador de confiança da parte fidedigna).
  • (Opcional) Se o seu fornecedor não estiver a usar um certificado assinado por uma autoridade de certificação pública (por exemplo, se estiver a usar certificados autoassinados), precisa de um certificado (ou uma cadeia de certificados) do fornecedor de identidade. O certificado (ou a cadeia de certificados) tem de conter, no mínimo, o certificado de raiz (são aceites cadeias parciais, desde que a cadeia seja contígua até ao certificado de raiz). Quando fornecer este valor em ClientConfig, tem de estar formatado como uma string codificada em base64. Para criar a string, concatene os certificados codificados em PEM completos numa única string e, em seguida, codifique-a em base64.

Para mais informações sobre os parâmetros de configuração para clusters, consulte Configure clusters.

O que se segue?