Reduzir os riscos de semelhança de identidade em frotas multilocatárias

Nesta página, você encontra as práticas recomendadas para configurar e usar a federação de identidade da carga de trabalho da frota, um recurso que permite configurar centralmente a autenticação de aplicativos para APIs do Google Cloud em todos os projetos. Para conferir as práticas recomendadas sobre a adoção de outros recursos da frota, consulte Planejar recursos da frota.

Esta página é destinada a administradores e operadores de plataforma e engenheiros de segurança que querem minimizar os riscos associados à igualdade de identidade em frotas.

Antes de ler esta página, confira os conceitos em Sobre a federação de identidade da carga de trabalho da frota.

Terminologia

Esta página usa a seguinte terminologia:

  • Federação de identidade da carga de trabalho para o GKE: um recurso que fornece identidades para cargas de trabalho do GKE em um único projeto Google Cloud .
  • Federação de identidade da carga de trabalho da frota: um recurso que estende a federação de identidade da carga de trabalho para o GKE a cargas de trabalho em toda a frota, incluindo fora do Google Cloud e em vários projetos.
  • Pool de identidades da carga de trabalho: uma entidade que fornece identidades para cargas de trabalho em um formato compatível com o Identity and Access Management (IAM). Cada cluster é um provedor de identidade em um pool de identidades da carga de trabalho.

Semelhança de identidade em frotas

Os pools de identidade da carga de trabalho são entidades que fornecem identidades para cargas de trabalho em um formato que o IAM pode usar ao autenticar e autorizar solicitações. Com a federação de identidade da carga de trabalho para GKE, cada projeto tem um pool de identidades de carga de trabalho fixo e gerenciado pelo Google por padrão, que é exclusivo desse projeto.

Com a federação de identidade da carga de trabalho da frota, o pool de identidade da carga de trabalho gerenciado pelo Google para o projeto host da frota é o pool padrão para todos os clusters registrados na frota, independentemente de estarem em outros projetos ou nuvens. Também é possível configurar um pool de identidades da carga de trabalho autogerenciado para clusters específicos em vez do pool padrão.

Na federação de identidade da carga de trabalho da frota e na federação de identidade da carga de trabalho para GKE, você usa políticas de permissão do IAM para conceder papéis em recursos específicos do Google Cloud a entidades nos clusters, como contas de serviço ou pods do Kubernetes. Nas políticas de permissão, você se refere a essas entidades usando um identificador principal, que é uma sintaxe de nomenclatura que o IAM pode ler. O identificador principal inclui o nome do pool de identidades da carga de trabalho usado pelo cluster e outras informações que selecionam as entidades específicas no cluster. Por exemplo, o seguinte identificador de principal seleciona uma conta de serviço do Kubernetes em um namespace:

principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/WORKLOAD_IDENTITY_POOL_NAME/subject/ns/NAMESPACE/sa/SERVICEACCOUNT

Neste exemplo, os seguintes campos têm informações sobre o principal:

  • PROJECT_NUMBER: o número do projeto host da frota.
  • WORKLOAD_IDENTITY_POOL_NAME: o nome do pool de identidade da carga de trabalho.
  • NAMESPACE: o nome do namespace.
  • SERVICEACCOUNT: o nome da ServiceAccount do Kubernetes.

As solicitações para as APIs Google Cloud são autenticadas usando tokens de acesso OAuth 2.0 de curta duração gerados pelos clusters. Esses tokens de acesso incluem o identificador principal da entidade que criou a solicitação. O IAM usa o identificador principal para garantir que uma política de permissão autorize a entidade a realizar a operação solicitada.

Implicações da semelhança de identidade para frotas multilocatárias

O identificador principal resulta em igualdade de identidade, o que significa que qualquer entidade no ambiente que corresponda a um identificador principal específico é considerada pelo IAM como a mesma coisa. Com a federação de identidade da carga de trabalho para GKE de projeto único, a igualdade de identidade se aplica a todas as entidades que compartilham um identificador principal nesse projeto. No entanto, com a federação de identidade da carga de trabalho da frota, essa igualdade de identidade se aplica a todas as entidades que compartilham um identificador principal em toda a frota, independente do projeto do cluster.

Por exemplo, com o identificador principal na seção anterior, as solicitações de pods que usam a mesma ServiceAccount, o mesmo namespace e o mesmo pool de identidade da carga de trabalho recebem o mesmo identificador principal, independente do cluster ou projeto.

Se a frota executar apenas clusters no projeto host da frota, as implicações de igualdade de identidade serão as mesmas da federação de identidade da carga de trabalho para GKE. No entanto, se a frota tiver clusters executados em outros projetos, a igualdade de identidade será estendida a todos os clusters registrados na frota.

Exemplos de complexidades para a semelhança de identidade da frota

Os exemplos a seguir descrevem possíveis complexidades de igualdade de identidade que podem ocorrer ao implementar a federação de identidade da carga de trabalho da frota. Cada cenário oferece possíveis mitigações que podem ajudar você a lidar com essas complexidades.

Frota de projeto único com todos os clusters registrados e o mesmo pool de identidades de carga de trabalho

