Configurar o gateway do Connect com identidades de terceiros

Este guia é destinado a administradores de plataformas que precisam configurar o gateway do Connect em um projeto com usuários que não têm Google Identities e não pertencem ao Google Workspace. Neste guia, essas identidades são chamadas de "identidades de terceiros". Antes de ler este guia, você precisa se familiarizar com os conceitos na Visão geral do gateway do Connect. Para autorizar contas individuais do Google, consulte Como configurar o gateway do Connect. Para receber suporte aos Grupos do Google, consulte Como configurar o gateway do Connect com os Grupos do Google.

Com a configuração neste guia, os usuários podem fazer login nos clusters da frota usando a Google Cloud CLI, o gateway do Connect e o console Google Cloud .

Tipos de cluster compatíveis

É possível configurar o controle de acesso com identidades de terceiros por meio do gateway do Connect para os seguintes tipos de cluster:

Para usar esse recurso com ambientes que não estão na lista anterior, entre em contato com o Cloud Customer Care ou a equipe de gateway do Connect.

Como funciona

Conforme descrito na visão geral, talvez os usuários estejam usando provedores de identidade que não são o Google Workspace nem o Cloud Identity. Com a federação de identidade de colaboradores, os usuários podem usar provedores de identidade de terceiros, como o Okta ou o Azure Active Directory, para ter acesso aos clusters pelo gateway do Connect. Ao contrário das Contas do Google, os usuários terceirizados são representados por um principal do Identity and Access Management (IAM) que segue o formato:

principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/subject/SUBJECT_VALUE

  • O WORKFORCE_POOL_ID é o nome do pool da força de trabalho que contém o provedor de identidade de terceiros relevante.

  • O SUBJECT_VALUE é o mapeamento da identidade de terceiros para um assunto do Google.

Para grupos de terceiros, o principal do IAM segue o formato:

principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/group/GROUP_VALUE

O diagrama a seguir mostra um fluxo típico de um usuário de terceiros que faz a autenticação e executa comandos em um cluster com esse serviço ativado. Para que esse fluxo funcione, uma política de controle de acesso baseado em função (RBAC) precisa ser aplicada ao cluster para o usuário ou um grupo.

Para usuários individuais, uma política de RBAC que usa o nome completo do principal do IAM do usuário precisa existir no cluster.

Se você estiver usando a funcionalidade de grupo, uma política de RBAC que use o nome completo do principal do IAM precisa existir no cluster para um grupo que:

  1. Contém o usuário alice@example.com como membro.

  2. Está incluído no mapeamento de um provedor de identidade em um pool de força de trabalho que está na organização Google Cloud de Alice.

Diagrama mostrando o fluxo de identidade de terceiros do gateway

  1. O usuário alice@example.com faz login na CLI gcloud com a identidade de terceiros usando o login baseado em navegador de terceiros. Para usar o cluster na linha de comando, o usuário recebe o gateway kubeconfig do cluster, conforme descrito em Como usar o gateway do Connect.
  2. O usuário envia uma solicitação executando um comando kubectl ou abrindo as páginas Cargas de trabalho ou Navegador de objetos do Google Kubernetes Engine no console do Google Cloud .
  3. A solicitação é recebida pelo gateway do Connect, que processa a autenticação de terceiros usando a federação de identidade de colaboradores.
  4. O gateway do Connect realiza uma verificação de autorização com o IAM.
  5. O serviço do Connect encaminha a solicitação ao agente do Connect em execução no cluster. A solicitação é acompanhada com as informações de credencial do usuário para uso na autenticação e autorização no cluster.
  6. O agente do Connect encaminha a solicitação para o servidor de API do Kubernetes.
  7. O servidor de API Kubernetes encaminha a solicitação para o componente do serviço de identidade no cluster, que valida a solicitação.
  8. O componente do serviço de identidade retorna as informações de grupo e usuário de terceiros para o servidor de API Kubernetes. O servidor de API do Kubernetes pode usar essas informações para autorizar a solicitação com base nas políticas de RBAC configuradas do cluster.

