Acessar clusters particulares do Google Kubernetes Engine em pools particulares do Cloud Build usando o serviço de identidade para GKE

Criar um cluster do GKE particular

1. No Cloud Shell, crie um cluster do GKE sem acesso de cliente ao endpoint público do plano de controle e com o Identity Service para GKE instalado:

   gcloud container clusters create CLUSTER  \
     --enable-identity-service \
     --enable-ip-alias \
     --enable-master-authorized-networks \
     --enable-private-endpoint \
     --enable-private-nodes \
     --master-ipv4-cidr CONTROL_PLANE_CIDR \
     --network NETWORK\
     --release-channel regular \
     --scopes cloud-platform \
     --subnetwork SUBNET \
     --tags NODE_TAGS \
     --workload-pool PROJECT_ID.svc.id.goog \
     --zone ZONE
   

   Substitua:

   • CLUSTER: o nome do cluster. Neste tutorial, use private-cluster.
   • CONTROL_PLANE_CIDR: o intervalo de endereços IP do plano de controle. Ele precisa ter um prefixo /28. Neste tutorial, use 172.16.0.32/28.
   • NETWORK: a rede VPC a que o plano de controle se conecta. Neste tutorial, use default.
   • SUBNET: a sub-rede a que o plano de controle do cluster do GKE se conecta. A sub-rede precisa pertencer à rede VPC especificada por NETWORK. Neste tutorial, use default.
   • NODE_TAGS: uma lista separada por vírgulas de tags de rede a serem aplicadas aos nós. Neste tutorial, use private-cluster-node.
   • PROJECT_ID: o ID do projeto do Google Cloud .
   • ZONE: a zona do cluster do GKE. Neste tutorial, use us-central1-f.

   Observe o seguinte sobre o comando:

   • A flag --enable-identity-service ativa o serviço de identidade para o GKE no cluster. No seu ambiente, é possível ativar o serviço de identidade para o GKE em um cluster atual.

   • A flag --enable-private-endpoint configura o plano de controle para ser acessível somente usando endereços IP internos.

   • A flag --enable-private-nodes configura os nós do cluster para ter apenas endereços IP internos.

   • As flags --enable-master-authorized-networks e --enable-private-nodes permitem o acesso ao servidor da API apenas das redes particulares especificadas pela flag --network.

   • A flag opcional --workload-pool ativa a federação de identidade da carga de trabalho para o GKE. Ele não é necessário para este tutorial.

2. Adicione uma regra de firewall que permita que o plano de controle do cluster do GKE se conecte ao webhook de admissão de validação para recursos ClientConfig:

   gcloud compute firewall-rules create allow-control-plane-clientconfig-webhook \
     --allow tcp:15000 \
     --network NETWORK\
     --source-ranges CONTROL_PLANE_CIDR\
     --target-tags NODE_TAGS
   

   ClientConfig é um tipo de recurso personalizado (CRD) do Kubernetes que o Identity Service para GKE usa para configurar como interagir com provedores de identidade.

Registrar o Identity Service para GKE como um aplicativo cliente OAuth 2.0

Nesta seção, você vai registrar o Identity Service para GKE como um aplicativo cliente usando o sistema de autenticação OAuth 2.0 do Google.

1. Abra a página Credenciais no console do Google Cloud .

   Abra a página Credenciais

2. Clique em Criar credenciais.

3. Selecione ID do cliente OAuth.

   Se a tela de consentimento ainda não tiver sido configurada para o projeto do Google Cloud, clique em Configurar tela de consentimento. Siga a documentação sobre como configurar a tela de consentimento. Para este tutorial, defina os seguintes valores:

   • O Tipo de usuário pode ser Interno ou Externo. Neste tutorial, selecione "Interno".
   • Os valores de Nome do app, E-mail de suporte ao usuário e Dados de contato do desenvolvedor são obrigatórios e podem ser de qualquer valor.
   • Não é necessário adicionar escopos para este tutorial.

   Quando terminar de configurar a tela de consentimento, clique em "Voltar ao painel" e comece de novo na etapa 1 do procedimento atual.

4. Na lista Tipo de aplicativo, selecione Aplicativo da Web.

5. No campo Nome, insira um nome para o ID do cliente. Neste tutorial, use Identity Service for GKE.

