Permita que os clientes acedam aos respetivos recursos de Trusted Cloud by S3NS a partir do seu produto ou serviço

Este documento descreve os requisitos e as práticas recomendadas que pode seguir para permitir que os clientes usem o seu produto para aceder aos respetivos recursos no Trusted Cloud sem usar chaves de contas de serviço.

Se oferecer um produto ou operar um serviço que permita aos clientes analisar ou gerir dados ou recursos, os seus clientes podem querer aceder a dados ou outros recursos no respetivo ambiente Trusted Cloud . Seguem-se alguns exemplos de produtos e serviços deste tipo:

  • Produtos de estatísticas de dados: os seus clientes podem querer usar estes produtos para analisar os respetivos dados no BigQuery.
  • Produtos e serviços de CI/CD: os seus clientes podem usar estes serviços para implementar infraestruturas e aplicações nos respetivos Trusted Cloud projetos.
  • Automatização de processos robóticos (RPA): os seus clientes podem usar a RPA para fluxos de trabalho, como criar projetos, gerir o acesso ou automatizar tarefas administrativas no Trusted Cloud.

Para autenticar produtos no local ou de software como serviço (SaaS) para Trusted Cloud, os clientes têm usado convencionalmente chaves de contas de serviço, mas estas chaves podem ser difíceis de gerir e armazenar em segurança.

Enquanto fornecedor de um produto no local ou SaaS, pode ajudar os seus clientes a proteger os respetivos recursos permitindo-lhes usar a Workload Identity Federation para aceder aos respetivos recursos. Trusted Cloud Trusted Cloud Exemplos de serviços que já permitem que os respetivos clientes usem a Workload Identity Federation incluem o Terraform Cloud, o GitHub e o GitLab

Este documento descreve como pode estender o seu produto para suportar a Workload Identity Federation e descreve as práticas recomendadas que pode seguir. Este documento pressupõe que está familiarizado com a federação de identidade da carga de trabalho e o OpenID Connect.

Arquitetura

A intenção da federação de identidades da carga de trabalho é remover a necessidade de chaves de contas de serviço, permitindo que os seus clientes federem o seu produto ou serviço com o respetivo ambienteTrusted Cloud . Os seus clientes podem, então, aceder aos respetivos Trusted Cloud recursos através de uma identidade reivindicada pelo seu produto ou serviço.

Para permitir que os seus clientes usem a Workload Identity Federation, o seu produto ou serviço tem de implementar um subconjunto do OpenID Connect. Em particular, tem de permitir que as cargas de trabalho obtenham um token de ID que cumpra os seguintes critérios:

  • O token identifica a carga de trabalho no seu produto ou plataforma
  • O token identifica a instância, o inquilino ou a instalação do seu produto ou plataforma
  • O token contém uma assinatura criptográfica que a Workload Identity Federation pode usar para validar a autenticidade do token

Requisitos

Para suportar a Workload Identity Federation, tem de garantir que o seu produto ou serviço cumpre os seguintes requisitos:

  1. As cargas de trabalho têm acesso a um token de ID válido.

    Em qualquer altura durante o respetivo ciclo de vida, uma carga de trabalho tem de ter acesso a um token de ID que afirme a identidade da carga de trabalho e esteja em conformidade com os requisitos definidos pela OpenID Connect 1.0.

    Uma vez que os tokens de ID têm uma duração limitada, tem de garantir que um token de ID sobrevive à respetiva carga de trabalho ou que as cargas de trabalho podem obter periodicamente novos tokens de ID.

  2. Os tokens de ID identificam exclusivamente a carga de trabalho.

    O token de ID tem de conter, pelo menos, uma reivindicação que identifique exclusivamente a carga de trabalho. O identificador da carga de trabalho tem de ser imutável.

    Para produtos ou serviços que suportam a multi-posse, o token também tem de conter, pelo menos, uma reivindicação que identifique o inquilino de forma exclusiva. O identificador do inquilino também tem de ser imutável.

  3. Os tokens de ID estão assinados, mas não encriptados.

  4. Os metadados do fornecedor OpenID são acessíveis publicamente e podem ser descobertos a partir de tokens de ID.

    Tem de fornecer um documento de configuração do fornecedor OpenID num ponto final acessível publicamente que possa ser descoberto através do protocolo de descoberta do emissor OpenID. Por exemplo, se os tokens de ID contiverem uma reivindicação iss com o valor https://service.example.com/v1/, tem de fornecer um documento de configuração do fornecedor OpenID em https://service.example.com/v1/.well-known/openid-configuration e o ponto final tem de estar acessível publicamente através da Internet a partir de qualquer endereço IP.

  5. As chaves de assinatura são acessíveis publicamente e podem ser descobertas a partir dos metadados do fornecedor OpenID.

    Tem de fornecer um documento JSON Web Key Set (JWKS) num ponto final acessível publicamente que possa ser descoberto a partir do campo jwks_uri nos metadados do fornecedor OpenID.