Antes de começar

  1. Faça login na sua conta do Google Cloud . Se você começou a usar o Google Cloudagora, crie uma conta para avaliar o desempenho dos nossos produtos em situações reais. Clientes novos também recebem US $300 em créditos para executar, testar e implantar cargas de trabalho.

  2. Instale a CLI do Google Cloud.

  3. Ao usar um provedor de identidade (IdP) externo, primeiro faça login na CLI gcloud com sua identidade federada.

  4. Para inicializar a CLI gcloud, execute o seguinte comando: 

    gcloud init

  5. Verifique se você tem as permissões necessárias para concluir este guia.

  6. Ative as APIs Connect Gateway, GKE Connect, GKE Hub, Anthos Identity Service e Cloud Resource Manager, se alguma delas ainda não estiver ativada:

    Funções necessárias para ativar APIs

    Para ativar APIs, você precisa da permissão serviceusage.services.enable. Se você criou o projeto, provavelmente já tem essa permissão pelo papel de Proprietário (roles/owner). Caso contrário, é possível receber essa permissão pelo papel de Administrador do Service Usage (roles/serviceusage.serviceUsageAdmin). Saiba como conceder papéis. 

    gcloud services enable connectgateway.googleapis.com gkeconnect.googleapis.com gkehub.googleapis.com anthosidentityservice.googleapis.com cloudresourcemanager.googleapis.com

  7. Instale a CLI do Google Cloud.

  8. Ao usar um provedor de identidade (IdP) externo, primeiro faça login na CLI gcloud com sua identidade federada.

  9. Para inicializar a CLI gcloud, execute o seguinte comando: 

    gcloud init

  10. Verifique se você tem as permissões necessárias para concluir este guia.

  11. Ative as APIs Connect Gateway, GKE Connect, GKE Hub, Anthos Identity Service e Cloud Resource Manager, se alguma delas ainda não estiver ativada:

    Funções necessárias para ativar APIs

    Para ativar APIs, você precisa da permissão serviceusage.services.enable. Se você criou o projeto, provavelmente já tem essa permissão pelo papel de Proprietário (roles/owner). Caso contrário, é possível receber essa permissão pelo papel de Administrador do Service Usage (roles/serviceusage.serviceUsageAdmin). Saiba como conceder papéis. 

    gcloud services enable connectgateway.googleapis.com gkeconnect.googleapis.com gkehub.googleapis.com anthosidentityservice.googleapis.com cloudresourcemanager.googleapis.com
    12.
  12. Para clusters fora do Google Cloud, os componentes de autenticação no seu cluster precisam chamar a API Cloud Identity. Verifique se você tem políticas de rede que exigem que o tráfego de saída do cluster passe por um proxy.

Funções exigidas

Para receber as permissões necessárias para configurar o gateway de conexão e seus clusters, peça ao administrador para conceder a você o papel do IAM de Editor (roles/editor) no projeto. Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Também é possível conseguir as permissões necessárias usando papéis personalizados ou outros papéis predefinidos.

Configurar mapeamentos de atributos de identidade de terceiros usando a federação de identidade de colaboradores

Verifique se há um pool de força de trabalho e um provedor de identidade configurados para sua organização do Google Cloud seguindo as instruções correspondentes ao provedor de identidade:

.

Configurar o suporte para grupos

O gateway do Connect usa componentes de autenticação no seu cluster para recuperar informações de associação a grupos. Para ativar os componentes necessários, consulte um dos seguintes documentos, dependendo do tipo de cluster:

Se o cluster ou a frota já estiver configurado para a compatibilidade com Grupos do Google, não haverá outras etapas. Você poderá pular para Conceder papéis do IAM a usuários e grupos de terceiros.

As seções a seguir mostram como atualizar o recurso personalizado ClientConfig para ativar o suporte a grupos. Estas seções se aplicam apenas aos clusters do Google Distributed Cloud. Para outros tipos de clusters, como o GKE no Google Cloud, o GKE na AWS e o GKE no Azure, pule para a seção Conceder papéis do IAM a grupos.

No Distributed Cloud, é possível configurar o suporte para grupos em clusters individuais ou em uma frota. O tipo de cluster usado determina como você configura o suporte a grupos, da seguinte maneira:

  • Distributed Cloud conectado: somente clusters individuais. A configuração no nível da frota não é compatível.
  • Google Distributed Cloud (somente software) no VMware e em bare metal: clusters ou frotas individuais.

Configurar o suporte a grupos usando a API Fleet do GKE

No Google Distributed Cloud (somente software) no VMware e em bare metal, é possível configurar o suporte a grupos no nível da frota. Se você já configurou a autenticação no nível da frota, como para um provedor de identidade diferente, a autenticação de grupo já está ativada. No entanto, se a política de rede exigir que o tráfego de saída passe por um proxy, atualize a configuração atual com informações sobre esse proxy.

