Autentique-se nas APIs Google Cloud a partir de cargas de trabalho de frotas de confiança mista

Esta página mostra como configurar as suas aplicações para autenticar em Google Cloud APIs como a API Compute Engine ou a API AI Platform a partir de frotas que têm um modelo de confiança mista na frota. Se a sua frota tiver um modelo de confiança partilhada na frota, consulte o artigo Autenticar em Google Cloud APIs a partir de cargas de trabalho de frotas de confiança partilhada.

Esta página destina-se a administradores e operadores da plataforma, bem como a engenheiros de segurança que pretendem autenticar programaticamente a partir de cargas de trabalho da frota para Google Cloud APIs. Para saber mais acerca das funções de utilizador e das tarefas de exemplo a que fazemos referência na Google Cloud documentação, consulte Funções e tarefas comuns de utilizador do GKE.

Antes de ler esta página, certifique-se de que conhece os seguintes conceitos:

Acerca da federação de identidade da carga de trabalho da frota para ambientes de confiança mista

A federação de identidade de carga de trabalho do Fleet permite-lhe conceder funções do IAM em Google Cloud APIs e recursos a entidades na sua frota, como cargas de trabalho num espaço de nomes específico. Por predefinição, o projeto anfitrião da frota usa um Workload Identity Pool gerido pela Google para aprovisionar identidades para entidades na frota. No entanto, em ambientes de confiança mista, como frotas multi-inquilinas ou em projetos anfitriões de frotas que executam clusters autónomos, recomendamos que configure um Workload Identity Pool autogerido separado para um subconjunto das suas cargas de trabalho e clusters.

As entidades que usam um Workload Identity Pool autogerido têm identificadores diferentes nas políticas do IAM do que as entidades que usam o Workload Identity Pool gerido pela Google do projeto anfitrião da frota. Isto garante que a concessão de acesso a diretores num espaço de nomes de frota específico não concede acesso involuntariamente a outros diretores que correspondam ao identificador.

Os Workload Identity Pools autogeridos requerem que use âmbitos de equipa. Os âmbitos de equipa permitem-lhe controlar o acesso a subconjuntos de recursos da frota por equipa. Associa âmbitos de equipa específicos a clusters de membros da frota específicos para permitir que essa equipa implemente cargas de trabalho nesses clusters. No âmbito de uma equipa, os membros da equipa só podem implementar cargas de trabalho em namespaces da frota.

A utilização de Workload Identity Pools autogeridos para fornecer identidades para cargas de trabalho no âmbito da equipa tem vantagens como as seguintes:

  • Certifique-se de que as concessões de acesso a entidades em namespaces de frotas não se aplicam involuntariamente a entidades noutros namespaces ou clusters.
  • Configure um conjunto de clusters da frota para obter identidades do Workload Identity Pool autogerido associando-as a um âmbito de equipa e configurando o Workload Identity Pool autogerido como um Fornecedor de identidade nesses clusters.
  • Configure um subconjunto dos clusters associados de um âmbito de equipa para obter identidades do conjunto autogerido. Para tal, configure o conjunto autogerido apenas como um fornecedor de identidade em clusters específicos.

Exemplo de identidade igual num ambiente de confiança mista

Considere o seguinte cenário:

  • Tem dois clusters de membros da frota: frontend-cluster e finance-cluster.
  • Não configurou um Workload Identity Pool autogerido.
  • Cria um âmbito de equipa finance-team e um espaço de nomes da frota finance-ns no âmbito de equipa.
  • Associa o cluster finance-cluster ao âmbito da equipa finance-team.
  • Concede uma função de IAM à finance-sa Kubernetes ServiceAccount no espaço de nomes da frota finance-ns.

Todas as cargas de trabalho que cumprem os seguintes critérios partilham a mesma identidade:

  • Executar no espaço de nomes da frota finance-ns.
  • Use a finance-sa ServiceAccount.

