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 identidades do Google 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 do Google Cloud .

Tipos de cluster compatíveis

É possível configurar o controle de acesso com identidades de terceiros pelo 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 da API Kubernetes.
  7. O servidor da API Kubernetes encaminha a solicitação para o componente de 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 da API Kubernetes. O servidor da API 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 Cloud, crie uma conta para avaliar o desempenho de 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:

    Funções necessárias para ativar APIs

    Para ativar as APIs, é necessário ter o papel do IAM de administrador de uso do serviço (roles/serviceusage.serviceUsageAdmin), que contém a permissão serviceusage.services.enable. 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:

    Funções necessárias para ativar APIs

    Para ativar as APIs, é necessário ter o papel do IAM de administrador de uso do serviço (roles/serviceusage.serviceUsageAdmin), que contém a permissão serviceusage.services.enable. 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 há 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 a compatibilidade com grupos. Estas seções se aplicam apenas aos clusters do Google Distributed Cloud. Para outros tipos de clusters, como GKE em Google Cloud, GKE na AWS e GKE no Azure, pule para a seção Conceder papéis do IAM a grupos.

No Distributed Cloud, é possível configurar o suporte a grupos para clusters individuais ou para 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

Para o Google Distributed Cloud (somente software) no VMware e bare metal, é possível configurar o suporte a grupos no nível da frota. Se você já tiver configurado a autenticação no nível da frota, como para um provedor de identidade diferente, a autenticação de grupo já estará 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 Serviço de Identidade do GKE

  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 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 provedor de identidade do Google 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 sua 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, modifique esse valor para true.

  3. Opcional: se você precisar acessar o provedor de identidade do Google usando 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 à identidade do Google. 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 Connected, ative o suporte a grupos atualizando o ClientConfig default em cada cluster:

  1. Receba os detalhes da associação 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 assinatura 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 default ClientConfig 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.

    Verifique se o campo internalServer tem o valor https://kubernetes.default.svc.

  4. Opcional: se você precisar acessar o provedor de identidade do Google usando 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 à identidade do Google. 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 da 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