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 o GKE Identity Service.
Registe o serviço de identidade do GKE junto do seu fornecedor
A configuração do GKE Identity Service requer um único ID de cliente e segredo do seu fornecedor de identidade. Este ID e segredo são usados pelo Serviço de identidade do GKE quando se liga ao fornecedor como parte do fluxo de autenticação para os utilizadores. Para os obter, tem de registar o GKE Identity Service junto do seu fornecedor como uma aplicação cliente, seguindo o procedimento padrão do fornecedor escolhido. 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. SubstituaAPISERVER-URL
pelo FQDN do servidor da API Kubernetes do cluster. Por exemplo, se oAPISERVER-URL
forhttps://apiserver.company.com
, oredirect_uri
deve serhttps://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 o serviço de identidade do GKE.
Informações de configuração do Fornecedor de identidade
Esta secção fornece informações adicionais específicas do fornecedor para registar o serviço de identidade do GKE. Se o seu fornecedor estiver listado aqui, registe o serviço de identidade do GKE junto do seu fornecedor como uma aplicação cliente através das seguintes instruções.
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.
Abra o painel de gestão do AD FS.
Selecione Grupos de aplicações > Ações > Adicionar um grupo de aplicações.
Selecione Aplicação de servidor. Introduza um nome e uma descrição à sua escolha. Clique em Seguinte.
Introduza os dois URLs de redirecionamento, conforme especificado acima. É-lhe atribuído um ID de cliente. É assim que o servidor do AD FS identifica o serviço de identidade do GKE. Guarde o ID do cliente para mais tarde.
Selecione Gerar um segredo partilhado. O serviço de identidade do GKE usa este segredo para fazer a autenticação no servidor do AD FS. Guarde a chave secreta para mais tarde.
Configurar grupos de segurança (opcional)
Na gestão do AD FS, selecione Relying party trusts > Add a new relying party trust.
Selecione Reivindicações ativadas e clique em Iniciar.
Selecione Introduzir dados sobre a entidade fidedigna manualmente.
Introduza um nome a apresentar.
Ignore os dois passos seguintes.
Introduza um identificador de confiança da parte fidedigna. Sugestão:
token-groups-claim
.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 .
Clique em Concluir.
Mapeamento de atributos LDAP para nomes de reivindicações
Na gestão do AD FS, selecione Relying party trusts > Edit claim issuance policy.
Selecione Enviar atributos LDAP como reivindicações e clique em Seguinte.
Em Nome da regra de reivindicação, introduza
groups
.Para Armazenamento de atributos, selecione Active Directory.
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
Para Tipo de reivindicação de saída, selecione:
- AD FS versão 5.0 e posterior: Grupo
- Versões do AD FS anteriores à 5.0: grupos
Clique em Concluir e, de seguida, em Aplicar.
Registar o serviço de identidade do GKE 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
.
Azure AD
Registe um cliente OAuth com o Azure
Para registar um cliente OAuth no Azure, conclua os passos nos seguintes links:
Se ainda não o fez, configure um inquilino no Azure Active Directory.
Registe uma aplicação na plataforma de identidade da Microsoft.
Abra a página Registos de apps no portal do Azure e selecione a sua aplicação pelo nome.
Crie um segredo do cliente.
Clique em Adicionar um certificado ou um segredo em Essenciais. É apresentada uma lista de certificados e uma lista de segredos.
Clique em Novo segredo do cliente. Atribua um nome ao segredo e clique em Adicionar.
Guarde o Value* do segredo num local seguro. Não vai poder recuperá-lo depois de fechar ou atualizar a página.
Adicione URIs de redirecionamento.
Volte à página da aplicação.
Selecione Adicionar um URI de redirecionamento em Essenciais. É apresentada a página Autenticação.
Escolha Adicionar uma plataforma e o painel denominado Configurar plataformas é apresentado à direita.
Escolha Web. Em 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. Clique no botão Configurar.Clique no botão Adicionar URI para adicionar outro URI,
https://console.cloud.google.com/kubernetes/oidc
, para o início de sessão na consola. Google CloudClique no botão Guardar na parte superior.
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 comoDirectory (tenant) ID
na página Aplicação no portal do Azure.ID de cliente: o ID de cliente é apresentado como
Application (client) ID
na página da aplicação no portal do Azure.Segredo do cliente: recebeu este segredo no último passo. Não vai poder recuperar esta chave se fechar a página após a criação da mesma. Certifique-se de que guarda o valor numa localização segura (ou gera um novo segredo se perder o anterior).
Configuração avançada para o Azure AD
Considere usar esta configuração avançada apenas quando quiser configurar clusters com políticas de autorização baseadas em grupos do Azure AD em que os utilizadores dos clusters pertencem a mais de 200 grupos do Azure AD. A configuração avançada para o Azure AD suporta as seguintes plataformas:
- Clusters do GKE no local (VMware e bare metal): a partir do GKE Enterprise 1.14
- Clusters do Anthos no AWS: a partir do GKE Enterprise 1.14 (versão do Kubernetes 1.25 ou posterior)
- Clusters do Anthos no Azure: a partir do GKE Enterprise 1.14 (versão do Kubernetes 1.25 ou posterior)
- Clusters do Anthos na AWS (geração anterior): a partir do GKE Enterprise 1.14
Antes de começar, certifique-se de que cada utilizador tem um endereço de email associado configurado como o respetivo identificador no Azure AD. O serviço de identidade do GKE usa o email do utilizador para afirmar a identidade do utilizador e autenticar o pedido.
Tem de garantir que o cliente que registou na secção anterior tem autorizações delegadas para obter informações de utilizadores e grupos da API Microsoft Graph. Estas autorizações permitem que o plug-in do GKE Identity Service aceda aos pontos finais da API Microsoft Graph a partir dos quais as informações do grupo são obtidas. Sem este passo, o GKE Identity Service não pode listar os grupos do utilizador e as políticas de autorização RBAC baseadas em grupos não funcionam como esperado.
Tem de ter autorizações de administrador global ou administrador da organização para executar este passo de configuração.
- Inicie sessão no portal do Azure.
- Se tiver acesso a vários inquilinos, use o filtro Diretório + subscrição no menu superior para selecionar o inquilino que contém o registo da sua app cliente.
- Selecione Azure Active Directory – Registos de apps e, de seguida, selecione a sua aplicação cliente.
- Selecione Autorizações da API – Adicionar uma autorização – Microsoft Graph – Autorizações delegadas.
- No separador Grupo, selecione Group.Read.All. No separador Utilizador, selecione User.Read.All.
- Clique em Adicionar autorizações para concluir o processo.
- Conceda consentimento em nome de todos os utilizadores clicando no botão Conceder consentimento de administrador para…. Pode encontrar mais informações sobre a concessão do consentimento do administrador em 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 (a predefinição assumida ao configurar clusters é
sub
) - O campo (afirmaçã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 Azure e o Okta, o administrador do cluster tem de especificar
prompt=consent
como parâmetro. Se configurou o ADFS 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 ser 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.
Pode ver uma lista completa dos parâmetros de configuração do serviço de identidade do GKE em Configurar clusters.
O que se segue?
O administrador do cluster pode configurar o serviço de identidade do GKE para clusters individuais ou uma frota.