Configurar provedores OIDC do GKE Identity Service

Neste documento, explicamos como configurar o provedor de identidade OpenID Connect (OIDC) escolhido do GKE Identity Service. Para saber mais sobre o GKE Identity Service, consulte a visão geral.

Este documento é destinado a administradores de plataforma ou a quem gerencia a configuração de identidade na organização. Se você for um administrador do cluster ou operador de aplicativos, peça ao administrador da plataforma para consultar esta seção antes de começar a Configurar os clusters do GKE Identity Service no nível da frota ou Configurar clusters do GKE Identity Service com OIDC.

Registrar o GKE Identity Service com seu provedor

A configuração do GKE Identity Service requer um ID do cliente e uma chave secreta do seu provedor de identidade. Esse ID e secret são usados pelo GKE Identity Service ao se conectar ao provedor como parte do fluxo de autenticação dos usuários. Para isso, você precisa registrar o serviço de identidade do GKE no seu provedor como um aplicativo cliente, seguindo o procedimento padrão do provedor escolhido. Veja 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 para o console do Google Cloud.
  • http://localhost:PORT/callback é o URL de redirecionamento da CLI gcloud. É possível especificar qualquer número de porta maior que 1024.

Registrar seu provedor por um processo de autenticação alternativo

Um processo alternativo para registrar seu provedor é autenticar diretamente pelo servidor do serviço de identidade do GKE. Se você estiver usando um provedor OIDC ou Azure AD, atualize o redirect_uri de acordo com o formato do URL do cluster. O redirect_uri tem o seguinte formato:

      https://CLUSTER-SERVER-FQDN.com:8443/finish-login

Substitua CLUSTER-SERVER-FQDN pelo nome do servidor de cluster.

Por exemplo, se o URL do cluster for https://cluster.company.com, redirect_uri precisará ser https://cluster.company.com:8443/finish-login.

Salve o ID e a chave secreta do cliente recebidos na etapa de registro. Compartilhe esses detalhes com administradores do cluster que precisam configurar o serviço de identidade do GKE. Verifique se você fez o seguinte:

  • Configure seu serviço de nome de domínio (DNS) para resolver CLUSTER-SERVER-FQDN para os VIPs (endereços IP virtuais) do plano de controle. Os usuários podem acessar o cluster usando esse nome de domínio.
  • Use um certificado de indicação de nome do servidor (SNI, na sigla em inglês) emitido pela autoridade de certificação (CA, na sigla em inglês) confiável da empresa. Este certificado menciona especificamente CLUSTER-SERVER-FQDN como um domínio válido, eliminando possíveis avisos de certificado para os usuários. Você pode fornecer o certificado SNI durante a criação do cluster. Para mais informações sobre autenticação com certificados SNI, consulte Autenticação de certificado SNI.
  • Se os certificados SNI não forem viáveis, configure todos os dispositivos de usuário para confiar no certificado de CA do cluster. Isso evita avisos de certificado, mas exige a distribuição do certificado de CA do cluster para todos os usuários.

Para mais informações sobre o acesso de login de usuários usando esses certificados, consulte Configurar um acesso de login de usuário por um processo de autenticação alternativo.

Informações de configuração do provedor

Nesta seção, fornecemos outras informações específicas do provedor para registrar o GKE Identity Service. Se o provedor estiver listado aqui, registre o GKE Identity Service com ele como um aplicativo cliente seguindo as instruções abaixo.

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. É assim que o servidor AD FS identifica o GKE Identity Service. Salve o ID do cliente para uso posterior.

  5. Selecione Gerar um secret compartilhado. O GKE Identity Service usa esse secret para autenticar no servidor AD FS. Guarde 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 console do Google 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 GKE Identity Service 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.

Azure AD

Registrar um cliente OAuth no Azure

Para registrar um cliente OAuth com o Azure, conclua as etapas nos seguintes links:

  1. Se você ainda não tiver feito isso, configure um locatário no Azure Active Directory.

  2. Registre um aplicativo com a plataforma de identidade da Microsoft.

  3. Abra a página Registros de aplicativos no Portal do Azure e selecione seu aplicativo por nome.

  4. Crie uma chave secreta do cliente.

    1. Clique em Adicionar um certificado ou secret em Fundamentos. Uma lista de certificados e uma lista de secrets são exibidas.

    2. Clique em New client secret. Nomeie a chave secreta e clique em Adicionar.

    3. Salve o valor* do secret em um local seguro. Não será possível recuperá-la depois de fechar ou atualizar a página.

  5. Adicione URIs de redirecionamento.

    1. Volte para a página do aplicativo.

    2. Selecione Adicionar um URI de redirecionamento em Essentials. A página Autenticação é exibida.

    3. Escolha Adicionar uma plataforma e o painel chamado Configurar plataformas será exibido à direita.

    4. Selecione Web. Em URIs de redirecionamento, insira http://localhost:PORT/callback no fluxo de login da CLI gcloud. Escolha um PORT maior que 1.024. Clique no botão Configurar.

    5. Clique no botão Adicionar URI para adicionar outro URI, https://console.cloud.google.com/kubernetes/oidc, para o login do console do Google Cloud.

    6. Clique no botão Salvar na parte superior.

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 do aplicativo no portal do Azure.

  • ID do cliente: o ID do cliente é exibido como Application (client) ID na página do aplicativo no portal do Azure.

  • Chave secreta do cliente: você recebeu estas informações na última etapa. Não será possível recuperá-la se você fechar a página após a criação do secret. Salve o valor em um local seguro (ou gere uma nova chave secreta, se você perder o controle da anterior).

Configuração avançada do Azure AD

Considere usar essa configuração avançada apenas quando quiser configurar clusters com políticas de autorização baseadas em grupo do Azure AD em que os usuários dos clusters pertencem a mais de 200 grupos do Azure AD. A configuração avançada do Azure AD é compatível com as seguintes plataformas:

  • Clusters do GKE no local (VMware e bare metal): a partir da versão 1.14 do GKE Enterprise
  • Clusters do Anthos na AWS: a partir da versão 1.14 do GKE Enterprise (versão 1.25 ou mais recente do Kubernetes)
  • Clusters do Anthos no Azure: a partir da versão 1.14 do GKE Enterprise (versão 1.25 ou mais recente do Kubernetes)
  • Clusters do Anthos na AWS (geração anterior): a partir da versão 1.14 do GKE Enterprise

Antes de começar, verifique se cada usuário tem um endereço de e-mail associado configurado como identificador no Azure AD. O GKE Identity Service usa o e-mail do usuário 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 plug-in do GKE Identity Service acesse os endpoints da API Microsoft Graph de onde se busca as informações do grupo. Sem essa etapa, o GKE Identity Service não pode listar os grupos do usuário, e as políticas de autorização do RBAC com base em grupos não funcionarão 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 portal do Azure.
  2. Se você tiver acesso a vários locatários, use o filtro "Diretório + assinatura" no menu superior para selecionar o locatário que contém o registro do aplicativo cliente.
  3. Selecione Azure Active Directory - Registros de aplicativo 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 no botão Conceder consentimento para administradores de.... Veja mais informações sobre como conceder o consentimento de administrador em Mais informações sobre as permissões e o consentimento do administrador.

Compartilhar detalhes do provedor

Verifique se o administrador do cluster tem as seguintes informações necessárias para a configuração do cluster:

  • 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 Azure e o Okta, o administrador do cluster precisará especificar prompt=consent como parâmetro. Se você configurou o ADFS 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.

Confira uma lista completa dos parâmetros de configuração do GKE Identity Service em Configurar clusters.