Práticas recomendadas

Quando expandir o seu produto ou serviço para suportar a federação de identidades da carga de trabalho, tenha em atenção as seguintes práticas recomendadas.

Práticas recomendadas:

Distinga entre tokens de identidade e de acesso.
Exponha tokens de ID de uma forma compatível com as bibliotecas de cliente.
Use URLs de emissor específicos do inquilino.
Permita que os utilizadores especifiquem o público-alvo do token de ID.
Use identificadores imutáveis e não reutilizáveis em reivindicações de tokens de ID.
Inclua informações de contexto nos tokens de ID.
Limite a duração do token de ID a 30 a 60 minutos.

Distinguir entre tokens de identidade e de acesso

No contexto da Workload Identity Federation, a finalidade de um token de ID é afirmar a identidade da carga de trabalho: o token tem de conter informações suficientes para que a Workload Identity Federation identifique a carga de trabalho e a distinga de outras cargas de trabalho.

Ao contrário dos tokens de ID, os tokens de acesso servem normalmente um propósito diferente: são usados para tomar decisões de acesso e podem conter informações sobre que autorizações uma carga de trabalho tem ou a que APIs tem permissão para aceder.

Se o seu produto ou serviço usar tokens de acesso para fins como permitir que as cargas de trabalho chamem a API do seu produto, estes tokens de acesso podem não ser adequados para a Federação de identidades de cargas de trabalho. Em vez de reutilizar tokens de acesso como tokens de ID, considere introduzir um segundo tipo de token que corresponda à definição de um token de ID e permitir que as cargas de trabalho usem o token de ID para a Workload Identity Federation.

Exponha tokens de ID de uma forma compatível com as bibliotecas de cliente

As Trusted Cloud bibliotecas cliente podem obter automaticamente tokens de ID de várias origens, incluindo as seguintes:

  • Um ponto final de HTTP (credenciais provenientes de URL)
  • Um ficheiro local (credenciais provenientes de ficheiros)

Para obter tokens de ID de outras origens, os seus clientes podem ter de modificar o respetivo código ou implementar ferramentas ou bibliotecas adicionais. Ao expor tokens de ID de uma forma compatível com as bibliotecas cliente, pode evitar essa complexidade adicional e facilitar a adoção da Workload Identity Federation por parte dos seus clientes.

Use URLs de emissor específicos do inquilino

As reivindicações incorporadas no token de ID de uma carga de trabalho podem ser exclusivas numa instância específica do seu produto ou serviço, mas podem não ser exclusivas em várias instâncias do seu produto ou serviço. Por exemplo, dois dos seus clientes podem usar o seu produto ou serviço para implementar uma carga de trabalho e atribuir inadvertidamente a essas cargas de trabalho o mesmo nome e ID.

A Workload Identity Federation tenta compensar esta possível falta de exclusividade validando o URL do emissor (iss) dos tokens de ID e permitindo apenas tokens de um único emissor por Workload Identity Pool.

Se o seu produto ou serviço suportar a multi-posse, vários dos seus clientes podem partilhar uma única instância do seu produto ou serviço, e os tokens de ID das respetivas cargas de trabalho podem usar o mesmo URL do emissor. A utilização do mesmo URL do emissor em vários inquilinos pode expor os seus clientes a ataques de roubo de identidade: por exemplo, um ator malicioso pode criar uma carga de trabalho no respetivo inquilino, atribuir-lhe o mesmo ID ou nome que uma carga de trabalho no inquilino da vítima e usar o token de ID da respetiva carga de trabalho para roubar a identidade da carga de trabalho da vítima.

