Olá @Gilmar Vagner
Obrigado por contactar o Microsoft Q&A.
Este erro ocorre porque o novo emissor OIDC do Azure DevOps emite declarações de token fixas e amplas que não podem ser personalizadas ou truncadas, ao contrário do include_claim_keys do GitHub.
Com o novo emissor, o ADO não consegue definir o âmbito dos tokens na origem, pelo que o GCP impõe limites e o âmbito deve ser feito inteiramente do lado do consumidor (condições do emissor + assunto).
Identifique os campos do token
No pipeline do ADO, observe o emissor (iss), o público-alvo (aud) e o assunto (sub) do token OIDC.
Criar/Atualizar o fornecedor OIDC do GCP
Configure um fornecedor de identidade de carga de trabalho no GCP utilizando o novo emissor do ADO, o público-alvo permitido e mapeie o google.subject.
Ligue a conta de serviço do GCP
Conceda roles/iam.workloadIdentityUser ao fornecedor, com âmbito definido pelo assunto (ligação pipeline/serviço).
Utilize a federação no pipeline
Troque o token OIDC do Azure DevOps pelas credenciais GCP e execute comandos gcloud/SDK em segurança.
Pode ligar o Azure DevOps ao GCP de uma forma alternativa:
https://docs.cloud.google.com/dotnet/docs/creating-cicd-pipeline-vsts-kubernetes-engine
Chave da conta de serviço (JSON)
Armazene a chave da conta de serviço do GCP nos segredos do Azure DevOps e autentique-se através de GOOGLE_APPLICATION_CREDENTIALS.
Broker do Vault/Terraform
O Azure DevOps autentica-se no Vault/TFC, que depois acede ao GCP.
Desencadear uma ação do GitHub a partir do Azure DevOps; o GitHub utiliza o OIDC nativo do GCP
Chame diretamente as APIs do GCP STS a partir do pipeline.