Considere a seguinte configuração de frota:

  • Todos os clusters de membros da frota estão no projeto host da frota.
  • Todos os clusters no projeto são membros da frota.
  • Todos os clusters usam o mesmo pool de identidades de carga de trabalho.

Nesse cenário, todos os clusters de membros da frota estão no projeto host da frota, e todos os clusters nesse projeto são membros da frota.

Diagrama mostrando um projeto com todos os clusters na mesma frota

Conforme descrito na seção Implicações da igualdade de identidade para frotas, usar a federação de identidade da carga de trabalho da frota nesse cenário é o mesmo que usar a federação de identidade da carga de trabalho para GKE, e não há riscos adicionais.

Frota de projeto único com alguns clusters registrados e o mesmo pool de identidades de carga de trabalho

Considere a seguinte configuração de frota:

  • A frota contém dois clusters, ambos executados no projeto host da frota.
  • O projeto host da frota contém um terceiro cluster que não é membro da frota.
  • O cluster que não é membro da frota também tem a federação de identidade da carga de trabalho para GKE ativada.
  • Todos os clusters no projeto usam o mesmo pool de identidades de carga de trabalho.

Diagrama mostrando um projeto com alguns clusters na mesma frota.

Com essa configuração, todos os papéis concedidos a uma entidade em um cluster do projeto se aplicam a outras entidades no projeto que correspondem ao identificador principal. Isso pode resultar na concessão não intencional de permissões a entidades que não fazem parte da frota. Por exemplo, conceder uma função a um identificador principal que seleciona uma conta de serviço específica em um namespace tem as seguintes implicações:

  • As cargas de trabalho executadas no namespace especificado e que usam a conta de serviço especificada nos clusters membros da frota compartilham o acesso.
  • As cargas de trabalho executadas no terceiro cluster não membro que usam o mesmo namespace e o nome da conta de serviço também recebem o mesmo acesso.

As sugestões a seguir podem ajudar a resolver essa complexidade:

  • Configure os clusters membros da frota para usar um pool de identidade da carga de trabalho autogerenciado (prévia). Isso garante que as entidades nos clusters membros da frota tenham identificadores principais diferentes do cluster não membro. Para mais detalhes, consulte Autenticar em APIs do Google Cloud com cargas de trabalho de frota de confiança mista.

  • Crie um projeto host de frota dedicado e use políticas da organização para impedir que ele execute clusters. Isso separa o domínio de confiança do pool de identidades da carga de trabalho em toda a frota dos domínios de confiança no nível do projeto do GKE. Somente os clusters registrados compartilham o pool de identidades de carga de trabalho em toda a frota.

    Essas sugestões funcionam para clusters no Google Cloud e clusters anexados.

Frota de vários projetos com alguns clusters registrados e o mesmo pool de identidades de carga de trabalho

Considere a seguinte configuração de frota:

  • A frota contém clusters membros que são executados em dois projetos Google Cloud: project-1 e project-2.
  • project-1 é o projeto host da frota. Todos os clusters em project-1 são membros da frota.
  • project-2 contém um cluster membro da frota e um cluster não registrado.
  • Todos os clusters em project-1 usam o pool de identidades de carga de trabalho gerenciado pelo Google do projeto, que também é o pool de identidades de carga de trabalho padrão em toda a frota.
  • O cluster de membro da frota em project-2 usa o pool de identidades de carga de trabalho em toda a frota.

Diagrama mostrando uma frota com clusters de dois projetos.

Nesse cenário, todas as permissões concedidas a entidades no projeto host da frota também se aplicam a entidades no cluster de membro de project-2, porque todas compartilham o mesmo pool de identidades de carga de trabalho.

Para tentar resolver essa complexidade, crie um projeto Google Cloud dedicado para usar como projeto host da frota. Os clusters membros da frota em project-1 e project-2 compartilham o pool de identidades de carga de trabalho do projeto dedicado por padrão. Em seguida, é possível conceder acesso no escopo do projeto a clusters em project-1 usando o pool de identidades da carga de trabalho para project-1 no identificador principal.

Impedir a criação de identidades semelhantes

A semelhança de identidade em frotas exige que você implemente cuidadosamente o controle de acesso para evitar a criação intencional ou não intencional de identidades semelhantes. Por exemplo, considere um cenário em que você concede acesso a todos os pods que usam uma conta de serviço específica em um namespace. Se alguém criar esse namespace e ServiceAccount em um cluster membro de frota diferente, os pods nesse cluster terão o mesmo acesso.

Para reduzir as chances desse problema, use um mecanismo de autorização para permitir que apenas um conjunto confiável de usuários crie, atualize ou exclua namespaces e contas de serviço do Kubernetes.

  • Para o IAM, as seguintes permissões fornecem esse acesso:

    • container.namespaces.*
    • container.serviceAccounts.*

  • Para o controle de acesso baseado em papéis (RBAC) do Kubernetes, o exemplo a seguir ClusterRoles configura acesso especial para interagir com estes recursos do Kubernetes:

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: namespace-admin
rules:
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["create","delete","update","patch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: serviceaccount-admin
rules:
- apiGroups: [""]
  resources: ["serviceaccounts"]
  verbs: ["create","delete","update","patch","impersonate"]

A seguir