Configurar a federação de identidade da carga de trabalho com outros provedores de identidade

Neste guia, descrevemos como usar a federação de identidade da carga de trabalho com outros provedores de identidade (IdPs).

Para autenticação no Cloud de Confiance, é possível permitir que a carga de trabalho troque as credenciais específicas do ambiente por credenciais de curta duração do Cloud de Confianceusando a federação de identidade da carga de trabalho.

As cargas de trabalho executadas fora do Cloud de Confiance podem ter acesso a credenciais específicas do ambiente que já existem, por exemplo:

  • Uma carga de trabalho pode receber um token de declaração do OpenID Connect (OIDC) de um IdP.

  • Uma carga de trabalho pode receber um token de declaração SAML de um provedor de identidade (IdP).

O uso da federação de identidade da carga de trabalho pode ajudar você a reduzir o número de credenciais que exigem rotação.

As próximas seções descrevem como usar a federação de identidade da carga de trabalho com IdPs compatíveis com um destes protocolos de autenticação: OpenID Connect (OIDC) ou SAML.

Preparar seu IdP externo

Você só precisa realizar essas etapas uma vez para cada IdP.

Antes de começar, verifique se o IdP externo atende aos seguintes requisitos:

OIDC

  • O IdP é compatível com o OpenID Connect 1.0.

  • O IdP tem um URI do emissor.

  • Cloud de Confiance pode acessar um conjunto de chaves JSON da Web (JWKS) que contém chaves JSON da Web (JWKs). Os JWKs são usados para validar tokens de declaração do OIDC. É possível fornecer acesso ao JWKS por um dos seguintes métodos:

    • Cloud de Confiance faz o download dos metadados do OIDC do IdP por um URL do Discovery conhecido, disponível publicamente e acessível pela Internet. Nos metadados, o URL do JWKS precisa ser protegido com SSL e TLS. O URL do JWKS precisa começar com https://. O Cloud de Confiance não é compatível com URLs do JWKS protegidos com certificados autoassinados.

      Por padrão, o Cloud de Confiance anexa /.well-known/openid-configuration ao URI do emissor para localizar o URL do Discovery. Se o IdP hospedar os metadados de descoberta em um endpoint personalizado, será possível especificar um URI de descoberta personalizado (--discovery-uri) (pré-lançamento).

      O URI de descoberta personalizado precisa atender aos seguintes requisitos:

      • O URI precisa começar com https://.
      • O URI não pode exceder 2.000 caracteres.
      • O esquema, o host e a porta precisam corresponder ao URI do emissor.
      • O caminho do URI precisa conter /.well-known/<suffix> (em que <suffix> não está vazio, como openid-configuration) e estar em conformidade com uma das seguintes topologias de URL do emissor:
      • O segmento de caminho conhecido é inserido antes do caminho do emissor (por exemplo, https://example.com/.well-known/openid-configuration/tenant1 para o emissor https://example.com/tenant1).
      • O segmento de caminho conhecido é anexado ao caminho do emissor (por exemplo, https://example.com/tenant1/.well-known/openid-configuration para o emissor https://example.com/tenant1).

      OCloud de Confiance usa esses URLs de endpoint para fazer o download das chaves da Web JSON (JWKs) do IdP e usa essas chaves para validar tokens. OCloud de Confiance não limita o número de chaves que podem ser baixadas.

    • É possível fazer upload de um arquivo JWKS do OIDC diretamente para o Cloud de Confiance ao criar ou atualizar o provedor de pool de Identidade da carga de trabalho do OIDC. Para fazer isso, use a flag --jwk-json-path para fornecer um caminho para o arquivo JWKS. Use esse método quando o URL do endpoint de metadados OIDC do IdP não estiver acessível publicamente. É possível fazer upload de até oito chaves para o Cloud de Confiance. Como prática recomendada, recomendamos que você alterne as chaves JWKS regularmente atualizando o arquivo JWKS.

  • Se você estiver federando cargas de trabalho da AWS usando a federação de identidade de saída da AWS, a AWS vai atuar como seu IdP do OIDC. Para preparar o ambiente da AWS, siga estas etapas:

    1. Ative a federação de identidade de saída nas configurações da sua conta da AWS para gerar o URL exclusivo do emissor do OIDC.

    2. Verifique se as cargas de trabalho da AWS (como perfis de instância do EC2 ou papéis de tarefa do ECS) têm a política do IAM da AWS necessária que concede permissão para receber JSON Web Tokens (JWTs).

SAML

  • O IdP é compatível com SAML 2.0.

  • O IdP fornece um documento de metadados SAML SP que descreve a configuração do provedor de serviços SAML e contém o certificado de assinatura do IdP.

    OCloud de Confiance usa esse certificado para validar declarações e respostas SAML.

  • O certificado de assinatura do IdP precisa conter uma chave ECDSA ou RSA em um certificado X.509 v3.

  • Os algoritmos de assinatura recomendados incluem:

  • O certificado de assinatura precisa atender aos seguintes requisitos de validade:

    • notBefore: um carimbo de data/hora que não seja maior que sete dias no futuro
    • notAfter: um carimbo de data/hora que não seja mais de 25 anos no futuro

É possível configurar um provedor de pool de identidade da carga de trabalho SAML com no máximo três certificados de assinatura SAML por vez. Essa limitação não se aplica a outros tipos de provedores de pool de identidade da carga de trabalho, como OIDC e X.509. Quando há vários certificados, o Cloud de Confiance faz a iteração por eles e tenta usar cada certificado não expirado para atender a uma solicitação de troca de token.

Como prática recomendada de segurança, recomendamos não reutilizar o mesmo par de chaves com outros serviços.

Se o IdP atender a esses critérios, faça o seguinte:

OIDC

Configure seu IdP para que a carga de trabalho possa receber tokens de ID que atendam a estes critérios:

  • Os tokens são assinados usando o algoritmo RS256 ou ES256.
  • Os tokens contêm uma declaração aud com o seguinte valor:

    https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/WORKLOAD_PROVIDER_ID
    

    Substitua:

    • PROJECT_NUMBER: o número do projeto do Cloud de Confiance projeto do Google Cloud que você usa para criar um pool de Identidade da carga de trabalho.
    • POOL_ID: ID de sua escolha que identifica o pool de identidades da carga de trabalho. É necessário usar o mesmo ID ao criar o pool de identidades da carga de trabalho posteriormente.
    • WORKLOAD_PROVIDER_ID: ID de sua escolha que identifica o provedor de pool de Identidade da carga de trabalho. É necessário usar o mesmo ID ao criar o provedor do pool de identidade da carga de trabalho posteriormente.

    Como alternativa, é possível configurar o provedor de pool de identidade da carga de trabalho para esperar um público personalizado.

  • Os tokens contêm uma declaração exp no futuro e uma iat no passado.

    O valor de exp precisa ser maior que o valor de iat em até 24 horas.

  • Tokens vinculados a certificados (pré-lançamento): opcionalmente, os tokens podem incluir uma declaração cnf (confirmação) que contém uma impressão digital do certificado SHA-256 (x5t#S256):

    "cnf": {
      "x5t#S256": "BASE64URL_SHA256_CERT_FINGERPRINT"
    }
    

    O valor de x5t#S256 precisa ser o hash SHA-256 codificado em base64url da codificação DER do certificado X.509 do cliente. Quando um token que contém essa declaração é apresentado à federação de identidade da carga de trabalho por uma conexão TLS mútua (mTLS) (sts.mtls.googleapis.com), o Security Token Service valida se a impressão digital corresponde ao certificado do cliente apresentado durante o handshake de TLS e emite um token de acesso de curta duração vinculado criptograficamente ao certificado.

    Para proteger os recursos contra roubo de tokens e ataques de repetição, aplique tokens vinculados a certificados configurando políticas de acesso baseado no contexto.

Normalmente, é melhor usar tokens de ID ao realizar uma troca de tokens, porque eles refletem a identidade do usuário. Se você decidir usar tokens de acesso, verifique se eles atendem aos seguintes requisitos adicionais:

  • Os tokens de acesso são formatados em JSON Web Token.
  • Os tokens de acesso contêm uma declaração ISSUER para que o URL ISSUER/.well-known/openid-configuration aponte para o endpoint de metadados OIDC do IdP.

  • Para fazer upload de chaves JWK locais, consulte Gerenciar JWKs do OIDC.

SAML

Configure seu IdP para que as declarações SAML contenham elementos que atendam aos seguintes critérios:

  • um elemento Issuer definido como o ID da entidade configurado no provedor do pool de identidades da carga de trabalho. O formato do emissor precisa ser omitido ou definido como urn:oasis:names:tc:SAML:2.0:nameid-format:entity;
  • um elemento Subject com:
    • um elemento NameID;
    • exatamente um elemento SubjectConfirmation com Method definido como urn:oasis:names:tc:SAML:2.0:cm:bearer;
    • um elemento SubjectConfirmationData com NotOnOrAfter definido como um carimbo de data/hora que ocorrerá no futuro e nenhum valor NotBefore.
  • um elemento Conditions com:

    • NotBefore omitido ou antigo;
    • NotOnOrAfter omitido ou no futuro.
    • um Audience, formatado da seguinte maneira:

      https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/WORKLOAD_PROVIDER_ID
      

      Substitua:

      • PROJECT_NUMBER: o número do projeto do Cloud de Confiance projeto que você usa para criar o pool de Identidade da carga de trabalho.
      • POOL_ID: ID de sua escolha que identifica o pool de identidades da carga de trabalho. É necessário usar o mesmo ID ao criar o pool de identidades da carga de trabalho posteriormente.
      • WORKLOAD_PROVIDER_ID: ID de sua escolha que identifica o provedor de pool de Identidade da carga de trabalho. É necessário usar o mesmo ID ao criar o provedor do pool de Identidade da carga de trabalho posteriormente.
  • pelo menos um elemento AuthnStatement;

  • um elemento SessionNotOnOrAfter com um carimbo de data/hora que ocorrerá no futuro. Se preferir, omita o elemento.

Para declarações SAML incluídas em uma resposta SAML, a resposta SAML precisa conter:

  • exatamente uma declaração que atenda aos critérios de declaração SAML descritos anteriormente nesta seção;
  • um atributo IssueInstant com um valor inferior a uma hora no passado;
  • o StatusCode urn:oasis:names:tc:SAML:2.0:status:Success.

É preciso assinar a declaração SAML, a resposta ou ambas.

Configurar a federação de identidade da carga de trabalho

Você só precisa realizar essas etapas uma vez para cada IdP. Depois disso, será possível usar o mesmo pool de identidade da carga de trabalho e servidor em várias cargas de trabalho e em vários projetos do Cloud de Confiance .

Para começar a configurar a federação de identidade da carga de trabalho, faça isto:

  1. No console do Cloud de Confiance , na página do seletor de projetos, selecione ou crie um projeto do Cloud de Confiance .

    Papéis necessários para selecionar ou criar um projeto

    • Selecionar um projeto: para selecionar um projeto, não é necessário ter um papel específico do IAM. É possível selecionar qualquer projeto em que você tenha um papel.
    • Criar um projeto: para criar um projeto, é preciso ter o papel de Criador de projetos (roles/resourcemanager.projectCreator), que contém a permissão resourcemanager.projects.create. Saiba como conceder papéis.

    Acessar o seletor de projetos

  2. É melhor usar um projeto dedicado para gerenciar pools e provedores de identidade da carga de trabalho.
  3. Verifique se o faturamento está ativado para o projeto do Cloud de Confiance .

  4. Ative as APIs IAM, Resource Manager, Service Account Credentials e Security Token Service, se ainda não estiverem ativadas.

    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 conseguir essa permissão pelo papel de administrador do Service Usage (roles/serviceusage.serviceUsageAdmin). Saiba como conceder papéis.

    Ativar as APIs

Gerenciar JWKs do OIDC enviados por upload (opcional)

Nesta seção, mostramos como gerenciar JWKs OIDC com upload automático em provedores OIDC do pool de identidades de carga de trabalho.

Criar um provedor e fazer upload de JWKs do OIDC

Para criar JWKs do OIDC, consulte Implementações de JWT, JWS, JWE, JWK e JWA.

Para fazer upload de um arquivo JWK do OIDC ao criar um provedor de pool de Identidade da carga de trabalho, execute o comando gcloud iam workload-identity-pools providers create-oidc com --jwk-json-path="JWK_JSON_PATH". Substitua JWK_JSON_PATH pelo caminho para o arquivo JSON do JWKs.

Essa operação cria chaves enviadas com as chaves no arquivo.

Atualizar JWKs do OIDC

Para atualizar as JWKs do OIDC, execute o comando gcloud iam workload-identity-pools providers update-oidc com --jwk-json-path="JWK_JSON_PATH". Substitua JWK_JSON_PATH pelo caminho para o arquivo JSON do JWKs.

Essa operação substitui todas as chaves atuais enviadas pelas chaves no arquivo. Não é possível restaurar as chaves substituídas.

Excluir todos os JWKs do OIDC enviados por upload

Para excluir todos os JWKs do OIDC enviados e voltar a usar o URI do emissor para buscar as chaves, execute o comando gcloud iam workload-identity-pools providers update-oidc com --jwk-json-path="JWK_JSON_PATH". Substitua JWK_JSON_PATH pelo caminho para um arquivo vazio. Use a sinalização --issuer-uri para definir o URI do emissor.

Essa operação exclui todas as chaves enviadas. Não é possível restaurar as chaves excluídas.

Definir um mapeamento e uma condição de atributo

Os tokens OIDC ou declarações SAML emitidas pelo IdP podem conter vários atributos, e você precisa decidir qual atributo quer usar como identificador do assunto (google.subject) no Cloud de Confiance.

Também é possível mapear outros atributos. Consulte esses atributos ao conceder acesso aos recursos.

OIDC

Os mapeamentos de atributos podem usar as declarações incorporadas no token de ID ou de acesso emitido pelo IdP externo.

Mapeie uma dessas declarações para google.subject para identificar exclusivamente o usuário. Para se proteger contra ameaças de spoofing, escolha uma reivindicação com um valor exclusivo que não possa ser alterado.

Muitos IdPs preenchem a declaração sub com um ID exclusivo e imutável. Para esses IdPs, considere mapear a declaração sub para google.subject:

google.subject=assertion.sub

Evite usar uma reivindicação como email para essa finalidade. Geralmente, os endereços de e-mail podem ser reatribuídos ou alterados para que não identifiquem um usuário de maneira exclusiva e permanente.

Mapear atributos de ator com delegação de identidade (pré-lançamento): quando você usa a delegação de identidade, o Security Token Service combina as declarações de sujeito e de ator, expondo as declarações de ator no objeto de declaração act. É possível referenciar declarações de ator nos mapeamentos de atributos usando assertion.act.<claim_name>.

Ao realizar uma troca de token delegada, somente os mapeamentos e as condições de atributo do provedor de assunto são avaliados e aplicados. Todos os mapeamentos ou condições de atributos configurados no provedor de ator são ignorados.

Por exemplo, é possível mapear o identificador de assunto e o URI do emissor do ator para atributos personalizados do Google:

attribute.actor_subject=assertion.act.sub,attribute.actor_issuer=assertion.act.iss

Se a delegação de vários saltos for usada, os atores upstream serão aninhados em assertion.act.act. No entanto, a ordem das declarações aninhadas não é garantida.

SAML

Os mapeamentos de atributos podem usar os elementos <Subject> e <Attribute> incorporados na declaração emitida pelo IdP externo. Os atributos SAML podem ser referenciados usando as seguintes palavras-chave:

  • assertion.subject contém o NameID do usuário autenticado encontrado no elemento <Subject>.
  • assertion.attributes['ATTRIBUTE_NAME'] contém uma lista de valores com o nome <Attribute>.

Mapeie uma dessas declarações para google.subject para identificar exclusivamente o usuário. Para se proteger contra ameaças de spoofing, escolha uma reivindicação com um valor exclusivo que não possa ser alterado.

Muitos IdPs preenchem o NameId com um ID exclusivo e imutável. Para esses IdPs, considere mapear o atributo NameId para google.subject:

google.subject=assertion.subject

Evite usar um atributo como http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress para essa finalidade. Geralmente, os endereços de e-mail podem ser reatribuídos ou alterados para que não identifiquem um usuário de maneira exclusiva e permanente.

Também é possível definir uma condição de atributo. As condições de atributo são expressões CEL que podem verificar atributos de declaração e atributos de destino. Se a condição do atributo for avaliada como true para uma determinada credencial, a credencial será aceita. Caso contrário, a credencial será rejeitada.

OIDC

Use uma condição de atributo para restringir quais usuários podem usar a federação de identidade da carga de trabalho para conseguir tokens do Cloud de Confiancede curta duração.

Por exemplo, a condição a seguir restringe o acesso a tokens que contêm uma declaração service_account personalizada com um valor true:

assertion.service_account==true

Condições de delegação de identidade (token de ator) (pré-lançamento): ao usar a delegação de identidade, é possível usar condições de atributo CEL para restringir quais atores podem realizar operações em nome de indivíduos ou aplicar declarações específicas no token de ator.

Por exemplo, a condição a seguir exige que um token de ator esteja presente e que o ator tenha sido originado de um emissor esperado:

has(assertion.act) && assertion.act.iss == 'https://actor-idp.example.com'

Para restringir o acesso a um identificador de assunto de ator específico:

assertion.act.sub == 'authorized-agent-worker'

SAML

Use uma condição de atributo para restringir quais usuários podem usar a federação de identidade da carga de trabalho para conseguir tokens do Cloud de Confiancede curta duração.

Por exemplo, a condição a seguir restringe o acesso a declarações que contenham um atributo https://example.com/SAML/Attributes/AllowGcpFederation personalizado com um valor true:

assertion.attributes['https://example.com/SAML/Attributes/AllowGcpFederation'][0]=='true'

Criar um pool de identidade e um pol de Identidade da carga de trabalho

Funções exigidas

Para receber as permissões necessárias para configurar a federação de identidade da carga de trabalho, peça ao administrador para conceder a você os seguintes papéis do IAM 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 por meio de papéis personalizados ou de outros papéis predefinidos.

Como alternativa, o papel básico de Proprietário do IAM (roles/owner) também inclui permissões para configurar a federação de identidade. Não conceda papéis básicos em um ambiente de produção, recomendamos que você faça isso em um ambiente de desenvolvimento ou teste.

Agora que você coletou todas as informações necessárias para criar um pool e um provedor de identidade de carga de trabalho:

Console

  1. No console do Cloud de Confiance , acesse a página Novo provedor de carga de trabalho e pool.

    Acessar "Novo provedor de carga de trabalho" e "Pool"

  2. Em Criar um pool de identidades, digite o seguinte:

    • Nome: o nome do pool. O nome também é usado como o ID do pool. Não será possível alterar o ID do pool posteriormente.
    • Descrição: texto que descreve a finalidade do pool.
  3. Clique em Continuar.

  4. Defina as configurações do provedor da seguinte maneira:

    OIDC

    • Em Selecionar um provedor, selecione OpenID Connect (OIDC).
    • Em Nome do provedor, digite um nome para o provedor. O nome também é usado como o ID do provedor. Não é possível alterar o ID do provedor depois que ele for criado.
    • Em URL do emissor, digite o URL do emissor do seu IdP. O URL precisa começar com https://.
    • Opcional: em Arquivo JWK(JSON), escolha um arquivo JWK para fazer upload. Se esse campo não for fornecido, o Cloud de Confiance tentará buscar um JWK do emissor.
    • Públicos-alvo permitidos: público-alvo esperado dos tokens de ID.

    SAML

    • Em Selecionar um provedor, escolha SAML.
    • Em Nome do provedor, digite um nome para o provedor. O nome também é usado como o ID do provedor. Não é possível alterar o ID do provedor depois que ele for criado.
    • Em Arquivo de metadados do IdP (XML), faça upload do documento XML de metadados SAML fornecido pelo seu IdP.
  5. Clique em Continuar.

  6. Em Configurar atributos do provedor, adicione os mapeamentos de atributos identificados anteriormente neste guia.

  7. Em Condições de atributo, insira a condição de atributo que você identificou anteriormente neste guia. Deixe o campo em branco se não houver uma condição de atributo.

  8. Para criar o pool de Identidade da carga de trabalho e o provedor, clique em Salvar.

gcloud

  1. Para criar um novo pool de identidade da carga de trabalho, execute o seguinte comando:

    gcloud iam workload-identity-pools create POOL_ID \
        --location="global" \
        --description="DESCRIPTION" \
        --display-name="DISPLAY_NAME"
    

    Substitua:

    • POOL_ID: o ID exclusivo do pool.
    • DISPLAY_NAME: o nome do pool.
    • DESCRIPTION: uma descrição do pool escolhido. Essa descrição aparece quando você concede acesso às identidades do pool.
  2. Para adicionar um provedor de pool de Identidade da carga de trabalho, faça o seguinte:

    OIDC

    Para adicionar um provedor de pool de Identidade da carga de trabalho do OIDC, execute o seguinte comando:

    gcloud iam workload-identity-pools providers create-oidc WORKLOAD_PROVIDER_ID \
        --location="global" \
        --workload-identity-pool="POOL_ID" \
        --issuer-uri="ISSUER" \
        --discovery-uri="DISCOVERY_URI" \
        --allowed-audiences="AUDIENCE" \
        --attribute-mapping="MAPPINGS" \
        --attribute-condition="CONDITIONS" \
        --jwk-json-path="JWK_JSON_PATH" \
        --actor-providers="ACTOR_PROVIDERS"
    

    Substitua:

    • WORKLOAD_PROVIDER_ID: um ID de provedor do pool de Identidade da carga de trabalho exclusivo de sua escolha.
    • POOL_ID: o ID do pool de Identidade da carga de trabalho que você criou anteriormente.
    • ISSUER: um URI do emissor, conforme definido nos metadados OIDC.
    • DISCOVERY_URI Pré-lançamento: um URL de descoberta personalizado opcional para buscar metadados do OIDC se o IdP não hospedar o endpoint de descoberta do OIDC conhecido em https://<issuer_url>/.well-known/openid-configuration. O esquema, o host e a porta precisam corresponder ao ISSUER, e o caminho precisa estar em conformidade com a topologia do URL do emissor (contendo /.well-known/<suffix>).
    • AUDIENCE: o público esperado de tokens de ID, que, para muitos provedores, correspondem ao ID do cliente.
    • MAPPINGS: uma lista separada por vírgulas de mapeamentos de atributos criados anteriormente neste guia.
    • CONDITIONS: uma condição de atributo opcional que você criou anteriormente neste guia. Remova o parâmetro se você não tiver uma condição de atributo.
    • JWK_JSON_PATH: um caminho opcional para JWKs do OIDC de upload local. Se esse parâmetro não for fornecido, o Cloud de Confiance vai usar o URL do Discovery (DISCOVERY_URI ou o caminho /.well-known/openid-configuration do IdP) para gerar as JWKs que contêm as chaves públicas.
    • ACTOR_PROVIDERS Pré-lançamento: uma lista opcional separada por vírgulas dos nomes de recursos completos dos provedores de pool de Identidade da carga de trabalho no mesmo pool que estão autorizados a emitir tokens de ator para esse provedor (por exemplo, projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/ACTOR_PROVIDER_ID). O ID do contêiner do projeto no nome do recurso precisa corresponder ao formato usado para o provedor de assunto (ambos usando o número numérico do projeto ou ambos usando o ID do projeto). É possível especificar no máximo três provedores de ator. Para mais informações, consulte Configurar a delegação de identidade e os tokens de ator.

    SAML

    Para adicionar um provedor de pool de identidade da carga de trabalho SAML, execute o seguinte comando:

    gcloud iam workload-identity-pools providers create-saml WORKLOAD_PROVIDER_ID \
        --location="global" \
        --workload-identity-pool="POOL_ID" \
        --idp-metadata-path="IDP_METADATA_PATH" \
        --attribute-mapping="MAPPINGS" \
        --attribute-condition="CONDITIONS"
    

    Substitua:

    • POOL_ID: o ID do pool
    • IDP_METADATA_PATH: o caminho local para o documento de metadados do IdP do SAML.
    • MAPPINGS: uma lista separada por vírgulas de mapeamentos de atributos criados anteriormente neste guia.
    • CONDITIONS: opcional. A condição do atributo que você criou anteriormente neste guia.

    O prefixo gcp- é reservado e não pode ser usado em um ID de pool de identidades de colaboradores ou de provedor de pool de identidades de colaboradores.

    Opcional: aceitar declarações SAML criptografadas do seu IdP

    Para permitir que o IdP do SAML 2.0 produza declarações SAML criptografadas que podem ser aceitas pela federação de identidade da carga de trabalho, faça isto:

    • Na federação de identidade da carga de trabalho, faça isto:
      • Crie um par de chaves assimétricas para seu provedor de pool de identidade da carga de trabalho.
      • Faça o download de um arquivo de certificado que contém a chave pública.
      • Configure o IdP do SAML para que use a chave pública para criptografar as declarações SAML emitidas.
    • No IdP, faça isto:
      • Ative a criptografia de declaração, também conhecida como criptografia de token.
      • Faça upload da chave pública que você criou na federação de identidade da carga de trabalho.
      • Confirme se o IdP produz declarações SAML criptografadas.
    Observação: mesmo com as chaves do provedor de criptografia SAML configuradas, a federação de identidade da carga de trabalho ainda pode processar uma declaração de texto simples.

    Criar chaves de criptografia de declaração SAML da federação de identidade da carga de trabalho

    Nesta seção, mostramos como criar um par de chaves assimétricas que permite que a federação de identidade da carga de trabalho aceite declarações SAML criptografadas.

    O Cloud de Confiance by S3NS usa a chave privada para descriptografar as declarações SAML emitidas pelo IdP. Para criar um par de chaves assimétricas para uso com criptografia SAML, execute o seguinte comando. Para saber mais, consulte Algoritmos de criptografia SAML compatíveis.

    gcloud iam workload-identity-pools providers keys create KEY_ID \
        --workload-identity-pool WORKLOAD_POOL_ID \
        --provider WORKLOAD_PROVIDER_ID \
        --location global \
        --use encryption \
        --spec KEY_SPECIFICATION

    Substitua:

    • KEY_ID: o nome da chave que você escolher
    • WORKLOAD_POOL_ID: o ID do pool
    • WORKLOAD_PROVIDER_ID: o ID do provedor do pool de identidade de colaboradores
    • KEY_SPECIFICATION: a especificação da chave, que pode ser uma destas: rsa-2048, rsa-3072 e rsa-4096.

    Depois que o par de chaves for criado, execute o comando a seguir para fazer o download da chave pública em um arquivo de certificado. Somente a federação de identidade da carga de trabalho tem acesso à chave privada.

    gcloud iam workload-identity-pools providers keys describe KEY_ID \
        --workload-identity-pool WORKLOAD_POOL_ID \
        --provider WORKLOAD_PROVIDER_ID \
        --location global \
        --format "value(keyData.key)" \
        > CERTIFICATE_PATH

    Substitua:

    • KEY_ID: o nome da chave
    • WORKLOAD_POOL_ID: o ID do pool
    • WORKLOAD_PROVIDER_ID: o ID do provedor do pool de identidade de colaboradores
    • CERTIFICATE_PATH: o caminho para gravar o certificado em, por exemplo, saml-certificate.cer ou saml-certificate.pem

    Configurar o IdP compatível com SAML 2.0 para emitir declarações SAML criptografadas

    Configure o IdP do SAML para que use o certificado público transferido por download na última etapa para criptografar as declarações SAML emitidas. Consulte a equipe do IdP para ter instruções específicas.

    Depois de configurar o IdP para criptografar declarações SAML, recomendamos que você confira se as declarações geradas estão realmente criptografadas. Mesmo com a criptografia da declaração SAML configurada, a federação de identidade da carga de trabalho ainda pode processar declarações de texto simples.

    Excluir chaves de criptografia da federação de identidade da carga de trabalho

    Para excluir as chaves de criptografia SAML, execute o seguinte comando:
      gcloud iam workload-identity-pools providers keys delete KEY_ID \
          --workload-identity-pool WORKLOAD_POOL_ID \
          --provider WORKLOAD_PROVIDER_ID \
          --location global

    Substitua:

    • KEY_ID: o nome da chave
    • WORKLOAD_POOL_ID: o ID do pool
    • WORKLOAD_PROVIDER_ID: o ID do provedor do pool de identidade de colaboradores

    Algoritmos de criptografia SAML compatíveis

    A federação de identidade da carga de trabalho é compatível com os seguintes algoritmos de transporte de chaves:

    A federação de identidade da carga de trabalho é compatível com os seguintes algoritmos de criptografia em blocos:

Configurar a aplicação do acesso baseado no contexto para a federação de identidade da carga de trabalho

A aplicação da política de acesso baseado no contexto só é válida quando tokens vinculados a certificados são usados. Para reforçar a segurança dos recursos contra ataques de repetição e roubo de tokens, ative o acesso baseado no contexto, que aplica a validação de mTLS e a vinculação de certificados para solicitações de acesso. Quando as políticas de acesso baseado no contexto são configuradas para tokens vinculados a certificados, o Cloud de Confiance avalia o contexto de transporte e o certificado do cliente das solicitações recebidas para garantir que os tokens de acesso apresentados pela carga de trabalho estejam vinculados criptograficamente a uma sessão de certificado do cliente mTLS confiável. A aplicação da política de acesso baseado no contexto não é válida para tokens padrão não vinculados.

Configurar delegação de identidade e tokens de ator

Em um cenário de delegação de identidade, conforme definido em RFC 8693: troca de token do OAuth 2.0, uma parte atuante (ator) realiza operações em nome de uma identidade de sujeito.

Para configurar e autorizar a delegação de identidade, atenda aos seguintes requisitos:

  1. Autorização do provedor de ator: na configuração de provedores de ator (--actor-providers) do provedor de assunto, inclua o nome completo do recurso do provedor que emite o token de ator. O provedor de ator precisa atender aos seguintes critérios:

    • Precisa estar no mesmo pool de identidade da carga de trabalho que o provedor em questão.
    • O ID do contêiner do projeto no nome do recurso precisa corresponder ao formato usado para o provedor de assunto. Por exemplo, se você estiver usando a Google Cloud CLI para criar o provedor de assunto, ele precisa ser o ID alfanumérico do projeto.
    • É possível autorizar no máximo três provedores de ator por provedor.
  2. Declaração may_act no token de assunto: o token de ID de assunto precisa incluir uma declaração may_act:

    "may_act": {
      "sub": "ACTOR_SUBJECT",
      "iss": "ACTOR_ISSUER"
    }
    

    Substitua:

    • ACTOR_SUBJECT: o identificador de assunto do usuário autorizado (precisa corresponder à declaração sub no token do usuário).
    • ACTOR_ISSUER: opcional. O URI do emissor do provedor de identidade do ator (precisa corresponder à declaração iss no token do ator). Se omitido, o ator precisa compartilhar o mesmo emissor que o token de assunto.
  3. Parâmetros de troca de token: ao realizar uma troca de token com a federação de identidade da carga de trabalho, o cliente fornece o subject_token e o actor_token, além dos respectivos tipos de token (subject_token_type e actor_token_type):

    • subject_token: o token de segurança que representa a identidade em nome de quem a solicitação é feita.
    • subject_token_type: um identificador que indica o tipo de token de assunto (como urn:ietf:params:oauth:token-type:jwt ou urn:ietf:params:oauth:token-type:id_token).
    • actor_token: o token de segurança que representa a identidade da parte que está agindo. O token de ator precisa atender aos seguintes requisitos:
      • Reivindicação de público-alvo (aud): precisa conter o URI de recurso completo do provedor de ator específico que emite o actor_token: //iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/ACTOR_PROVIDER_ID. A declaração aud precisa conter apenas um URI de recurso do provedor de pool de Identidade da carga de trabalho. Se houver vários provedores de ator no mesmo pool de Identidade da carga de trabalho, inclua apenas o URI do recurso do provedor que emite o actor_token.
      • Provedor de ator autorizado: o provedor de ator identificado na declaração aud precisa residir no mesmo pool de Identidade da carga de trabalho que o provedor de assunto e estar listado na configuração de provedores de ator (--actor-providers) do provedor de assunto.
      • Declarações sub e iss correspondentes: as declarações sub e iss opcional do token de ator precisam corresponder aos valores sub e iss declarados na declaração may_act do token de assunto.
    • actor_token_type: um identificador que indica o tipo de token de ator (urn:ietf:params:oauth:token-type:jwt ou urn:ietf:params:oauth:token-type:id_token). Esse parâmetro é obrigatório quando actor_token está presente.
    • Tokens vinculados a certificados com delegação: se o subject_token estiver vinculado a um certificado (contiver uma declaração de confirmação cnf), o actor_token também precisará estar vinculado a um certificado (contendo uma declaração cnf). Ao realizar a troca de token por mTLS (sts.mtls.googleapis.com), o certificado do cliente apresentado no handshake de mTLS precisa corresponder à impressão digital do certificado do actor_token.

Autenticar uma carga de trabalho

É necessário realizar essas etapas uma vez para cada carga de trabalho.

Permitir que a carga de trabalho externa acesse recursos do Cloud de Confiance

Para fornecer à sua carga de trabalho acesso aos recursos do Cloud de Confiance , recomendamos que você conceda ao principal acesso direto aos recursos. Nesse caso, o principal é o usuário federado. Alguns produtos do Cloud de Confiance têm limitações de APIs do Google Cloud. Se sua carga de trabalho chamar um endpoint de API que apresenta limitação, será possível usar a identidade temporária de conta de serviço. Nesse caso, o principal é a conta de serviço doCloud de Confiance , que atua como a identidade. Você concede acesso à conta de serviço no recurso.

Acesso direto a recursos

É possível conceder acesso a uma identidade federada diretamente nos recursos usando o console do Cloud de Confiance ou a CLI gcloud.

Console

Para usar o console do Cloud de Confiance para conceder papéis do IAM diretamente em um recurso, acesse a página do recurso e conceda o papel. O exemplo a seguir mostra como acessar a página do Cloud Storage e conceder o papel Leitor de objetos do Storage (roles/storage.objectViewer) a uma identidade federada diretamente em um bucket do Cloud Storage.

  1. No console do Cloud de Confiance , acesse a página Buckets do Cloud Storage.

    Acessar buckets

  2. Na lista de buckets, clique no nome do bucket ao qual você quer conceder o papel.

  3. Selecione a guia Permissões na parte superior da página.

  4. Clique no botão Permitir acesso.

    A caixa de diálogo Adicionar principais será exibida.

  5. No campo Novos principais, insira uma ou mais identidades que precisam acessar seu bucket.

    Por assunto

    principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT
    

    Substitua:

    • PROJECT_NUMBER: o número do projeto
    • POOL_ID: o ID do pool de carga de trabalho
    • SUBJECT: o sujeito individual mapeado do IdP, por exemplo, administrator@example.com

    Por grupo

    principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP
    

    Substitua:

    • PROJECT_NUMBER: o número do projeto
    • WORKLOAD_POOL_ID: o ID do pool de carga de trabalho
    • GROUP: o grupo mapeado do IdP, por exemplo: administrator-group@example.com

    Por atributo

    principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE
    

    Substitua:

    • PROJECT_NUMBER: o número do projeto
    • WORKLOAD_POOL_ID: o ID do pool de carga de trabalho
    • ATTRIBUTE_NAME: um dos atributos que foi mapeado do IdP
    • ATTRIBUTE_VALUE: o valor do atributo
  6. Escolha um papel ou mais no menu suspenso Selecionar um papel. Os papéis selecionados são exibidos no painel com uma breve descrição das permissões que eles concedem.

  7. Clique em Salvar.

gcloud

Para usar a CLI gcloud a fim de conceder papéis do IAM em um recurso de um projeto, faça isto:

  1. Consiga o número do projeto em que o recurso está definido.

    gcloud projects describe $(gcloud config get-value core/project) --format=value\(projectNumber\)
    
  2. Conceda acesso ao recurso.

    Para usar a CLI gcloud para conceder o papel de Leitor de objetos do Storage (roles/storage.objectViewer) a identidades externas que atendam a determinados critérios, execute o comando a seguir.

    Por assunto

    gcloud storage buckets add-iam-policy-binding BUCKET_ID \
        --role=roles/storage.objectViewer \
        --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT"

    Por grupo

    gcloud storage buckets add-iam-policy-binding BUCKET_ID \
        --role=roles/storage.objectViewer \
        --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP"

    Por atributo

    gcloud storage buckets add-iam-policy-binding BUCKET_ID \
        --role=roles/storage.objectViewer \
        --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE"

    Substitua:

    • BUCKET_ID: o bucket em que o acesso será concedido
    • PROJECT_NUMBER: o número do projeto que contém o pool de Identidade da carga de trabalho
    • POOL_ID: o ID do pool de identidade da carga de trabalho
    • SUBJECT: o valor esperado do atributo mapeado para google.subject
    • GROUP: o valor esperado do atributo mapeado para google.groups
    • ATTRIBUTE_NAME: o nome de um atributo personalizado no seu mapeamento de atributos
    • ATTRIBUTE_VALUE: o valor do atributo personalizado no seu mapeamento de atributos

    É possível conceder papéis em qualquer recurso do Cloud de Confiance compatível com políticas de permissão do IAM.

Identidade temporária de conta de serviço

  1. Para criar uma conta de serviço para a carga de trabalho externa, faça isto:

    1. Ative as APIs IAM, Security Token Service e API Service Account Credentials, se ainda não estiverem ativadas.

      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 conseguir essa permissão pelo papel de administrador do Service Usage (roles/serviceusage.serviceUsageAdmin). Saiba como conceder papéis.

      Ativar as APIs

    2. Crie uma conta de serviço que represente a carga de trabalho. Recomendamos que você use uma conta de serviço dedicada para cada carga de trabalho. A conta de serviço não precisa estar no mesmo projeto que o pool de Identidade da carga de trabalho, mas você precisa se referir ao projeto que contém a conta de serviço.

    3. Conceda à conta de serviço acesso a recursos que você quer que as identidades externas acessem.

  2. Para permitir que a identidade federada represente a conta de serviço, faça o seguinte:

Console

Para usar o console do Cloud de Confiance para conceder papéis do IAM a uma identidade federada com conta de serviço, faça isto:

Conta de serviço no mesmo projeto

  1. Para conceder acesso usando a identidade temporária de conta de serviço no mesmo projeto, faça o seguinte:

    1. Acesse a página pools de Identidade da carga de trabalho.

      Acesse Pools de identidade da carga de trabalho

    2. Selecione Conceder acesso.

    3. Na caixa de diálogo Conceder acesso à conta de serviço, selecione Conceder acesso usando a identidade temporária de conta de serviço.

    4. Na lista Contas de serviço, selecione a conta de serviço para as identidades externas que serão representadas e faça isto:

    5. Para escolher quais identidades no pool podem representar a conta de serviço, realize uma das seguintes ações:

      • Para permitir que apenas identidades específicas do pool de Identidade da carga de trabalho representem a conta de serviço, selecione Somente identidades correspondentes ao filtro.

      • Na lista Nome do atributo, selecione o atributo que você quer filtrar.

      • No campo Valor do atributo, insira o valor esperado do atributo. Por exemplo, se você usar um google.subject=assertion.sub de mapeamento de atributos, defina o nome do Atributo com subject e o Valor do atributo com o valor da declaração sub em tokens emitidos pelo seu provedor de identidade externo.

    6. Para salvar a configuração, clique em Salvar e em Dispensar.

Conta de serviço em um projeto diferente

  1. Para conceder acesso usando a identidade temporária de conta de serviço em um projeto diferente, faça o seguinte:

    1. Acesse a página Contas de serviço.

      Acessar a página "Contas de serviço"

    2. Selecione a conta de serviço que você quer representar.

    3. Clique em Gerenciar acesso.

    4. Clique em Adicionar principal.

    5. No campo Novo principal, insira um dos seguintes identificadores principais para as identidades no pool que vão representar a identidade da conta de serviço.

      Por assunto

      principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT
      

      Substitua:

      • PROJECT_NUMBER: o número do projeto
      • POOL_ID: o ID do pool de carga de trabalho
      • SUBJECT: o sujeito individual mapeado do IdP, por exemplo, administrator@example.com

      Por grupo

      principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP
      

      Substitua:

      • PROJECT_NUMBER: o número do projeto
      • WORKLOAD_POOL_ID: o ID do pool de carga de trabalho
      • GROUP: o grupo mapeado do IdP, por exemplo: administrator-group@example.com

      Por atributo

      principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE
      

      Substitua:

      • PROJECT_NUMBER: o número do projeto
      • WORKLOAD_POOL_ID: o ID do pool de carga de trabalho
      • ATTRIBUTE_NAME: um dos atributos que foi mapeado do IdP
      • ATTRIBUTE_VALUE: o valor do atributo

      Por pool

      principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/*
      

      Substitua:

      • PROJECT_NUMBER: o número do projeto
      • WORKLOAD_POOL_ID: o ID do pool de carga de trabalho
    6. Em Selecionar um papel, selecione a função de usuário da Identidade da carga de trabalho (roles/iam.workloadIdentityUser).

    7. Para salvar a configuração, clique em Salvar.

gcloud

Para conceder o papel de usuário da Identidade da carga de trabalho (roles/iam.workloadIdentityUser) a um principal ou conjunto de principais federados, execute o seguinte comando. Para saber mais sobre os identificadores principais da federação de identidade da carga de trabalho, consulte Tipos de principal.

Por assunto

gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \
    --role=roles/iam.workloadIdentityUser \
    --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT"

Por grupo

gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \
    --role=roles/iam.workloadIdentityUser \
    --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP"

Por atributo

gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \
    --role=roles/iam.workloadIdentityUser \
    --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE"

Substitua:

  • SERVICE_ACCOUNT_EMAIL: o endereço de e-mail da conta de serviço
  • PROJECT_NUMBER: o número do projeto que contém o pool de Identidade da carga de trabalho
  • POOL_ID: o ID do pool de identidade da carga de trabalho
  • SUBJECT: o valor esperado do atributo mapeado para google.subject
  • GROUP: o valor esperado do atributo mapeado para google.groups
  • ATTRIBUTE_NAME: o nome de um atributo personalizado no seu mapeamento de atributos
  • ATTRIBUTE_VALUE: o valor do atributo personalizado no seu mapeamento de atributos

Baixar uma configuração de credencial

Nesta seção, descrevemos como baixar a configuração de credencial usando o console doCloud de Confiance .

Para permitir que sua carga de trabalho acesse as bibliotecas de cliente, primeiro baixe e configure o Application Default Credentials (ADC) conforme a seguir:

  1. No console do Cloud de Confiance , acesse a página Pools de Identidade da carga de trabalho.

    Acesse Pools de identidade da carga de trabalho
  2. Na tabela, selecione o pool para acessar a página de detalhes dele.

  3. Clique em Conceder acesso.

  4. Selecione Conceder acesso usando identidades federadas (recomendado)

  5. Para baixar o Application Default Credentials (ADC) para que sua carga de trabalho possa acessar as bibliotecas de cliente, faça isto:

    1. Clique em Baixar configuração.

    2. Na caixa de diálogo Configurar seu aplicativo, faça isto:

      1. Na lista suspensa Provedor, selecione seu provedor.

      2. No Caminho do token OIDC ou no caminho da declaração SAML, insira o caminho em que o token ou a declaração está localizado.

      3. Na lista suspensa Tipo de formato, selecione o formato.

    3. Clique em Baixar configuração e anote o caminho em que você salvou o arquivo.

Criar uma configuração de credencial

As bibliotecas de cliente do Cloud, a CLI gcloud e o Terraform podem receber credenciais externas automaticamente e usá-las para acessar o Cloud de Confiance. Para permitir que bibliotecas e ferramentas concluam esse processo, você precisa fornecer um arquivo de configuração de credenciais. Esse arquivo define o seguinte:

  • De onde receber credenciais externas
  • Qual pool de Identidade da carga de trabalho e provedor usar
  • Qual conta de serviço representar, se você usa a identidade temporária de conta de serviço

As bibliotecas de cliente do Cloud recebem credenciais externas de um arquivo local, um URL HTTP, executando um executável local:

  • Credenciais de execução executável: as bibliotecas iniciam um executável sempre que precisam de uma nova credencial. Se o executável conseguir uma nova credencial externa, ele precisará gravar um documento JSON em STDOUT semelhante a este:

    OIDC

    {
      "version": 1,
      "success": true,
      "token_type": "urn:ietf:params:oauth:token-type:id_token",
      "id_token": "HEADER.PAYLOAD.SIGNATURE",
      "expiration_time": 1620499962
    }
    

    Se o executável não conseguir uma nova credencial, ele precisará gravar um documento JSON em STDOUT semelhante a este:

    {
      "version": 1,
      "success": false,
      "code": "401",
      "message": "Caller not authorized."
    }
    

    Os documentos JSON usam os seguintes campos:

    • version: a versão da saída JSON. Apenas a versão 1 é compatível.
    • success: o status da resposta.

      Quando true, a resposta precisa conter os campos id_token e token_type. O executável precisa sair com o código de saída 0.

      Quando false, a resposta precisa conter os campos code e message e sair com um valor diferente de zero.

    • token_type: o tipo de token da credencial externa. Os valores aceitos são

      • urn:ietf:params:oauth:token-type:id_token
      • urn:ietf:params:oauth:token-type:jwt
    • id_token: a credencial externa.

    • expiration_time: o prazo de validade do token OIDC em segundos (época Unix). Esse campo só é necessário quando um arquivo de saída é especificado na configuração da credencial.

    • code: a string do código de erro.

    • message: a mensagem de erro

    SAML

    {
      "version": 1,
      "success": true,
      "token_type": "urn:ietf:params:oauth:token-type:saml2",
      "saml_response": "...",
      "expiration_time": 1620499962
    }
    

    Se o executável não conseguir uma nova credencial, ele precisará gravar um documento JSON em STDOUT semelhante a este:

    {
      "version": 1,
      "success": false,
      "code": "401",
      "message": "Caller not authorized."
    }
    

    Os documentos JSON usam os seguintes campos:

    • version: a versão da saída JSON. Apenas a versão 1 é compatível.
    • success: o status da resposta.

      Quando true, a resposta precisa conter os campos id_token e token_type. O executável precisa sair com o código de saída 0.

      Quando false, a resposta precisa conter os campos code e message e sair com um valor diferente de zero.

    • token_type: o tipo de token da credencial externa. Precisa ser urn:ietf:params:oauth:token-type:saml2.

    • saml_response: a resposta SAML ou a declaração SAML codificada em base64.

    • expiration_time: o prazo de validade da declaração em segundos (época Unix). Esse campo só é necessário quando um arquivo de saída é especificado na configuração da credencial.

    • code: a string do código de erro.

    • message: a mensagem de erro

    Ao iniciar o executável, as bibliotecas de cliente definem as seguintes variáveis de ambiente:

    • GOOGLE_EXTERNAL_ACCOUNT_AUDIENCE: público-alvo da configuração de credenciais. Sempre presente.
    • GOOGLE_EXTERNAL_ACCOUNT_TOKEN_TYPE: tipo de token de assunto esperado. Sempre presente.
    • GOOGLE_EXTERNAL_ACCOUNT_IMPERSONATED_EMAIL: e-mail da conta de serviço Presente apenas quando a identidade temporária de conta de serviço é usada.
    • GOOGLE_EXTERNAL_ACCOUNT_OUTPUT_FILE: o local do arquivo de saída da configuração da credencial. Presente somente quando especificado na configuração de credencial.

    Para usar credenciais de origem executável, é necessário definir a variável de ambiente GOOGLE_EXTERNAL_ACCOUNT_ALLOW_EXECUTABLES como 1.

  • Credenciais fornecidas pelo arquivo: as bibliotecas leem a credencial externa de um arquivo de texto simples local ou JSON. Por exemplo:

    JSON

    {
      "mytoken": "ey...
    }
    

    Se você usar a delegação de ator (pré-lançamento), o arquivo JSON precisará incluir campos separados para o token de assunto e o token de ator:

    {
      "subject_token": "ey...",
      "actor_token": "ey..."
    }
    

    As configurações de credenciais que usam delegação de ator (actor_token_field_name e actor_token_type) são compatíveis apenas com a biblioteca de autenticação do Google para Java.

    Texto

    ey...
    

    A credencial externa pode ser:

    • um token OIDC;
    • uma resposta SAML;
    • uma declaração SAML codificada em Base64.

    É necessário atualizar o arquivo periodicamente para que ele sempre tenha uma credencial válida. Por exemplo, se o token OIDC ou declaração SAML for válido por uma hora, atualize o arquivo pelo menos uma vez por hora.

  • Credenciais fornecidas pelo URL: as bibliotecas executam uma solicitação GET para um endpoint HTTP sempre que precisam de uma nova credencial. O endpoint precisa retornar um texto simples ou uma resposta JSON equivalente ao formato usado pelas credenciais fornecidas pelo arquivo.

Para criar um arquivo de configuração de credencial, faça o seguinte:

Credenciais de origem executáveis

gcloud iam workload-identity-pools create-cred-config \
    projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/WORKLOAD_PROVIDER_ID \
    --service-account=SERVICE_ACCOUNT_EMAIL \
    --service-account-token-lifetime-seconds=SERVICE_ACCOUNT_TOKEN_LIFETIME \
    --sts-location=REGION \
    --output-file=FILEPATH.json \
    --executable-command=EXECUTABLE_COMMAND \
    --executable-timeout-millis=EXECUTABLE_TIMEOUT \
    --executable-output-file=EXECUTABLE_OUTPUT_FILE

Substitua:

  • PROJECT_NUMBER: o número do projeto que contém o pool de Identidade da carga de trabalho
  • POOL_ID: o ID do pool de Identidade da carga de trabalho
  • WORKLOAD_PROVIDER_ID: o ID do provedor do pool de Identidade da carga de trabalho
  • SERVICE_ACCOUNT_EMAIL: se você usa a identidade temporária de conta de serviço, substitua pelo endereço de e-mail da conta de serviço. Omita essa flag se você não usa a identidade temporária de conta de serviço.
  • SERVICE_ACCOUNT_TOKEN_LIFETIME: se você usa a identidade temporária de conta de serviço, substitua pelo ciclo de vida do token de acesso à conta de serviço, em segundos. Quando não informado, o padrão é uma hora. Omita essa flag se você não usa a identidade temporária de conta de serviço. Para especificar um ciclo de vida com mais de uma hora, configure a restrição da política da organização constraints/iam.allowServiceAccountCredentialLifetimeExtension.
  • REGION: opcional. Especifique a região dos endpoints regionais do Security Token Service, se estiverem disponíveis.
  • FILEPATH: o arquivo em que a configuração será salva.
  • EXECUTABLE_COMMAND: o comando completo, incluindo argumentos, a ser executado para recuperar o token de ID do OIDC. Por exemplo, --executable-command="/path/to/command --foo=bar".
  • EXECUTABLE_TIMEOUT: a duração opcional em milissegundos para aguardar a execução do executável (o padrão é 30s).
  • EXECUTABLE_OUTPUT_FILE: um caminho que aponta para as credenciais 3PI geradas pelo executável. Isso é útil para armazenar as credenciais em cache. Ao especificar esse caminho, as bibliotecas do Auth verificam a existência dele antes de executar o executável.

Credenciais fornecidas pelo arquivo

gcloud iam workload-identity-pools create-cred-config \
    projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/WORKLOAD_PROVIDER_ID \
    --service-account=SERVICE_ACCOUNT_EMAIL \
    --service-account-token-lifetime-seconds=SERVICE_ACCOUNT_TOKEN_LIFETIME \
    --sts-location=REGION \
    --output-file=FILEPATH.json \
    --credential-source-file=TOKEN_FILEPATH \
    --credential-source-type=SOURCE_TYPE \
    --credential-source-field-name=FIELD_NAME \
    --actor-token-field-name=ACTOR_FIELD_NAME \
    --actor-token-type=ACTOR_TOKEN_TYPE \
    --credential-cert-path=WORKLOAD_CERTIFICATE_PATH \
    --credential-cert-private-key-path=WORKLOAD_KEY_PATH \
    --credential-cert-configuration-output-file=CERT_CONFIG_FILEPATH

Substitua:

  • PROJECT_NUMBER: o número do projeto que contém o pool de Identidade da carga de trabalho
  • POOL_ID: o ID do pool de Identidade da carga de trabalho
  • WORKLOAD_PROVIDER_ID: o ID do provedor do pool de Identidade da carga de trabalho
  • SERVICE_ACCOUNT_EMAIL: se você usa a identidade temporária de conta de serviço, substitua pelo endereço de e-mail da conta de serviço. Omita essa flag se você não usa a identidade temporária de conta de serviço.
  • SERVICE_ACCOUNT_TOKEN_LIFETIME: se você usa a identidade temporária de conta de serviço, substitua pelo ciclo de vida do token de acesso à conta de serviço, em segundos. Quando não informado, o padrão é uma hora. Omita essa flag se você não usa a identidade temporária de conta de serviço. Para especificar um ciclo de vida com mais de uma hora, configure a restrição da política da organização constraints/iam.allowServiceAccountCredentialLifetimeExtension.
  • REGION: opcional. Especifique a região dos endpoints regionais do Security Token Service, se estiverem disponíveis.
  • FILEPATH: o arquivo em que a configuração será salva.
  • TOKEN_FILEPATH: caminho em que os tokens de ID do OIDC são armazenados.
  • SOURCE_TYPE: formato do arquivo de token de ID do OIDC, definido como text (padrão) ou json. Se a flag --actor-token-field-name for especificada, ela precisará ser definida como json.
  • FIELD_NAME: campo no arquivo de texto que contém o token (se SOURCE_TYPE for json)
  • ACTOR_FIELD_NAME (pré-lançamento): opcional. Se você usar a delegação de ator, especifique o campo no arquivo JSON (TOKEN_FILEPATH) que contém o token de ator. Ele precisa ser diferente de FIELD_NAME. Omita essa flag se você não usa a delegação de ator.
  • ACTOR_TOKEN_TYPE (pré-lançamento): opcional. O tipo de token do ator quando a flag --actor-token-field-name é especificada. O padrão é urn:ietf:params:oauth:token-type:jwt. Omita essa flag se você não usa a delegação de ator.
  • WORKLOAD_CERTIFICATE_PATH (pré-lançamento): opcional. Se você usar tokens vinculados a certificados, especifique o caminho para o arquivo de certificado de folha X.509 codificado em PEM da carga de trabalho. Quando essa flag é especificada, a CLI gcloud configura endpoints mTLS (sts.mtls.googleapis.com e iamcredentials.mtls.googleapis.com) e gera um arquivo de configuração de certificado.
  • WORKLOAD_KEY_PATH (pré-lançamento): opcional. O caminho para o arquivo de chave privada codificado em PEM do certificado X.509 da carga de trabalho. Se a flag --credential-cert-path for especificada, essa flag será obrigatória.
  • CERT_CONFIG_FILEPATH (pré-lançamento): opcional. Um caminho de saída personalizado para o arquivo de configuração de certificado gerado. Se você omitir essa flag e especificar a flag --credential-cert-path, a CLI gcloud vai gravar certificate_config.json no local de configuração padrão da CLI gcloud (~/.config/gcloud/certificate_config.json no Linux e no macOS ou %APPDATA%\gcloud\certificate_config.json no Windows).

As configurações de credenciais resultantes que incluem delegação de ator usando as flags --actor-token-field-name e --actor-token-type são compatíveis apenas com a Biblioteca de autenticação do Google para Java.

Credenciais fornecidas pelo URL

gcloud iam workload-identity-pools create-cred-config \
    projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/WORKLOAD_PROVIDER_ID \
    --service-account=SERVICE_ACCOUNT_EMAIL \
    --service-account-token-lifetime-seconds=SERVICE_ACCOUNT_TOKEN_LIFETIME \
    --sts-location=REGION \
    --output-file=FILEPATH.json \
    --credential-source-url="TOKEN_URL" \
    --credential-source-headers="KEY_1=VALUE_1,KEY_2=VALUE_2" \
    --credential-source-type=SOURCE_TYPE \
    --credential-source-field-name=FIELD_NAME

Substitua:

  • PROJECT_NUMBER: o número do projeto que contém o pool de Identidade da carga de trabalho.
  • POOL_ID: ID do pool de Identidade da carga de trabalho.
  • WORKLOAD_PROVIDER_ID: ID do provedor do pool de Identidade da carga de trabalho
  • SERVICE_ACCOUNT_EMAIL: se você usa a identidade temporária de conta de serviço, substitua pelo endereço de e-mail da conta de serviço. Omita essa flag se você não usa a identidade temporária de conta de serviço.
  • SERVICE_ACCOUNT_TOKEN_LIFETIME: se você usa a identidade temporária de conta de serviço, substitua pelo ciclo de vida do token de acesso à conta de serviço, em segundos. Quando não informado, o padrão é uma hora. Omita essa flag se você não usa a identidade temporária de conta de serviço. Para especificar um ciclo de vida com mais de uma hora, configure a restrição da política da organização constraints/iam.allowServiceAccountCredentialLifetimeExtension.
  • REGION: opcional. Especifique a região dos endpoints regionais do Security Token Service, se estiverem disponíveis.
  • FILEPATH: o arquivo em que a configuração será salva.
  • TOKEN_URL: URL do qual o token de ID do OIDC será recuperado
  • KEY_n, VALUE_n: cabeçalhos personalizados para incluir na solicitação HTTP para TOKEN_URL
  • SOURCE_TYPE: formato do arquivo de token de ID do OIDC, definido como text (padrão) ou json
  • FIELD_NAME: campo no arquivo de texto que contém o token (se SOURCE_TYPE for json)

Usar a configuração de credencial para acessar o Cloud de Confiance

Para permitir que as ferramentas e as bibliotecas de cliente usem a configuração da sua credencial, faça o seguinte:

  1. Inicialize uma variável de ambiente GOOGLE_APPLICATION_CREDENTIALS e aponte-a para o arquivo de configuração de credenciais:

    Bash

      export GOOGLE_APPLICATION_CREDENTIALS=`pwd`/FILEPATH.json
      
    em que FILEPATH é o caminho relativo do arquivo de configuração de credenciais.

    PowerShell

      $env:GOOGLE_APPLICATION_CREDENTIALS = Resolve-Path 'FILEPATH.json'
      
    em que FILEPATH é o caminho relativo do arquivo de configuração de credenciais.
  2. Use uma biblioteca de cliente ou ferramenta compatível com a federação de identidade da carga de trabalho e que possa encontrar credenciais automaticamente:

    C++

    As bibliotecas de cliente doCloud de Confiance para C++ são compatíveis com a federação de identidade da carga de trabalho desde a versão v2.6.0. Para usar a federação de identidade da carga de trabalho, crie as bibliotecas de cliente com a versão 1.36.0 ou mais recente do gRPC.

    Go

    As bibliotecas de cliente do Go são compatíveis com a federação de identidade da carga de trabalho se usarem a versão v0.0.0-20210218202405-ba52d332ba99 ou posteriores do módulo golang.org/x/oauth2.

    Para verificar qual versão deste módulo sua biblioteca de cliente usa, execute os seguintes comandos:

    cd $GOPATH/src/cloud.google.com/go
    go list -m golang.org/x/oauth2
    

    Java

    As bibliotecas de cliente do Java aceitam federação de identidade da carga de trabalho se usarem a versão 0.24.0 ou posteriores do artefato com.google.auth:google-auth-library-oauth2-http.

    Para verificar qual versão desse artefato a biblioteca de cliente usa, execute o seguinte comando do Maven no diretório do aplicativo:

    mvn dependency:list -DincludeArtifactIds=google-auth-library-oauth2-http
    

    Node.js

    As bibliotecas de cliente do Node.js são compatíveis com a federação de identidade da carga de trabalho se usarem a versão 7.0.2 ou posteriores do pacote google-auth-library.

    Para verificar qual versão desse pacote sua biblioteca de cliente usa, execute o seguinte comando no diretório do seu aplicativo:

    npm list google-auth-library
    

    Ao criar um objeto GoogleAuth, é possível especificar um ID de projeto ou permitir que GoogleAuth encontre o ID do projeto automaticamente. Para encontrar o ID do projeto automaticamente, a conta de serviço no arquivo de configuração precisa ter o papel de navegador (roles/browser), ou um papel com permissões equivalentes no projeto. Para ver detalhes, consulte o README do pacote google-auth-library.

    Python

    As bibliotecas de cliente do Python são compatíveis com a federação de identidade da carga de trabalho se usarem a versão 1.27.0 ou posteriores do pacote google-auth.

    Para verificar qual versão desse pacote sua biblioteca de cliente usa, execute o seguinte comando no ambiente em que o pacote está instalado:

    pip show google-auth
    

    Para especificar um ID de projeto para o cliente de autenticação, defina a variável de ambiente GOOGLE_CLOUD_PROJECT ou permita que o cliente encontre o ID do projeto automaticamente. Para encontrar o ID do projeto automaticamente, a conta de serviço no arquivo de configuração precisa ter o papel de Navegador (roles/browser) ou um papel com permissões equivalentes no projeto. Para ver detalhes, consulte o guia do usuário do pacote google-auth.

    gcloud

    Para autenticar usando a federação de identidade da carga de trabalho, use o comando gcloud auth login:

    gcloud auth login --cred-file=FILEPATH.json
    

    Substitua FILEPATH pelo caminho para o arquivo de configuração de credencial.

    O suporte para a federação de identidade da carga de trabalho na gcloud CLI está disponível na versão 363.0.0 e posteriores da gcloud CLI.

    Terraform

    O provedor doCloud de Confiance é compatível com a federação de identidade da carga de trabalho se você usar a versão 3.61.0 ou posterior:

    terraform {
      required_providers {
        google = {
          source  = "hashicorp/google"
          version = "~> 3.61.0"
        }
      }
    }
    

    bq

    Para autenticar usando a federação de identidade da carga de trabalho, use o comando gcloud auth login da seguinte maneira:

    gcloud auth login --cred-file=FILEPATH.json
    

    Substitua FILEPATH pelo caminho para o arquivo de configuração de credencial.

    O suporte para a federação de identidade da carga de trabalho no bq está disponível na versão 390.0.0 e posteriores da gcloud CLI.

A seguir