6. Clique em Criar.

   Uma caixa de diálogo será exibida. Copie o valor de Seu ID do cliente. Você vai precisar dele mais adiante neste procedimento.

7. Clique em OK para fechar a caixa de diálogo.

8. No Cloud Shell, crie um diretório no diretório principal chamado cloud-build-private-pools-gke-tutorial e acesse esse diretório:

   mkdir -p ~/cloud-build-private-pools-gke-tutorial cd ~/cloud-build-private-pools-gke-tutorial

9. No novo diretório, crie um arquivo YAML chamado client-config-patch.yaml com valores que você vai precisar depois para corrigir o recurso Identity Service para GKE ClientConfig:

   cat << EOF > client-config-patch.yaml
   spec:
     authentication:
     - name: google-oidc
       oidc:
         clientID: CLIENT_ID
         cloudConsoleRedirectURI: https://console.cloud.google.com/kubernetes/oidc
         extraParams: prompt=consent,access_type=offline
         issuerURI: https://accounts.google.com
         kubectlRedirectURI: http://localhost:10000/callback
         scopes: email
         userClaim: email
         userPrefix: '-'
   EOF
   

   Substitua CLIENT_ID pelo ID do cliente OAuth da etapa anterior.

   Observe o seguinte sobre o patch:

   • Os tokens de ID emitidos pelo sistema de autenticação OAuth 2.0 do Google contêm um identificador numérico exclusivo na declaração sub (assunto). Usar esse identificador opaco em vinculações de papéis dificulta a identificação do assunto de uma vinculação de papel. Portanto, esse patch configura o serviço de identidade para o GKE a fim de usar a declaração de e-mail dos tokens de ID para identificar usuários em vez de usar a declaração sub padrão.

   • O escopo de e-mail é adicionado para que os tokens de ID emitidos incluam a declaração de e-mail.

   • Os campos cloudConsoleRedirectURI, extraParams, kubectlRedirectURI e escopos são usados quando os desenvolvedores se autenticam no cluster usando o serviço de identidade para o GKE. Elas não são usadas quando as contas de serviço do Google se autenticam no cluster. O campo kubectlRedirectURI é obrigatório.

   • O campo userPrefix é um prefixo para usuários que fazem a autenticação usando o provedor de identidade configurado. O valor '-' significa que não há prefixo.

   • O campo spec.authentication é uma matriz. É possível usar vários provedores de identidade do OpenID Connect com o serviço de identidade para o GKE. Por exemplo, você pode usar o Google como provedor de identidade para autenticar contas de serviço do Google e outro provedor para autenticar desenvolvedores.

   Para mais informações sobre os campos nessa configuração, consulte Usar provedores de identidade externos para autenticar no GKE.

Criar uma conta de serviço do Google para configurar o serviço de identidade para o GKE

1. No Cloud Shell, crie uma conta de serviço do Google:

   gcloud iam service-accounts create ISG_GSA \
     --display-name "Configure Identity Service for GKE"
   

   Substitua ISG_GSA pelo nome que você quer usar para a conta de serviço do Google. Neste tutorial, use identity-service-for-gke.

   Atribua essa conta de serviço do Google a uma instância de VM do Compute Engine para configurar o Identity Service para GKE e o controle de acesso baseado em função do Kubernetes no cluster.

2. Conceda o papel de administrador do Kubernetes Engine no projeto à conta de serviço do Google:

   gcloud projects add-iam-policy-binding PROJECT_ID \
     --member serviceAccount:ISG_GSA@PROJECT_ID.iam.gserviceaccount.com \
     --role roles/container.admin
   

   Esse papel fornece as permissões necessárias para realizar as seguintes tarefas neste tutorial:

   • Configure as configurações do serviço de identidade para o GKE em clusters no projeto.
   • Crie vinculações de papéis e vinculações de papéis de cluster no cluster.

Configurar o serviço de identidade para o GKE

Para configurar o serviço de identidade para o GKE, você precisa ter acesso ao plano de controle do cluster. Neste tutorial, você cria uma instância de VM do Compute Engine para acessar o plano de controle.

Você precisa ter acesso SSH à instância de VM. Para ativar o acesso SSH autenticado e autorizado de fora da rede VPC à instância de VM, use o encaminhamento TCP com o Identity-Aware Proxy (IAP). Esse recurso permite o acesso SSH sem exigir que a instância de VM tenha um endereço IP público.