No entanto, se alguém no cluster frontend-cluster criar um espaço de nomes do finance-ns Kubernetes e uma finance-sa ServiceAccount, recebe a mesma identidade que as cargas de trabalho no cluster finance-cluster. Isto deve-se ao facto de toda a frota usar o Workload Identity Pool gerido pela Google do projeto anfitrião da frota e porque o identificador principal não especifica um cluster anfitrião.

Considere as seguintes alterações ao cenário anterior:

  • Configura um Workload Identity Pool autogerido na sua frota.
  • Configura o cluster finance-cluster para obter identidades do conjunto autogerido em vez do conjunto gerido pela Google.
  • Cria uma concessão de função da IAM que especifica o conjunto autogerido no identificador principal, em vez do conjunto gerido pela Google.

As cargas de trabalho executadas no espaço de nomes da frota finance-ns em finance-cluster recebem agora uma identidade do conjunto autogerido. No entanto, as entidades no espaço de nomes do Kubernetes no cluster frontend-cluster continuam a receber identidades do conjunto de identidade do Workload gerido pela Google do projeto anfitrião da frota.finance-ns

Estas alterações resultam nas seguintes vantagens:

  • Pode conceder explicitamente funções a entidades no espaço de nomes finance-ns fleet.
  • As entidades no cluster frontend-cluster não podem obter o mesmo acesso porque as identidades no cluster frontend-cluster provêm do pool de identidades de carga de trabalho gerido pela Google.

Antes de começar

  • Certifique-se de que tem as seguintes ferramentas de linha de comandos instaladas:

    • A versão mais recente da CLI do Google Cloud, que inclui o gcloud, a ferramenta de linha de comandos para interagir com Google Cloud.
    • kubectl

    Se estiver a usar o Cloud Shell como ambiente de shell para interagir com o Google Cloud, estas ferramentas são instaladas automaticamente.

  • Certifique-se de que inicializou a CLI gcloud para utilização com o seu projeto.

Requisitos

Tem de usar funcionalidades de gestão de equipas de frotas, como âmbitos de equipas e espaços de nomes de frotas na sua frota. As instruções nesta página mostram como configurar um exemplo de âmbito da equipa e espaço de nomes da frota.

Prepare os seus clusters

Antes de as aplicações na sua frota poderem receber uma identidade federada, os clusters em que são executadas têm de estar registados na sua frota e configurados corretamente para usar a Federação de identidades de cargas de trabalho da frota. As secções seguintes descrevem como configurar a Federação de identidades de cargas de trabalho da frota para diferentes tipos de clusters.

GKE

Para clusters do GKE, faça o seguinte:

  1. Ative a Workload Identity Federation para o GKE no seu cluster do Google Kubernetes Engine, se ainda não estiver ativada.
  2. Registe o cluster na frota.

Também pode ativar a federação de identidade da carga de trabalho para o GKE durante o processo de criação do cluster e registo da frota.

Clusters fora de Google Cloud

Os seguintes tipos de clusters ativam automaticamente a Federação de identidades de cargas de trabalho e são registados na sua frota durante a criação do cluster:

  • Google Distributed Cloud (apenas software) no VMware
  • Google Distributed Cloud (apenas software) em bare metal
  • GKE no AWS
  • GKE no Azure

Clusters anexados

Os clusters anexados do EKS e do AKS registados através da API GKE Multi-Cloud são registados com a Workload Identity Federation da frota ativada por predefinição. Outros clusters anexados podem ser registados com a Workload Identity Federation da frota ativada se cumprirem os requisitos necessários. Siga as instruções para o seu tipo de cluster em Registar um cluster.

Configure um Workload Identity Pool do IAM

