Configurar provedores OIDC para autenticar em clusters

Este documento é destinado a administradores de plataforma ou a quem gerencia a configuração de identidade na organização. Ele explica como configurar o provedor de identidade OpenID Connect (OIDC) escolhido para autenticação em clusters do Kubernetes que não estão no Google Cloud.

Registrar um aplicativo cliente com seu provedor

Durante o fluxo de autenticação para usuários, o cluster usa um ID do cliente e um secret para se conectar ao provedor de identidade. Para isso, configure um aplicativo cliente para Kubernetes. O procedimento para configurar um aplicativo cliente depende do seu provedor. Confira alguns detalhes de registro específicos de provedores conhecidos na próxima seção.

Para URLs de redirecionamento, especifique os seguintes valores:

  • https://console.cloud.google.com/kubernetes/oidc é o URL de redirecionamento do console Google Cloud .
  • http://localhost:PORT/callback é o URL de redirecionamento da CLI gcloud. É possível especificar qualquer número de porta maior que 1024.
  • APISERVER_URL:11001/finish-login é o URL de redirecionamento se você escolher autenticar usando o acesso FQDN. Substitua APISERVER_URL pelo FQDN do servidor da API Kubernetes do cluster. Por exemplo, se APISERVER_URL for https://apiserver.company.com, redirect_uri será https://apiserver.company.com:11001/finish-login.

Salve o ID e o Secret do cliente recebidos na etapa de registro. Compartilhe esses detalhes com administradores do cluster que precisam configurar os clusters.

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

Esta seção mostra as etapas para registrar um aplicativo cliente com os Serviços de Federação do Active Directory (AD FS) da Microsoft ou com o Microsoft Entra ID.

Microsoft AD FS

Use um conjunto de assistentes de gerenciamento do AD FS para configurar o servidor do AD FS e o banco de dados de usuários do AD.

  1. Abra o painel de gerenciamento do AD FS.

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

  3. Selecione Aplicativo do servidor. Insira um nome e uma descrição de sua escolha. Clique em Next.

  4. Insira os dois URLs de redirecionamento, conforme especificado acima. Você recebe um ID de cliente. O AD FS identifica o cluster usando esse ID do cliente. Salve o ID do cliente para uso posterior.

  5. Selecione Gerar um secret compartilhado. O mecanismo de autenticação do Kubernetes usa esse secret para autenticar no servidor AD FS. Salve o secret para mais tarde.

Como configurar grupos de segurança (opcional)

  1. No gerenciamento do AD FS, selecione Confiança de terceira parte confiável > Adicionar uma nova confiança de terceira parte confiável.

  2. Selecione Reconhecimento de declarações e clique em Iniciar.

  3. Selecione Inserir dados sobre terceiros confiáveis manualmente.

  4. Insira um nome de exibição.

  5. Pule os próximos dois passos.

  6. Insira um identificador de confiança da parte confiável. Sugestão: token-groups-claim.

  7. Em Política de controle de acesso, selecione Permitir todos. Isso significa que todos os usuários compartilham as respectivas informações de grupo de segurança com a CLI gcloud e o consoleGoogle Cloud .

  8. Clique em Concluir.

Como mapear atributos LDAP para nomes de declaração

  1. No gerenciamento do AD FS, selecione Confiança de terceira parte confiável > Editar política de emissão de declarações.

  2. Selecione Enviar atributos LDAP como declarações e clique em Próximo.

  3. Em Nome da regra de declaração, insira groups.

  4. Em Armazenamento de atributos, selecione Active Directory.

  5. Na tabela, em Atributo LDAP, selecione:

    • AD FS versão 5.0 e mais recentes: Grupos de token qualificados pelo nome de domínio
    • Versões do AD FS anteriores à 5.0: Nomes qualificados de grupos de token

  6. Em Tipo de declaração de saída, selecione:

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

  7. Clique em Concluir e em Aplicar.

Como registrar o aplicativo cliente do Kubernetes com o AD FS

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

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

Substitua:

  • [CLIENT_ID] é o ID do cliente que você recebeu anteriormente;

  • [SERVER_ROLE_IDENTIFIER] é o identificador de declaração inserido anteriormente. Lembre-se de que o identificador sugerido foi token-groups-claim.

Microsoft Entra ID