1. No Cloud Shell, crie uma regra de firewall que permita o acesso SSH usando o encaminhamento TCP do IAP para qualquer instância de VM com a tag de rede ssh-iap:

   gcloud compute firewall-rules create allow-ssh-ingress-from-iap \
     --allow tcp:22 \
     --description "Allow SSH tunneling using Identity-Aware Proxy" \
     --network NETWORK \
     --source-ranges 35.235.240.0/20 \
     --target-tags ssh-iap
   

   O intervalo de origem contém os endereços IP que o IAP usa para o encaminhamento de TCP.

2. Crie uma instância de VM do Compute Engine na mesma rede VPC que o cluster do GKE:

   gcloud compute instances create VM \
     --metadata enable-oslogin=TRUE \
     --network NETWORK \
     --no-address \
     --scopes cloud-platform,userinfo-email \
     --service-account ISG_GSA@PROJECT_ID.iam.gserviceaccount.com \
     --subnet SUBNET  \
     --tags ssh-iap \
     --zone ZONE
   

   Substitua VM pelo nome que você quer usar para a instância de VM. Neste tutorial, use identity-service-for-gke-configuration.

   Observe o seguinte sobre o comando acima:

   • A flag --service-account anexa a conta de serviço do Google à instância de VM.

   • O escopo cloud-platform é necessário para acessar a API Service Account Credentials.

   • O escopo userinfo-email é útil ao criar uma instância de VM para gerenciar o controle de acesso baseado em papéis do Kubernetes. Ele é opcional para este tutorial.

   • A flag --no-address significa que a instância de VM foi criada sem um endereço IP externo.

   • O valor opcional de metadados da instância enable-oslogin ativa o Login do SO na instância de VM. O Login do SO permite gerenciar o acesso SSH a instâncias de VM usando o IAM.

3. Copie o arquivo de patch ClientConfig para a instância de VM:

   gcloud compute scp client-config-patch.yaml VM:~ --tunnel-through-iap --zone ZONE
   

   A flag --tunnel-through-iap instrui gcloud a criar um túnel para a conexão pelo IAP.

4. Conecte-se à instância de VM usando o SSH.

   gcloud compute ssh VM --tunnel-through-iap --zone ZONE
   

   Execute o restante dos comandos desta seção na sessão do SSH.

5. Instale a ferramenta de linha de comando kubectl e o binário gke-gcloud-auth-plugin na instância de VM:

   sudo apt-get install -y kubectl google-cloud-sdk-gke-gcloud-auth-plugin
   

6. Busque credenciais para o cluster do GKE:

   export USE_GKE_GCLOUD_AUTH_PLUGIN=True
   gcloud container clusters get-credentials CLUSTER --zone ZONE
   

7. Faça o patch do recurso ClientConfig padrão:

   kubectl patch clientconfig default \
       --namespace kube-public \
       --patch-file client-config-patch.yaml \
       --type merge
   

8. Extraia o campo certificateAuthorityData do recurso ClientConfig padrão corrigido e armazene-o em um arquivo chamado certificateAuthorityData.pem:

   kubectl get clientconfig default \
        --namespace kube-public \
        --output jsonpath='{.spec.certificateAuthorityData}' \
        | base64 --decode > certificateAuthorityData.pem
   

9. Extraia o campo do servidor do recurso ClientConfig padrão corrigido e armazene-o em um arquivo chamado server.txt:

   kubectl get clientconfig default \
        --namespace kube-public \
        --output jsonpath='{.spec.server}' > server.txt
   

10. Saia da sessão SSH:

    exit
    

(Opcional) Verificar a configuração do cluster

Antes de continuar, verifique se o serviço de identidade para o GKE foi configurado corretamente no cluster. Para verificar a configuração, use a conta de serviço do Google anexada à instância de VM para autenticar o cluster usando o serviço de identidade do GKE.

1. No Cloud Shell, conceda o papel Criador do token de identidade do OpenID Connect da conta de serviço à própria conta de serviço do Google:

   gcloud iam service-accounts add-iam-policy-binding \
     ISG_GSA@PROJECT_ID.iam.gserviceaccount.com \
     --member serviceAccount:ISG_GSA@PROJECT_ID.iam.gserviceaccount.com \
     --role roles/iam.serviceAccountOpenIdTokenCreator
   

   Esse papel fornece a permissão iam.serviceAccounts.getOpenIdToken, que é necessária para solicitar tokens de ID para a conta de serviço na API Service Account Credentials.