Nesta secção, cria um novo Workload Identity Pool do IAM no projeto de anfitrião da frota e concede ao agente do serviço da frota acesso ao novo Workload Identity Pool.

  1. Crie um Workload Identity Pool:

    gcloud iam workload-identity-pools create POOL_NAME \
    --location=global \
    --project=POOL_HOST_PROJECT_ID \
    --mode=TRUST_DOMAIN

    Substitua o seguinte:

    • POOL_NAME: o nome do novo Workload Identity Pool.
    • POOL_HOST_PROJECT_ID: o ID do projeto no qual quer criar o Workload Identity Pool autogerido. Pode usar qualquer Google Cloud projeto, incluindo o projeto de anfitrião da frota.

  2. Conceda a função de administrador do Workload Identity Pool do IAM (roles/iam.workloadIdentityPoolAdmin) no novo Workload Identity Pool ao agente do serviço da frota:

    gcloud iam workload-identity-pools add-iam-policy-binding POOL_NAME \
    --project=POOL_HOST_PROJECT_ID \
    --location=global \
    --member=serviceAccount:service-FLEET_HOST_PROJECT_NUMBER@gcp-sa-gkehub.iam.gserviceaccount.com \
    --role=roles/iam.workloadIdentityPoolAdmin \
    --condition=None

    Substitua FLEET_HOST_PROJECT_NUMBER pelo número do projeto de alojamento da frota.

Adicione o conjunto autogerido à configuração da frota

Nesta secção, ativa os pools autogeridos com a federação de identidade da força de trabalho da frota e adiciona o pool que criou à configuração da frota. Esta secção também fornece instruções para criar um novo âmbito de equipa e um espaço de nomes da frota. Se a sua frota já tiver âmbitos de equipa e espaços de nomes da frota configurados, ignore esses passos.

  1. Ative a federação de identidade da carga de trabalho da frota ao nível da frota:

    gcloud beta container fleet workload-identity enable \
  --project=FLEET_HOST_PROJECT_ID

    Substitua FLEET_HOST_PROJECT_ID pelo ID do projeto do projeto de anfitrião da sua frota.

  2. Adicione o Workload Identity Pool autogerido à configuração da frota:

    gcloud beta container fleet workload-identity scope-tenancy-pool set POOL_NAME

    Substitua POOL_NAME pelo nome do seu Workload Identity Pool autogerido. Este valor tem a seguinte sintaxe:

    POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog

  3. Crie um novo âmbito de equipa. Se tiver um âmbito de equipa e um espaço de nomes de frota existentes, avance para a secção Valide a configuração do Workload Identity Pool.

    gcloud container fleet scopes create SCOPE_NAME

    Substitua SCOPE_NAME pelo nome do novo âmbito da equipa.

  4. Crie um novo espaço de nomes da frota no âmbito da equipa:

    gcloud container fleet scopes namespaces create NAMESPACE_NAME \
    --scope=SCOPE_NAME

    Substitua NAMESPACE_NAME pelo nome do novo espaço de nomes do Fleet.

  5. Associe um cluster na sua frota ao âmbito da equipa:

    gcloud container fleet memberships bindings create BINDING_NAME \
    --membership=FLEET_CLUSTER_NAME \
    --location=global \
    --scope=SCOPE_NAME

    Substitua o seguinte:

    • BINDING_NAME: o nome da nova associação de subscrição.
    • FLEET_CLUSTER_NAME: o nome do cluster da frota existente a associar ao âmbito da equipa.

Valide a configuração do Workload Identity Pool

Nesta secção, garante que a configuração do Workload Identity Pool autogerido foi bem-sucedida.

  1. Descreva a configuração de associação à frota:

    gcloud container fleet memberships describe FLEET_CLUSTER_NAME \
    --location=global

    Substitua FLEET_CLUSTER_NAME pelo nome de um cluster de frota existente associado a qualquer âmbito de equipa na sua frota.

    O resultado é semelhante ao seguinte:

    authority:
...
  scopeTenancyIdentityProvider: https://gkehub.googleapis.com/projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/FLEET_CLUSTER_NAME
  scopeTenancyWorkloadIdentityPool: POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog
  workloadIdentityPool: FLEET_HOST_PROJECT_ID.svc.id.goog