Para ajudar a proteger os seus clientes contra ataques de spoofing, evite usar os mesmos URLs do emissor em vários inquilinos e incorpore um ID de inquilino único no URL do emissor, por exemplo, https://saas.example.com/tenant-123/.

Permitir que os utilizadores especifiquem o público-alvo do token de ID

Algumas das cargas de trabalho do seu cliente podem ter de aceder Trusted Cloud bem como a outros serviços de terceiros. Quando os clientes decidem federar o seu produto ou serviço com várias entidades fidedignas, podem encontrar-se numa situação em que o token de ID de uma carga de trabalho é usado inadvertidamente ou maliciosamente para a entidade fidedigna errada. Por exemplo, um ator malicioso pode enganar uma carga de trabalho para revelar um token de ID destinado a um serviço de terceiros e, em seguida, usar esse token de ID para a Federação de identidades de cargas de trabalho.

Para ajudar a evitar que os seus clientes sejam vítimas de ataques de confused deputy, evite usar um público-alvo estático (afirmação aud) em tokens de ID. Em alternativa, permita que as cargas de trabalho especifiquem um público-alvo quando obtêm um token de ID e, opcionalmente, mantenha uma lista de autorizações para públicos-alvo que as cargas de trabalho podem pedir.

Por predefinição, a Workload Identity Federation espera que o público-alvo de um token de ID corresponda ao URL https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID. Certifique-se de que as cargas de trabalho podem usar um URL como público-alvo para tokens de ID e que o comprimento do URL do público-alvo é inferior a 180 carateres.

Use identificadores imutáveis e não reutilizáveis em reivindicações de tokens de ID

Quando os clientes querem conceder a uma das respetivas cargas de trabalho acesso a recursos do Trusted Cloud, têm de criar uma associação do IAM que faça referência à identidade da carga de trabalho por assunto, grupo ou um atributo personalizado. O assunto, o grupo e os atributos personalizados da identidade da carga de trabalho são derivados das reivindicações no token de ID da carga de trabalho.

Se um cliente criar uma associação do IAM que faça referência a uma reivindicação mutável, a respetiva carga de trabalho pode perder acidentalmente o acesso quando o valor da reivindicação mudar. Por exemplo, um cliente pode criar uma associação do IAM que faça referência ao nome da respetiva carga de trabalho. Se, posteriormente, mudar o nome da carga de trabalho, a associação do IAM pode deixar de se aplicar.

Pior ainda, os autores de ameaças podem tentar obter acesso não autorizado a outros recursos ao mudar deliberadamente o nome das cargas de trabalho ou modificar o ambiente de uma carga de trabalho para roubar a identidade de outra carga de trabalho.

Para ajudar os clientes a evitar estes problemas de roubo de identidade, certifique-se de que os tokens de ID contêm identificadores imutáveis e que não podem ser reutilizados.

Inclua informações de contexto nos tokens de ID

Em vez de conceder acesso incondicional às cargas de trabalho aos recursos do Trusted Cloud , os clientes podem querer restringir o acesso para que uma carga de trabalho só possa obter credenciais Google quando forem cumpridos determinados critérios adicionais.

Para permitir que os clientes configurem essas restrições, inclua reivindicações adicionais no token de ID que contenham informações de contexto. Exemplos de informações de contexto:

  • Informações sobre o utilizador que é proprietário ou iniciou a carga de trabalho
  • O motivo e a forma como a carga de trabalho foi iniciada
  • O pedido que está a ser processado pela carga de trabalho

Os clientes podem usar estas reivindicações para configurar condições de atributos ou em identificadores principais.

Limite a duração do token de ID a 60 minutos

Os tokens de ID têm uma duração limitada determinada pela reivindicação exp. Quando uma carga de trabalho usa um token de ID para fazer uma troca de tokens, a federação de identidade da carga de trabalho valida a reivindicação exp do token de ID e emite um token do STS válido durante o tempo do token de entrada, mas, no máximo, durante 1 hora.

A utilização de tokens de ID válidos durante mais de uma hora não tem qualquer efeito na Workload Identity Federation, mas pode aumentar os riscos se um token de ID for divulgado acidentalmente. A utilização de uma duração significativamente inferior a 1 hora pode ajudar a reduzir esses riscos, mas pode levar a trocas de tokens frequentes e a um desempenho reduzido.

O que se segue?