2. Conecte-se à instância de VM usando o SSH.

   gcloud compute ssh VM --tunnel-through-iap --zone ZONE
   

   Execute o restante dos comandos desta seção na sessão do SSH.

3. Solicite um token de acesso do OAuth 2.0 do servidor de metadados para a conta de serviço do Google anexada à instância de VM, usando o ID do cliente OAuth como a declaração aud (público-alvo) solicitada:

   ACCESS_TOKEN=$(curl --silent --header "Metadata-Flavor: Google" \
   http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token \
          | python3 -c 'import json, sys; print(json.load(sys.stdin).get("access_token"))')
   

   O corpo da resposta do servidor de metadados é um documento JSON. O comando usa um script Python inline para extrair o campo access_token do corpo da resposta.

4. Solicite um token de ID da API Service Account Credentials para a conta de serviço do Google anexada à instância de VM:

   ID_TOKEN=$(curl --silent --request POST \
       --data '{"audience": "CLIENT_ID", "includeEmail": true}' \
       --header "Authorization: Bearer $ACCESS_TOKEN" \
       --header "Content-Type: application/json; charset=utf-8" \
   "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/ISG_GSA@PROJECT_ID.iam.gserviceaccount.com:generateIdToken" \
          | python3 -c 'import json, sys; print(json.load(sys.stdin).get("token"))')
   

   Observe o seguinte sobre o comando acima:

   • O campo audience no JSON do corpo da solicitação especifica a declaração aud (público-alvo) solicitada do token de ID.
   • O token de acesso da etapa anterior é usado para autenticar a API.

5. Confira as declarações no token de ID:

   echo $ID_TOKEN \
       | cut -d. -f2 \
       | base64 --decode --ignore-garbage 2> /dev/null \
       | python3 -m json.tool
   

   Verifique se a declaração email contém o endereço de e-mail da conta de serviço do Google.

6. Use o token de ID para autenticar no plano de controle usando o serviço de identidade do GKE:

   kubectl get namespaces \
       --certificate-authority certificateAuthorityData.pem \
       --server $(cat server.txt) \
       --token $ID_TOKEN
   

   A saída será assim:

     Error from server (Forbidden): namespaces is forbidden: User "ISG_GSA@PROJECT_ID.iam.gserviceaccount.com" cannot list resource "namespaces" in API group "" at the cluster scope
   

   É esperado que você o receba. Embora a conta de serviço do Google tenha recebido permissões do IAM em clusters do GKE no projeto, elas não se aplicam quando você faz a autenticação usando o Identity Service para GKE. Em vez disso, configure o acesso usando o controle de acesso baseado em papéis (RBAC) do Kubernetes.

7. Crie uma vinculação de papel de cluster que conceda o papel de cluster view à conta de serviço do Google quando ela se autenticar no cluster usando o provedor OpenID Connect do Google:

   kubectl create clusterrolebinding ISG_GSA-cluster-view \
       --clusterrole view \
       --user ISG_GSA@PROJECT_ID.iam.gserviceaccount.com
   

   Se você definir um valor userPrefix diferente de - no ClientConfig do seu ambiente, adicione o prefixo ao valor da flag --user neste comando.

8. Acesse o cluster do GKE usando o Identity Service para GKE:

   kubectl get namespaces \
       --certificate-authority certificateAuthorityData.pem \
       --server $(cat server.txt) \
       --token $ID_TOKEN
   

   A saída será assim:

   NAME                      STATUS   AGE
   anthos-identity-service   Active   1h
   default                   Active   1h
   kube-node-lease           Active   1h
   kube-public               Active   1h
   kube-system               Active   1h
   

9. Saia da sessão SSH:

   exit
   

Criar um contexto para a ferramenta kubectl

O comando kubectl pode usar um arquivo kubeconfig para configurar o acesso aos clusters. Um arquivo kubeconfig contém um ou mais contextos. Cada contexto tem um nome e, opcionalmente, inclui informações de conectividade do cluster, credenciais usadas para autenticar no cluster e um namespace padrão.

Nesta seção, você vai criar um arquivo kubeconfig com um contexto. O contexto inclui detalhes de conectividade do proxy do Identity Service para GKE do seu cluster. Não adicione credenciais de usuário ao arquivo kubeconfig.