...

    Este resultado deve conter os seguintes campos:

    • scopeTenancyIdentityProvider: o fornecedor de identidade para cargas de trabalho que são executadas em espaços de nomes de frotas nos âmbitos da equipa. O valor é um identificador de recurso para o seu cluster.
    • scopeTenancyWorkloadIdentityPool: o Workload Identity Pool a partir do qual as cargas de trabalho nos espaços de nomes da frota nos âmbitos da equipa recebem identificadores. O valor é o seu Workload Identity Pool autogerido, com o formato POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog.
    • workloadIdentityPool: o nome do Workload Identity Pool gerido pela Google do projeto anfitrião da frota, a partir do qual todas as outras cargas de trabalho na frota recebem identidades por predefinição.

  2. Opcional: verifique se o seu Workload Identity Pool tem um espaço de nomes com o mesmo nome que o espaço de nomes da sua frota:

    gcloud iam workload-identity-pools namespaces list \
    --workload-identity-pool=POOL_NAME \
    --location=global

    O resultado é semelhante ao seguinte:

    ---
description: Fleet namespace NAMESPACE_NAME
name: projects/FLEET_HOST_PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_NAME/namespaces/NAMESPACE_NAME
state: ACTIVE

A sua frota pode agora usar o Workload Identity Pool autogerido para obter identidades para cargas de trabalho executadas em espaços de nomes da frota. Para começar a usar o conjunto autogerido, configure a forma como clusters específicos recebem identidades, conforme descrito na secção seguinte.

Faça com que as cargas de trabalho usem pools autogeridos para identidades

Para que as cargas de trabalho usem o pool autogerido, configure espaços de nomes específicos da frota nos clusters membros da frota através de um ConfigMap do Kubernetes. Esta configuração por cluster e por espaço de nomes permite-lhe reduzir ainda mais o âmbito das concessões de acesso de espaços de nomes de frotas inteiros para cargas de trabalho executadas em espaços de nomes de frotas específicos em clusters específicos.

  1. Estabeleça ligação ao cluster membro da frota:

    gcloud container clusters get-credentials FLEET_CLUSTER_NAME \
    --project=CLUSTER_PROJECT_ID \
    --location=CLUSTER_LOCATION

    Substitua o seguinte:

    • FLEET_CLUSTER_NAME: o nome de um cluster membro da frota que já está associado a um âmbito da equipa.
    • CLUSTER_PROJECT_ID: o ID do projeto do projeto do cluster.
    • CLUSTER_LOCATION: a localização do cluster.

  2. Obtenha o nome completo do Workload Identity Pool autogerido. Precisa dele mais tarde.

    kubectl get membership membership -o json | jq -r ".spec.scope_tenancy_workload_identity_pool"

    O resultado é semelhante ao seguinte:

    POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog

  3. Obtenha o nome do fornecedor de identidade para âmbitos de equipa. Precisar dele mais tarde.

    kubectl get membership membership -o json | jq -r ".spec.scope_tenancy_identity_provider"

    O resultado é semelhante ao seguinte:

    https://gkehub.googleapis.com/projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/FLEET_CLUSTER_NAME

  4. Num editor de texto, guarde o seguinte manifesto YAML para um ConfigMap como self-managed-pool.yaml:

    kind: ConfigMap
apiVersion: v1
metadata:
  namespace: NAMESPACE_NAME
  name: google-application-credentials
data:
  config: |
    {
      "type": "external_account",
      "audience": "identitynamespace:SELF_MANAGED_POOL_FULL_NAME:IDENTITY_PROVIDER",
      "subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
      "token_url": "https://sts.googleapis.com/v1/token",
      "credential_source": {
        "file": "/var/run/secrets/tokens/gcp-ksa/token"
      }
    }

    Substitua o seguinte:

    • NAMESPACE_NAME: o nome do espaço de nomes da frota.
    • SELF_MANAGED_POOL_FULL_NAME: o nome completo do Workload Identity Pool autogerido a partir do resultado dos passos anteriores nesta secção. Por exemplo, example-pool.global.1234567890.workload.id.goog.
    • IDENTITY_PROVIDER: o nome do fornecedor de identidade da saída dos passos anteriores nesta secção. Por exemplo, https://gkehub.googleapis.com/projects/1234567890/locations/global/memberships/example-cluster.

  5. Implemente o ConfigMap no seu cluster:

    kubectl create -f self-managed-pool.yaml