Para configurar o suporte a grupos no nível da frota, selecione uma das seguintes opções:

Console

  1. No console do Google Cloud , acesse a página Serviço de Identidade do GKE.

    Acessar o GKE Identity Service

  2. Clique em Ativar o serviço de identidade.

  3. Selecione os clusters do Google Distributed Cloud (somente software) no VMware e bare metal que você quer configurar.

  4. Clique em Atualizar configuração. O painel Editar a configuração de clusters do serviço de identidade é aberto.

  5. Na seção Configurar provedores de identidade, você pode escolher reter, adicionar, atualizar ou remover um provedor de identidade.

  6. Clique em Continuar para ir para a próxima etapa de configuração. Se você tiver selecionado pelo menos um cluster qualificado para essa configuração, a seção Autenticação do Google será exibida.

  7. Selecione Ativar para habilitar a autenticação do Google para os clusters selecionados. Se você precisar acessar o Google Identity usando um proxy, digite os detalhes do Proxy.

  8. Clique em Atualizar configuração. Isso aplica a configuração de identidade nos clusters selecionados.

gcloud

  1. Ative o recurso de serviço de identidade no nível da frota e configure os clusters, conforme descrito em Configurar o gerenciamento de autenticação no nível da frota.

  2. No arquivo auth-config.yaml que contém a especificação ClientConfig, adicione o seguinte campo:

    spec:
  authentication:
  - name: google-authentication-method
    google:
      disable: false

    O valor de false no campo google.disable ativa o suporte a grupos. Para desativar o suporte a grupos, mude esse valor para true.

  3. Opcional: se você precisar acessar o Google Identity por meio de um proxy, adicione o campo proxy à configuração anterior:

    spec:
  authentication:
  - name: google-authentication-method
    google:
      disable: false
    proxy: PROXY_URL

    Substitua PROXY_URL pelo endereço do servidor proxy para se conectar ao Google Identity. Por exemplo: http://user:password@10.10.10.10:8888

  4. Aplique a configuração a um cluster na sua frota:

    gcloud container fleet identity-service apply \
--membership=CLUSTER_NAME \
--config=/path/to/auth-config.yaml

    Substitua CLUSTER_NAME pelo nome de assinatura exclusivo do cluster na frota.

Depois de configurar o suporte a grupos no nível da frota, o controlador da frota gerencia a configuração. A configuração no nível da frota substitui todas as mudanças locais feitas na configuração de um cluster específico.

Configurar o suporte a grupos para clusters individuais

Para todos os clusters do Distributed Cloud, incluindo o Distributed Cloud conectado, ative o suporte a grupos atualizando o ClientConfig default em cada cluster:

  1. Receba os detalhes da assinatura do cluster:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get memberships membership -o yaml

    Substitua USER_CLUSTER_KUBECONFIG pelo caminho do arquivo kubeconfig do cluster. Se houver vários contextos no kubeconfig o contexto atual será usado. Talvez seja necessário redefinir o contexto atual para o cluster correto antes de executar o comando.

    Na resposta, consulte o campo spec.owner.id para recuperar os detalhes da associação do cluster. O identificador de associação tem o formato //gkehub.googleapis.com/projects/PROJECT_NUMBER/locations/global/memberships/MEMBERSHIP.

    O resultado será o seguinte:

    id: //gkehub.googleapis.com/projects/123456789/locations/global/memberships/xy-ab12cd34ef

  2. Abra o ClientConfig default no cluster para edição:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-public edit clientconfig default

  3. Para ativar o suporte a grupos, adicione o campo google ao campo spec.authentication:

    spec:
  internalServer: https://kubernetes.default.svc
  authentication:
  - google:
      audiences:
      - "CLUSTER_IDENTIFIER"
    name: google-authentication-method

    Substitua CLUSTER_IDENTIFIER pelos detalhes da assinatura do cluster.

    Confira se o campo internalServer tem um valor de https://kubernetes.default.svc.

  4. Opcional: se você precisar acessar o Google Identity por meio de um proxy, adicione o campo proxy à configuração anterior:

    spec:
  internalServer: https://kubernetes.default.svc
  authentication:
  - google:
      audiences:
      - "CLUSTER_IDENTIFIER"
    name: google-authentication-method
    proxy: PROXY_URL

    Substitua PROXY_URL pelo endereço do servidor proxy para se conectar ao Google Identity. Por exemplo: http://user:password@10.10.10.10:8888

