Se você oferece um produto ou opera um serviço que permite aos clientes analisar ou gerenciar dados ou recursos, eles podem querer acessar dados ou outros recursos no ambiente do Google Cloud deles. Veja alguns exemplos desses produtos e serviços:
- Produtos de análise de dados: talvez os clientes queiram usar esses produtos para analisar os dados no BigQuery.
- Produtos e serviços de CI/CD: seus clientes podem usar esses serviços para implantar a infraestrutura e os aplicativos nos projetos do Google Cloud deles.
- Automação de processos robóticos (RPA): seus clientes podem usar a RPA para fluxos de trabalho como criação de projetos, gerenciamento de acesso ou automação de tarefas administrativas no Google Cloud.
Para autenticar produtos no local ou de software como serviço (SaaS) no Google Cloud, os clientes geralmente dependem de chaves de conta de serviço, mas elas podem ser difíceis de gerenciar e armazenar com segurança.
Como fornecedor de um produto no local ou SaaS, é possível ajudar seus clientes a proteger os recursos do Google Cloud permitindo que eles usem a federação de identidade da carga de trabalho para acessar os recursos do Google Cloud. Exemplos de serviços que já permitem que os clientes usem a federação de identidade da carga de trabalho incluem Terraform Cloud, GitHub e GitLab
Neste artigo, descrevemos como é possível estender seu produto para dar suporte à federação de identidade da carga de trabalho e as práticas recomendadas que você pode seguir. Neste artigo, pressupomos que você esteja familiarizado com a federação de identidade da carga de trabalho e OpenID Connect.
Arquitetura
A intenção da federação de identidade da carga de trabalho é remover a necessidade de chaves da conta de serviço, permitindo que seus clientes façam a federação do produto ou serviço com o ambiente do Google Cloud deles. Os clientes podem acessar os recursos do Google Cloud usando uma identidade declarada pelo produto ou serviço.
Para permitir que seus clientes usem a federação de identidade da carga de trabalho, o produto ou serviço precisa implementar um subconjunto do OpenID Connect. Especificamente, permita que as cargas de trabalho recebam um token de ID que atenda aos seguintes critérios:
- O token identifica a carga de trabalho no seu produto ou plataforma
- O token identifica a instância, o locatário ou a instalação do produto ou plataforma
- O token contém uma assinatura criptográfica que a federação de identidade da carga de trabalho pode usar para verificar a autenticidade do token
Requisitos
Para oferecer suporte à federação de identidade da carga de trabalho, verifique se o produto ou serviço atende aos seguintes requisitos:
As cargas de trabalho têm acesso a um token de ID válido.
A qualquer momento durante o ciclo de vida, uma carga de trabalho precisa ter acesso a um token de ID que confirme a identidade da carga de trabalho e esteja em conformidade com os requisitos definidos pelo OpenID Connect 1.0.
Como os tokens de ID têm uma vida útil limitada, você precisa garantir que um token de ID sobreviva à respectiva carga de trabalho ou que as cargas de trabalho possam receber novos tokens de ID periodicamente.
Os tokens de ID identificam exclusivamente a carga de trabalho.
O token de ID precisa conter pelo menos uma declaração que identifique exclusivamente a carga de trabalho. O identificador da carga de trabalho precisa ser imutável.
Para produtos ou serviços compatíveis com multilocação, o token também precisa conter pelo menos uma declaração que identifique o locatário de maneira exclusiva. O identificador de locatário também precisa ser imutável.
Os tokens de ID são assinados, mas não criptografados.
Os metadados do provedor OpenID são acessíveis publicamente e podem ser descobertos a partir de tokens de ID.
Forneça um documento de configuração do provedor OpenID em um endpoint acessível publicamente que possa ser descoberto usando o protocolo de descoberta do emissor do OpenID. Por exemplo, se os tokens de ID contiverem uma declaração
isscom o valorhttps://service.example.com/v1/, será necessário fornecer um documento de configuração do provedor OpenID emhttps://service.example.com/v1/.well-known/openid-configuration, e o endpoint precisará ser acessíveis publicamente pela Internet a partir de qualquer endereço IP.As chaves de assinatura são acessíveis publicamente e podem ser descobertas nos metadados do provedor OpenID.
Forneça um documento conjunto de chaves da Web JSON (JWKS, na sigla em inglês) em um endpoint acessível publicamente que possa ser descoberto no campo
jwks_urinos metadados do provedor OpenID.
Práticas recomendadas
Ao estender seu produto ou serviço para oferecer suporte à federação de identidade da carga de trabalho, considere as práticas recomendadas a seguir.
Práticas recomendadas:
Diferenciar os tokens de identidade e de acesso.Expor tokens de ID de maneira compatível com bibliotecas de cliente.
Usar URLs do emissor específicos de locatário.
Permitir que os usuários especifiquem o público do token de ID.
Usar identificadores imutáveis e não reutilizáveis em declarações de token de ID.
Incluir informações de contexto em tokens de ID.
Limitar a vida útil do token de ID a 30-60 minutos.
Diferenciar os tokens de identidade e de acesso
No contexto da federação de identidade da carga de trabalho, o propósito de um token de ID é declarar a identidade da carga de trabalho: o token precisa conter informações suficientes para a federação de identidade da carga de trabalho, para identificá-la e distingui-la de outras cargas de trabalho.
Os tokens de acesso geralmente têm uma finalidade diferente dos tokens de ID: são usados para tomar decisões de acesso e podem conter informações sobre quais permissões uma carga de trabalho tem ou quais APIs ela pode acessar.
Se o produto ou serviço usa tokens de acesso para finalidades como permitir que as cargas de trabalho chamem a API do produto, esses tokens de acesso podem não ser adequados para a federação de identidade da carga 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 federação de identidade da carga de trabalho.
Expor tokens de ID de maneira compatível com bibliotecas de cliente
As bibliotecas de cliente do Google Cloud podem receber tokens de ID automaticamente de várias fontes, incluindo:
- Um endpoint HTTP (credenciais fornecidas pelo URL)
- Um arquivo local (credenciais originadas do arquivo)
Para receber tokens de ID de outras fontes, seus clientes podem precisar modificar o código ou implantar outras ferramentas ou bibliotecas. Se os tokens de ID forem expostos de maneira compatível com as bibliotecas de cliente, será possível evitar essa complexidade extra e facilitar a adoção da federação de identidade da carga de trabalho para seus clientes.
Usar URLs do emissor específicos de locatário
As declarações incorporadas no token de ID de uma carga de trabalho podem ser únicas em uma instância específica do seu produto ou serviço, mas podem não ser exclusivas em várias instâncias do produto ou serviço. Por exemplo, dois clientes podem usar seu produto ou serviço para implantar uma carga de trabalho e, acidentalmente, atribuir o mesmo nome e ID a essas cargas de trabalho.
A federação de identidade da carga de trabalho tenta compensar essa possível falta
de exclusividade verificando o URL do emissor (iss) dos tokens de ID e
permitindo apenas tokens de um único emissor por pool de identidades da carga de trabalho.
Se o produto ou serviço for compatível com multilocação, vários clientes poderão compartilhar uma única instância do produto ou serviço, e os tokens de ID das cargas de trabalho deles poderão usar o mesmo URL do emissor. O uso do mesmo URL do emissor em vários locatários pode expor seus clientes a ataques de spoofing: por exemplo, um usuário de má-fé pode criar uma carga de trabalho no próprio locatário dele, atribuir a ela o mesmo ID ou nome de carga de trabalho no locatário da vítima e usar o token de ID da carga de trabalho para falsificar a identidade da carga de trabalho da vítima.
Para ajudar a proteger os clientes contra ataques de spoofing, evite usar os mesmos URLs do emissor em vários locatários e incorpore um ID de locatário único no URL do emissor, por exemplo, https://saas.example.com/tenant-123/.
Permitir que os usuários especifiquem o público do token de ID
Algumas das cargas de trabalho do cliente talvez precisem acessar o Google Cloud e outros serviços de terceiros. Quando os clientes decidem federar seu produto ou serviço com várias partes confiáveis, eles talvez se deparem com uma situação em que o token de ID de uma carga de trabalho é usado inadvertida ou maliciosamente pela parte errada: por exemplo, um usuário de má-fé pode fazer com a carga de trabalho revele um token de ID destinado a um serviço de terceiros e usá-lo para a federação de identidade da carga de trabalho.
Para ajudar a evitar que seus clientes sejam vítimas de tais ataques de confused deputy, evite usar um público estático (declaração aud) em tokens de ID. Em vez disso, a prática deve ser permitir que as cargas de trabalho especifiquem um público ao receberem um token de ID e, opcionalmente, mantenham uma lista de permissões para os públicos que as cargas de trabalho podem solicitar.
Por padrão, a federação de identidade da carga de trabalho espera que o público de um token de ID corresponda ao URL https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID.
Verifique se as cargas de trabalho podem usar um URL como público para tokens de ID e se os públicos podem ter até 180 caracteres.
Usar identificadores imutáveis e não reutilizáveis em declarações de token de ID
Quando os clientes querem conceder a uma de suas cargas de trabalho acesso aos recursos do Google Cloud, eles precisam criar uma vinculação do IAM que faça referência à identidade da carga de trabalho por assunto, grupo ou atributo personalizado. O assunto, o grupo e os atributos personalizados da carga de trabalho são derivados das declarações no token de ID da carga de trabalho.
Se um cliente criar uma vinculação do IAM que faça referência a uma declaração mutável, o acesso da carga de trabalho poderá ser acidentalmente perdido quando o valor da declaração for alterado. Por exemplo, um cliente pode criar uma vinculação do IAM que faça referência ao nome da carga de trabalho. Se ele renomear a carga de trabalho, a vinculação do IAM poderá não ser mais aplicada.
Pior que isso, usuários de má-fé podem tentar conseguir acesso não autorizado a outros recursos renomeando deliberadamente cargas de trabalho ou modificando seu ambiente para falsificar a identidade de outra carga de trabalho.
Para ajudar os clientes a evitar problemas de spoofing, verifique se os tokens de ID contêm identificadores imutáveis e que não podem ser reutilizados.
Incluir informações de contexto em tokens de ID
Em vez de conceder às cargas de trabalho acesso incondicional aos recursos do Google Cloud, os clientes podem querer restringir o acesso para que a carga de trabalho só possa receber credenciais do Google quando determinados critérios adicionais forem atendidos.
Para permitir que os clientes configurem essas restrições, inclua outras declarações no token de ID que contenham informações de contexto. Exemplos de informações de contexto incluem:
- informações sobre o usuário que possui ou iniciou a carga de trabalho
- o motivo e como a carga de trabalho foi iniciada
- a solicitação que está sendo processada pela carga de trabalho
Os clientes podem usar essas declarações para configurar condições de atributo ou nos identificadores principais.
Limitar a vida útil do token de ID a 60 minutos
Os tokens de ID têm um ciclo de vida limitado determinado pela declaração exp. Quando uma carga de trabalho usa um token de ID para executar uma troca de token, a federação de identidade da carga de trabalho valida a declaração exp do token de ID e emite um token STS válido pelo mesmo período do token de entrada, mas com limite máximo de 1 hora.
O uso de tokens de ID válidos por mais de uma hora não afeta a federação de identidade da carga de trabalho, mas pode aumentar os riscos se um token de ID vazar acidentalmente. Optar por um ciclo de vida significativamente inferior a 1 hora pode ajudar a reduzir esses riscos, mas resultar em trocas de tokens frequentes e redução de desempenho.
A seguir
- Leia mais sobre a federação de identidades de carga de trabalho.
- Saiba mais sobre as práticas recomendadas para usar a federação de identidade da carga de trabalho.