A implementação do ConfigMap indica ao GKE que as cargas de trabalho nesse espaço de nomes devem usar o Workload Identity Pool autogerido para obter identidades.

Conceda funções de IAM a principais

Nesta secção, cria uma conta de serviço do Kubernetes num espaço de nomes da frota e concede uma função de IAM à conta de serviço. Os pods que usam esta ServiceAccount podem, então, aceder aos recursos nos quais concede a função. Google Cloud

  1. Crie uma conta de serviço do Kubernetes no espaço de nomes da sua frota:

    kubectl create serviceaccount SERVICEACCOUNT_NAME \
    --namespace=NAMESPACE_NAME

    Substitua o seguinte:

    • SERVICEACCOUNT_NAME: o nome da nova ServiceAccount.
    • NAMESPACE_NAME: o nome do espaço de nomes da frota.

  2. Conceda uma função IAM à conta de serviço. O comando de exemplo seguinte concede a função Storage Object Viewer (roles/storage.objectViewer) num contentor à ServiceAccount:

    gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME \
    --member=principal://iam.googleapis.com/projects/FLEET_HOST_PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog/subject/ns/NAMESPACE_NAME/sa/SERVICEACCOUNT_NAME \
    --role=roles/storage.objectViewer \
    --condition=None

O comando member contém o identificador principal da nova ServiceAccount que criou. Os pedidos que as suas cargas de trabalho enviam para as APIs usam um token de acesso federado. Google Cloud Este token de acesso federado inclui o identificador principal da entidade que envia o pedido. Se o principal numa política de permissão que concede uma função no recurso de destino corresponder ao principal no token de acesso federado, a autenticação e a autorização podem continuar.

Implemente cargas de trabalho que usam o pool autogerido

Os manifestos do Kubernetes que aplica no espaço de nomes da frota têm de ser configurados para obter identidades do conjunto autogerido. As cargas de trabalho que implementar e que precisam de chamar Google Cloud APIs devem incluir os seguintes campos:

  • metadata.namespace: o nome do espaço de nomes da frota.
  • spec.serviceAccountName: o nome da ServiceAccount do Kubernetes no namespace da frota.
  • spec.containers.env: uma variável de ambiente denominada GOOGLE_APPLICATION_CREDENTIALS que indica o caminho para o ficheiro de credenciais predefinidas da aplicação (ADC).
  • spec.containers.volumeMounts: um volume só de leitura que permite ao contentor usar o token de portador para a ServiceAccount.
  • spec.volumes: um volume projetado que monta um token ServiceAccount no Pod. O público-alvo do token é o Workload Identity Pool autogerido. O ConfigMap que contém a configuração da federação de identidade da força de trabalho da frota é uma origem para o volume.

Para ver um exemplo de um ficheiro de manifesto configurado corretamente, consulte a secção Validar a autenticação a partir de uma carga de trabalho.

Valide a autenticação a partir de uma carga de trabalho