1. No Cloud Shell, copie os arquivos que contêm os dados da autoridade certificadora e o URL do servidor da instância de VM para o diretório atual:

   gcloud compute scp VM:~/certificateAuthorityData.pem VM:~/server.txt . \
       --tunnel-through-iap --zone ZONE
   

2. Crie um contexto e uma configuração de cluster que você usará mais tarde para se conectar ao cluster do GKE no Cloud Build:

   kubectl config set-context private-cluster \
       --cluster private-cluster \
       --kubeconfig kubeconfig
   

   A flag --kubeconfig cria o contexto e a configuração do cluster em um novo arquivo chamado kubeconfig no diretório atual.

   Esse comando usa o nome do cluster do GKE como o nome da configuração do cluster para o contexto. No seu próprio ambiente, você pode usar um nome de configuração de cluster diferente no contexto.

3. Defina o campo certificateAuthorityData na configuração do cluster:

   kubectl config set-cluster private-cluster \
       --certificate-authority certificateAuthorityData.pem \
       --embed-certs \
       --kubeconfig kubeconfig
   

4. Defina o campo server na configuração do cluster:

   kubectl config set-cluster private-cluster \
       --kubeconfig kubeconfig \
       --server $(cat server.txt)
   

Criar uma conta de serviço do Google para o Cloud Build

1. No Cloud Shell, crie uma conta de serviço do Google para executar builds no pool privado do Cloud Build:

   gcloud iam service-accounts create CB_GSA \
     --description "Runs builds on Cloud Build private pools" \
     --display-name "Cloud Build private pool"
   

   Substitua CB_GSA pelo nome que você quer usar para a conta de serviço do Google. Neste tutorial, use cloud-build-private-pool.

2. Conceda o papel de conta de serviço do Cloud Build no projeto à conta de serviço do Google:

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member serviceAccount:CB_GSA@PROJECT_ID.iam.gserviceaccount.com \
       --role roles/cloudbuild.builds.builder
   

   Esse papel fornece as permissões padrão da conta de serviço do Cloud Build gerenciada pelo Google.

3. Conceda o papel Criador do token de identidade do OpenID Connect da conta de serviço na conta de serviço do Google para a própria conta de serviço:

   gcloud iam service-accounts add-iam-policy-binding \
       CB_GSA@PROJECT_ID.iam.gserviceaccount.com \
       --member serviceAccount:CB_GSA@PROJECT_ID.iam.gserviceaccount.com \
       --role roles/iam.serviceAccountOpenIdTokenCreator
   

   Esse papel fornece a permissão iam.serviceAccounts.getOpenIdToken, que é necessária para solicitar tokens de ID para a conta de serviço na API Service Account Credentials.

4. Conecte-se à instância de VM usando o SSH.

   gcloud compute ssh VM --tunnel-through-iap --zone ZONE
   

   Execute o restante dos comandos desta seção na sessão do SSH.

5. Na sessão SSH, crie uma vinculação de função de cluster do Kubernetes que conceda a função de cluster cluster-admin à conta de serviço do Google quando ela se autenticar no cluster usando o provedor OpenID Connect do Google:

   kubectl create clusterrolebinding CB_GSA-cluster-admin \
       --clusterrole cluster-admin \
       --user CB_GSA@PROJECT_ID.iam.gserviceaccount.com
   

   O papel de cluster cluster-admin concede permissões abrangentes em todo o cluster. No seu ambiente, é possível usar uma função de cluster que forneça apenas as permissões necessárias para as tarefas realizadas pelo Cloud Build. Também é possível usar vinculações de papéis para conceder permissões apenas a namespaces específicos.

   Se você definir um userPrefix no ClientConfig do seu ambiente, adicione esse prefixo ao valor da flag --user neste comando.

6. Saia da sessão SSH:

   exit
   

Criar um pool particular do Cloud Build