Conceder papéis do IAM a usuários e grupos de terceiros

As identidades de terceiros precisam dos seguintes papéis adicionais do Google Cloud para interagir com clusters conectados pelo gateway:

  • roles/gkehub.gatewayAdmin: esse papel permite que os usuários acessem a API do gateway do Connect.
    • Se os usuários só precisarem de acesso somente leitura aos clusters conectados, use roles/gkehub.gatewayReader.
    • Se os usuários precisarem de acesso de leitura/gravação aos clusters conectados, poderá usar roles/gkehub.gatewayEditor.
  • roles/gkehub.viewer: esse papel permite que os usuários acessem as assinaturas registradas a clusters.

Confira a seguir como adicionar os papéis necessários a identidades individuais e grupos mapeados:

Identidades únicas

Para conceder os papéis necessários a uma única identidade para o projeto PROJECT_ID, execute o seguinte comando:

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=GATEWAY_ROLE \
    --member="principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/subject/SUBJECT_VALUE"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/gkehub.viewer \
    --member="principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/subject/SUBJECT_VALUE"

onde

  • PROJECT_ID é o ID do projeto.
  • GATEWAY_ROLE é um dos campos roles/gkehub.gatewayAdmin, roles/gkehub.gatewayReader ou gkehub.gatewayEditor.
  • WORKFORCE_POOL_ID é o ID do pool de identidade da força de trabalho.
  • SUBJECT_VALUE é a identidade do usuário.

Grupos

Para conceder os papéis necessários a todas as identidades em um grupo específico para o projeto PROJECT_ID, execute o seguinte comando:

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=GATEWAY_ROLE \
    --member="principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/group/GROUP_ID"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/gkehub.viewer \
    --member="principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/group/GROUP_ID"

onde

  • PROJECT_ID é o ID do projeto.
  • GATEWAY_ROLE é um dos campos roles/gkehub.gatewayAdmin, roles/gkehub.gatewayReader ou gkehub.gatewayEditor.
  • WORKFORCE_POOL_ID: é o ID do pool da força de trabalho.
  • GROUP_ID: é um grupo na declaração google.groups mapeada.

Consulte a configuração do seu provedor de identidade listada em Configurar mapeamentos de terceiros com a identidade da força de trabalho para mais personalizações, como especificar atributos do departamento, ao aplicar a política de RBAC.

Saiba mais sobre como conceder permissões e papéis do IAM em Como conceder, alterar e revogar acesso a recursos.

Configurar políticas de controle de acesso baseado em papéis (RBAC, na sigla em inglês)

Por fim, o servidor de API Kubernetes de cada cluster precisa autorizar comandos kubectl que passam pelo gateway do usuário e dos grupos de terceiros especificados. Para cada cluster, você precisa adicionar uma política de permissões do RBAC que especifica quais permissões o assunto tem no cluster.

Os assuntos nas políticas do RBAC precisam usar o mesmo formato das vinculações do IAM, com usuários de terceiros começando com principal://iam.googleapis.com/ e grupos de terceiros começando com principalSet://iam.googleapis.com/. Se o cluster não tiver a autenticação de identidades externas de terceiros configurada, você precisará de políticas de representação, além de papéis/papéis de cluster para um usuário de terceiros. Nesse caso, siga estas etapas de configuração do RBAC, adicionando o principal de terceiros que começa com principal://iam.googleapis.com/ como usuário.

No exemplo a seguir, mostramos como conceder permissões cluster-admin aos membros de um grupo de terceiros em um cluster em que a autenticação de identidades externas de terceiros está configurada. Em seguida, salve o arquivo de política como /tmp/admin-permission.yaml e aplique-o ao cluster associado ao contexto atual.

cat <<EOF > /tmp/admin-permission.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: gateway-cluster-admin-group
subjects:
- kind: Group
  name: "principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/group/GROUP"
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
EOF
# Apply permission policy to the cluster.
kubectl apply --kubeconfig=KUBECONFIG_PATH -f /tmp/admin-permission.yaml

Saiba mais sobre como especificar permissões de RBAC em Como usar a autorização RBAC.

A seguir