Para registrar um cliente OAuth com o Microsoft Entra ID, conclua as etapas nos seguintes links:

  1. Se você ainda não tiver feito isso, configure um locatário do Microsoft Entra.

  2. Registre um aplicativo no Microsoft Entra ID.

  3. No centro de administração do Microsoft Entra, abra a página Registros de apps e selecione seu aplicativo. A página de visão geral do aplicativo é aberta.

  4. Crie uma chave secreta do cliente:

    1. No menu de navegação, clique em Certificados e segredos.
    2. Clique na guia Chaves secretas do cliente.
    3. Clique em New client secret. Nomeie a chave secreta e clique em Adicionar.
    4. Salve o valor do secret em um local seguro. Não será possível recuperá-la depois de fechar ou atualizar a página.

    Para mais informações, consulte Adicionar e gerenciar credenciais de aplicativos no Microsoft Entra ID.

  5. Adicione URIs de redirecionamento:

    1. No menu de navegação, clique em Autenticação.
    2. Na seção Configurações da plataforma, clique em Adicionar uma plataforma. O painel Configurar plataformas é aberto.
    3. Clique em Web.
    4. No campo URIs de redirecionamento, insira http://localhost:PORT/callback no fluxo de login da CLI gcloud. Escolha um PORT maior que 1.024.
    5. Clique em Configurar.
    6. Clique em Adicionar URI para adicionar outro URI.
    7. Insira https://console.cloud.google.com/kubernetes/oidc para o fluxo de login do console Google Cloud .
    8. Salve sua configuração.

    Para mais informações, consulte Como adicionar um URI de redirecionamento ao seu aplicativo.

Seu registro de cliente foi concluído. Você precisa ter as seguintes informações para compartilhar com o administrador do cluster:

  • Emissor de URI: https://login.microsoftonline.com/TENANT_ID/v2.0. O ID do locatário é exibido como Directory (tenant) ID na página de visão geral do aplicativo no centro de administração do Microsoft Entra.

  • ID do cliente: o ID do cliente é exibido como Application (client) ID na página de visão geral do aplicativo no centro de administração do Microsoft Entra.

  • Chave secreta do cliente: o valor da chave secreta do cliente que você criou ao registrar o aplicativo cliente. Se você não tiver acesso a esse valor, gere um novo secret.

Configuração avançada do Microsoft Entra ID

Considere usar essa configuração avançada apenas quando quiser configurar clusters com políticas de autorização baseadas em grupo do Microsoft Entra ID em que os usuários 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 no local (VMware e bare metal): a partir da versão 1.14
  • GKE na AWS: a partir da versão 1.14 (versão 1.25 ou mais recente do Kubernetes)
  • GKE no Azure: a partir da versão 1.14 (versão 1.25 ou mais recente do Kubernetes)

Antes de começar, verifique se cada usuário tem um endereço de e-mail associado configurado como identificador no Microsoft Entra ID. Esse endereço de e-mail é usado para declarar a identidade do usuário e autenticar a solicitação.

É preciso garantir que o cliente registrado na seção anterior tenha delegado permissões para acessar informações de usuários e grupos da API Microsoft Graph. Essas permissões permitem que o mecanismo de autenticação do Kubernetes acesse os endpoints da API Microsoft Graph de onde as informações do grupo são buscadas. Sem essa etapa, o cluster não pode receber informações de grupo para o usuário, o que faz com que as políticas de autorização do RBAC com base em grupos não funcionem como esperado.

Você precisa ter permissões de administrador global ou da organização para realizar esta etapa de configuração.

  1. Faça login no centro de administração do Microsoft Entra.
  2. Selecione o locatário do Microsoft Entra que tem seu aplicativo cliente.
  3. Selecione Registros de apps e, em seguida, selecione o aplicativo cliente.
  4. Selecione Permissões da API - Adicionar uma permissão - Microsoft Graph - Permissões delegadas.
  5. Na guia Grupo, marque Group.Read.All. Na guia Usuário, marque User.Read.All.
  6. Clique em Adicionar permissões para concluir o processo.
  7. Conceda consentimento em nome de todos os usuários clicando em Conceder consentimento de administrador para.... Para mais informações, consulte Mais informações sobre as permissões e o consentimento do administrador.

Compartilhar os detalhes do provedor de identidade

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

  • O URI do emissor do provedor.
  • A chave secreta do cliente
  • O ID do cliente
  • O URI de redirecionamento e a porta especificados para a CLI gcloud
  • O campo de nome de usuário (declaração) que seu provedor usa para identificar usuários nos tokens (o padrão presumido ao configurar clusters é sub)
  • O campo de nome do grupo (reivindicação) usado pelo seu provedor para retornar grupos de segurança, se houver.
  • Outros escopos ou parâmetros específicos do seu provedor, conforme descrito na seção anterior. Por exemplo, se o servidor de autorização solicitar o consentimento para autenticação com o Microsoft Entra ID e o Okta, o administrador do cluster precisará especificar prompt=consent como parâmetro. Se você 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 você escolheu como identificador de confiança da parte confiável).
  • (Opcional) Se o provedor não estiver usando um certificado assinado por uma autoridade de certificação pública (por exemplo, se você estiver usando certificados autoassinados), será necessário um certificado (ou cadeia de certificados) do provedor de identidade. O certificado (ou cadeia de certificados) precisa conter, no mínimo, o certificado raiz. As cadeias parciais são aceitas, desde que a cadeia seja contígua ao certificado raiz. Ao fornecer esse valor em ClientConfig, ele precisa ser formatado como uma string codificada em base64. Para criar a string, concatene os certificados codificados em PEM completos em uma única string e codifique-a em base64.

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

A seguir