1. No Cloud Shell, aloque um intervalo de endereços IP na sua rede VPC para a conexão com o pool particular:

   gcloud compute addresses create RESERVED_RANGE_NAME \
   --addresses RESERVED_RANGE_START_IP\
       --description "Cloud Build private pool reserved range" \
       --global \
       --network NETWORK \
       --prefix-length RESERVED_RANGE_PREFIX_LENGTH \
       --purpose VPC_PEERING
   

   Substitua:

   • RESERVED_RANGE_NAME: o nome do intervalo de endereços IP alocado que hospeda o pool particular do Cloud Build. Neste tutorial, use cloud-build-private-pool.
   • RESERVED_RANGE_START_IP: o primeiro endereço IP do intervalo alocado. Neste tutorial, use 192.168.12.0.
   • RESERVED_RANGE_PREFIX_LENGTH: o tamanho do prefixo (máscara de sub-rede) do intervalo de endereços IP alocado. O comprimento do prefixo precisa ser /23 ou um número menor, por exemplo, /22 ou /21. Um número menor significa um intervalo de endereços maior. Neste tutorial, use 23 e não insira a barra inicial /.

2. Crie uma regra de firewall para permitir o tráfego de entrada do intervalo de endereços IP reservados para outros recursos na sua rede VPC:

   gcloud compute firewall-rules create allow-private-pools-ingress \
       --allow all \
       --network NETWORK \
       --source-ranges RESERVED_RANGE_START_IP/RESERVED_RANGE_PREFIX_LENGTH
   

3. Crie uma conexão de serviço particular para conectar sua rede VPC ao serviço Service Networking:

   gcloud services vpc-peerings connect \
       --network NETWORK \
       --ranges RESERVED_RANGE_NAME \
       --service servicenetworking.googleapis.com
   

   Os pools particulares do Cloud Build executam workers usando o Service Networking. A conexão de serviço particular permite que sua rede VPC se comunique com o pool particular no intervalo alocado de endereços IP internos usando uma conexão de peering de rede VPC.

   Pode levar alguns minutos para criar a conexão de serviço particular.

   Se você usa uma VPC compartilhada no seu próprio ambiente, consulte Configurar seu ambiente para saber mais sobre as etapas adicionais para criar a conexão de serviço particular.

4. Crie um pool particular do Cloud Build em uma rede VPC de propriedade do Google que tenha peering com sua rede VPC:

   gcloud builds worker-pools create PRIVATE_POOL_NAME \
      --no-public-egress \
      --peered-network projects/PROJECT_ID/global/networks/NETWORK \
      --region REGION
   

   Substitua:

   • PRIVATE_POOL_NAME: o nome do pool particular. Neste tutorial, use private-pool.
   • REGION: a região a ser usada para o pool particular. Neste tutorial, use us-central1.

   A flag --no-public-egress significa que os workers no pool particular não têm endereços IP públicos. No seu ambiente, você pode remover essa flag se quiser que os workers no pool particular tenham conectividade com a Internet usando endereços IP públicos.

   Para informações sobre outras opções de configuração, como tipo de máquina e tamanho do disco para os workers no pool particular, consulte Criar e gerenciar pools particulares.

Verificar a solução

Nesta seção, você verifica a solução executando um build no pool particular do Cloud Build. O build acessa o cluster particular do GKE.

1. No Cloud Shell, crie um bucket do Cloud Storage para armazenar os registros de build do Cloud Build:

   gcloud storage buckets create gs://PROJECT_ID-build-logs --location=REGION
   