Esta secção fornece instruções opcionais para verificar se configurou corretamente o conjunto do Workload Identity autogerido listando o conteúdo de um exemplo de contentor do Cloud Storage. Cria um contentor, concede uma função no contentor a uma ServiceAccount num espaço de nomes da frota e implementa um pod para tentar aceder ao contentor.

  1. Crie um contentor do Cloud Storage:

    gcloud storage buckets create gs://FLEET_HOST_PROJECT_ID-workload-id-bucket \
    --location=LOCATION \
    --project=FLEET_HOST_PROJECT_ID

  2. Conceda a função roles/storage.objectViewer no contentor à conta de serviço no espaço de nomes da frota:

    gcloud storage buckets add-iam-policy-binding gs://FLEET_HOST_PROJECT_ID-workload-id-bucket \
    --condition=None \
    --role=roles/storage.objectViewer \
    --member=principal://iam.googleapis.com/projects/FLEET_PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog/subject/ns/NAMESPACE_NAME/sa/SERVICEACCOUNT_NAME

    Substitua o seguinte:

    • FLEET_HOST_PROJECT_NUMBER: o número do projeto do seu projeto anfitrião da frota.
    • POOL_NAME: o nome do seu conjunto do Workload Identity autogerido.
    • NAMESPACE_NAME: o nome do espaço de nomes da frota no qual quer executar o pod.
    • SERVICEACCOUNT_NAME: o nome da ServiceAccount do Kubernetes que o pod deve usar.

  3. Guarde o seguinte manifesto como pod-bucket-access.yaml:

    apiVersion: v1
kind: Pod
metadata:
  name: bucket-access-pod
  namespace:  NAMESPACE_NAME
spec:
  serviceAccountName: SERVICEACCOUNT_NAME
  containers:
  - name: sample-container
    image: google/cloud-sdk:slim
    command: ["sleep","infinity"]
    env:
    - name: GOOGLE_APPLICATION_CREDENTIALS
      value: /var/run/secrets/tokens/gcp-ksa/google-application-credentials.json
    volumeMounts:
    - name: gcp-ksa
      mountPath: /var/run/secrets/tokens/gcp-ksa
      readOnly: true
  volumes:
  - name: gcp-ksa
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          path: token
          audience: POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog
          expirationSeconds: 172800
      - configMap:
          name: my-cloudsdk-config
          optional: false
          items:
          - key: "config"
            path: "google-application-credentials.json"

    Substitua o seguinte:

    • NAMESPACE_NAME: o nome do espaço de nomes da frota no qual quer executar o pod.
    • SERVICEACCOUNT_NAME: o nome da ServiceAccount do Kubernetes que o pod deve usar.
    • POOL_NAME: o nome do seu conjunto do Workload Identity autogerido.
    • FLEET_HOST_PROJECT_NUMBER: o número do projeto do seu projeto anfitrião da frota.

  4. Implemente o pod no seu cluster:

    kubectl apply -f pod-bucket-access.yaml

  5. Abra uma sessão de shell no pod:

    kubectl exec -it bucket-access-pod -n NAMESPACE_NAME -- /bin/bash

  6. Experimente listar objetos no contentor:

    curl -X GET -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
    "https://storage.googleapis.com/storage/v1/b/FLEET_HOST_PROJECT_ID-workload-id-bucket/o"

    O resultado é o seguinte:

    {
  "kind": "storage#objects"
}

Opcionalmente, pode validar se um espaço de nomes e uma ServiceAccount semelhantes num cluster membro da frota diferente não conseguem afirmar a mesma identidade. Num cluster que use a Workload Identity Federation da frota, mas não tenha um espaço de nomes da frota ou uma configuração de pool autogerida, siga estes passos:

  1. Crie um novo espaço de nomes do Kubernetes com o mesmo nome do espaço de nomes da frota no qual configurou o Workload Identity Pool autogerido.
  2. Crie uma nova conta de serviço do Kubernetes com o mesmo nome da conta de serviço à qual concedeu uma função do IAM nas secções anteriores.

  3. Implemente um pod que use o mesmo ServiceAccount e espaço de nomes, mas para o qual o campo spec.volumes.projected.sources.serviceAccountToken especifica o conjunto de identidade da carga de trabalho gerido pela Google. Este conjunto tem a seguinte sintaxe:

    FLEET_HOST_PROJECT_ID.svc.id.goog

  4. Tente aceder ao contentor do Cloud Storage a partir de uma sessão de shell no pod.

O resultado deve ser um erro 401: Unauthorized, porque o identificador principal do pod que usa o Workload Identity Pool gerido pela Google é diferente do identificador principal do pod que usa o Workload Identity Pool autogerido.

O que se segue?