2. Crie um arquivo de configuração de build para o Cloud Build:

   cat << "EOF" > cloudbuild.yaml
   steps:
   - id: list-services
     name: gcr.io/google.com/cloudsdktool/google-cloud-cli
     entrypoint: bash
     args:
     - -eEuo
     - pipefail
     - -c
     - |-
       kubectl config use-context $_KUBECTL_CONTEXT
   
       ACCESS_TOKEN=$$(curl --silent \
           --header "Metadata-Flavor: Google" \
           http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token \
           | python3 -c 'import json, sys; print(json.load(sys.stdin).get("access_token"))')
   
       ID_TOKEN=$$(curl --silent --request POST \
           --data '{"audience": "CLIENT_ID", "includeEmail": true}' \
           --header "Authorization: Bearer $$ACCESS_TOKEN" \
           --header "Content-Type: application/json; charset=utf-8" \
           "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/$_SERVICE_ACCOUNT:generateIdToken" \
           | python3 -c 'import json, sys; print(json.load(sys.stdin).get("token"))')
   
       kubectl get services --namespace $_NAMESPACE --token $$ID_TOKEN
   
   logsBucket: gs://PROJECT_ID-build-logs
   
   options:
     env:
     - KUBECONFIG=/workspace/$_KUBECONFIG
   
   substitutions:
     _KUBECONFIG: kubeconfig
     _KUBECTL_CONTEXT: private-cluster
     _NAMESPACE: default
   
   serviceAccount: projects/$PROJECT_ID/serviceAccounts/$_SERVICE_ACCOUNT
   EOF
   

   A etapa no arquivo de configuração da criação faz o seguinte:

   1. Muda para o contexto kubectl especificado pela substituição _KUBECTL_CONTEXT. O valor de substituição padrão é private-cluster.

   2. Recupera um token de acesso do servidor de metadados. O token de acesso é emitido para a conta de serviço do Google que executa o build.

   3. Gera um token de ID usando a API Service Account Credentials. A solicitação para gerar o token de ID é autenticada usando o token de acesso. A declaração aud (público-alvo) solicitada do token de ID é o ID do cliente OAuth 2.0 especificado pela substituição _CLIENT_ID.

   4. Lista os serviços do Kubernetes no namespace especificado pela substituição _NAMESPACE. O valor de substituição padrão é default. A solicitação é autenticada usando o token de ID gerado no comando anterior.

   Observe o seguinte sobre o arquivo de configuração de build:

   • O caractere $ é o prefixo das substituições. $$ é usado para expansão de parâmetros bash e substituição de comandos.

   • As substituições _KUBECONFIG e _KUBECTL_CONTEXT permitem especificar diferentes arquivos kubeconfig e contextos ao executar um build. Essas substituições permitem gerenciar várias configurações de cluster usando um único arquivo kubeconfig com vários contextos ou vários arquivos kubeconfig.

   • A substituição _SERVICE_ACCOUNT não tem um valor padrão. Você precisa fornecer um valor para essa substituição ao executar um build.

   • O bloco options define a variável de ambiente KUBECONFIG para todas as etapas do build.

   • A etapa de build usa a imagem do builder gcr.io/google.com/cloudsdktool/google-cloud-cli. Essa é uma imagem de contêiner grande, e leva algum tempo para extraí-la do registro para o worker do pool particular. Para reduzir o tempo necessário para extrair a imagem do builder, crie uma imagem personalizada que contenha apenas as ferramentas necessárias para a etapa de build, como curl, kubectl e Python.

   Para mais informações sobre scripts shell inline em arquivos de configuração de build, consulte Executar scripts bash.

3. Execute um build usando o arquivo de configuração de build e os arquivos no diretório atual:

   gcloud builds submit \
       --config cloudbuild.yaml \
       --region REGION \
       --substitutions _SERVICE_ACCOUNT=CB_GSA@PROJECT_ID.iam.gserviceaccount.com \
       --worker-pool projects/PROJECT_ID/locations/REGION/workerPools/PRIVATE_POOL_NAME
   

   O comando faz upload de todos os arquivos do diretório atual para o Cloud Storage, que serão usados pelo Cloud Build. A etapa de build usa o arquivo kubeconfig para se conectar ao cluster do GKE.

   Perto do final da saída, você verá linhas semelhantes a estas:

   NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
   kubernetes   ClusterIP   10.0.0.1     <none>        443/TCP   2h
   

   Essa saída mostra que o worker do pool particular se conectou ao plano de controle do cluster usando o proxy de autenticação do Identity Service para GKE.

Solução de problemas

Se não for possível se conectar à instância de VM usando SSH, adicione a flag --troubleshoot para descobrir a causa dos problemas de conectividade:

gcloud compute ssh VM --tunnel-through-iap --zone ZONE --troubleshoot

Se você receber a mensagem Error from server (NotFound): clientconfigs.authentication.gke.io "default" not found ao corrigir o ClientConfig padrão no cluster do GKE, verifique se criou a regra de firewall conforme descrito na seção Como criar um cluster particular do GKE. Verifique se ela existe:

gcloud compute firewall-rules describe allow-control-plane-clientconfig-webhook

Se não for possível se autenticar no proxy do Identity Service para GKE, procure erros nos registros dos pods na implantação gke-oidc-service:

gcloud compute ssh VM --tunnel-through-iap --zone ZONE --command \
    'kubectl logs deployment/gke-oidc-service \
         --namespace anthos-identity-service --all-containers'

Se você tiver outros problemas com este tutorial, recomendamos que consulte estes documentos:

• Solução de problemas do GKE
• Como solucionar problemas de clusters do Kubernetes