Reduza os riscos de igualdade de identidade em frotas multiinquilinas

Esta página fornece práticas recomendadas para configurar e usar a Workload Identity Federation da frota, que é uma funcionalidade da frota que lhe permite configurar centralmente a autenticação de aplicações para APIs em vários projetos. Google Cloud Para ver as práticas recomendadas relativas à adoção de outras funcionalidades de frotas, consulte Planeie funcionalidades de frotas.

Esta página destina-se a administradores e operadores da plataforma, bem como a engenheiros de segurança que querem minimizar os riscos associados à igualdade de identidade em frotas.

Antes de ler esta página, certifique-se de que conhece os conceitos descritos no artigo Acerca da Workload Identity Federation da frota.

Terminologia

Esta página usa a seguinte terminologia:

  • Federação de identidades de cargas de trabalho para o GKE: uma funcionalidade que fornece identidades a cargas de trabalho do GKE num único Google Cloud projeto.
  • Federação de identidade da carga de trabalho da frota: uma funcionalidade 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.
  • Workload Identity Pool: uma entidade que fornece identidades a cargas de trabalho num formato compatível com o Identity and Access Management (IAM). Cada cluster é um fornecedor de identidade num Workload Identity Pool.

Identidade igual em frotas

Os Workload Identity Pools são entidades que fornecem identidades a cargas de trabalho num formato que o IAM pode usar ao autenticar e autorizar pedidos. Com a Workload Identity Federation para o GKE, cada projeto tem um Workload Identity Pool gerido pela Google fixo por predefinição, que é exclusivo desse projeto.

Com a federação de identidade da carga de trabalho da frota, o conjunto de identidades da carga de trabalho gerido pela Google para o projeto anfitrião da frota é o conjunto de identidades da carga de trabalho predefinido para todos os clusters que registar na frota, independentemente de os clusters estarem noutros projetos ou noutras nuvens. Opcionalmente, pode configurar um pool de identidades de carga de trabalho autogerido para clusters específicos a usar em vez do pool predefinido.

Tanto na Workload Identity Federation da frota como na Workload Identity Federation para o GKE, usa políticas de autorização do IAM para conceder funções em Google Cloudrecursos específicos a entidades nos seus clusters, como ServiceAccounts do Kubernetes ou pods. Nas suas políticas de autorização, refere-se a estas entidades através de um identificador principal, que é uma sintaxe de nomenclatura que a IAM pode ler. O identificador principal inclui o nome do Workload Identity Pool que o cluster usa e outras informações que selecionam as entidades específicas no cluster. Por exemplo, o seguinte identificador principal seleciona uma ServiceAccount do Kubernetes num espaço de nomes:

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 do projeto de alojamento da frota.
  • WORKLOAD_IDENTITY_POOL_NAME: o nome do Workload Identity Pool.
  • NAMESPACE: o nome do espaço de nomes.
  • SERVICEACCOUNT: o nome da ServiceAccount do Kubernetes.

Os pedidos às Google Cloud APIs são autenticados através de tokens de acesso OAuth 2.0 de curta duração gerados pelos clusters. Estes tokens de acesso incluem o identificador principal da entidade que criou o pedido. O IAM usa o identificador principal para garantir que uma política de autorização permite que a entidade execute a operação pedida.

Implicações da identidade semelhante para frotas multiinquilinas

O identificador principal resulta na 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 Workload Identity Federation de projeto único para o GKE, a igualdade de identidades aplica-se a todas as entidades que partilham um identificador principal nesse projeto. No entanto, com a Workload Identity Federation da frota, esta identidade aplica-se a todas as entidades que partilham um identificador principal em toda a frota, independentemente do projeto do cluster.

Por exemplo, com o identificador principal na secção anterior, os pedidos de pods que usam a mesma ServiceAccount, o mesmo espaço de nomes e o mesmo conjunto de identidade da carga de trabalho recebem o mesmo identificador principal, independentemente do cluster ou do projeto.

Se a sua frota apenas executar clusters no projeto anfitrião da frota, as implicações de igualdade de identidade são as mesmas que para a federação de identidade da carga de trabalho para o GKE. No entanto, se a sua frota tiver clusters que são executados noutros projetos, a identidade igual estende-se a todos os clusters registados na frota.

Exemplos de complexidades para a igualdade da identidade da frota

Os seguintes cenários de exemplo descrevem potenciais complexidades de identidade semelhantes que podem ocorrer quando implementa a federação de identidade da carga de trabalho da frota. Cada cenário oferece possíveis mitigações que podem ajudar a gerir estas complexidades.

Frota de projeto único com todos os clusters registados e o mesmo Workload Identity Pool

Considere a seguinte configuração da frota:

  • Todos os clusters membros da frota estão no projeto anfitrião da frota.
  • Todos os clusters no projeto são membros da frota.
  • Todos os clusters usam o mesmo Workload Identity Pool.

Neste cenário, todos os clusters membros da frota estão no projeto anfitrião da frota e todos os clusters nesse projeto são membros da frota.

Diagrama que mostra um projeto com todos os clusters na mesma frota

Conforme descrito na secção Implicações da igualdade de identidade para frotas, usar a Workload Identity Federation de frotas neste cenário é o mesmo que usar a Workload Identity Federation para o GKE, e não existe nenhum risco adicional.

Frota de projeto único com alguns clusters registados e o mesmo Workload Identity Pool

Considere a seguinte configuração da frota:

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

Diagrama que mostra um projeto com alguns clusters na mesma frota.

Com esta configuração, todas as funções que atribuir a uma entidade num cluster no projeto aplicam-se a outras entidades no projeto que correspondam ao identificador principal. Isto pode resultar na concessão não intencional de autorizaçõ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 num espaço de nomes tem as seguintes implicações:

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

As seguintes sugestões podem ajudar a resolver esta complexidade:

  • Configure os clusters membros da frota para usar um Workload Identity Pool autogerido (pré-visualização). Isto garante que as entidades nos clusters membros da frota têm identificadores principais diferentes do cluster não membro. Para obter detalhes, consulte o artigo Autentique-se nas Google Cloud APIs a partir de cargas de trabalho de frotas de confiança mista.

  • Crie um projeto de anfitrião de frota dedicado e use políticas da organização para impedir que o projeto de anfitrião de frota dedicado execute clusters. Isto separa o domínio fidedigno do Workload Identity Pool ao nível da frota dos domínios fidedignos ao nível do projeto do GKE. Apenas os clusters registados partilham o Workload Identity Pool ao nível da frota.

    Estas sugestões funcionam para clusters em Google Cloud e clusters anexados.

Frota de vários projetos com alguns clusters registados e o mesmo Workload Identity Pool

Considere a seguinte configuração da 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 anfitrião da frota. Todos os clusters em project-1 são membros da frota.
  • project-2 contém um cluster de membros da frota e um cluster não registado.
  • Todos os clusters em project-1 usam o Workload Identity Pool gerido pela Google do projeto, que também é o Workload Identity Pool predefinido ao nível da frota.
  • O cluster de membros da frota em project-2 usa o grupo de identidades de carga de trabalho ao nível da frota.

Diagrama que mostra uma frota com clusters de dois projetos.

Neste cenário, todas as autorizações que conceder a entidades no projeto de anfitrião da frota também se aplicam a entidades no cluster membro de project-2, porque todas partilham o mesmo grupo de identidades de workload.

Para tentar resolver esta complexidade, crie um Google Cloud projeto dedicado para usar como projeto anfitrião da frota. Os clusters membros da frota em project-1 e em project-2 partilham o Workload Identity Pool do projeto dedicado por predefinição. Em seguida, pode conceder acesso ao nível do projeto a clusters no project-1 usando o Workload Identity Pool para o project-1 no identificador principal.

Impeça a criação de identidades semelhantes

A identidade igual em frotas requer que implemente cuidadosamente o controlo de acesso para evitar a criação intencional ou não intencional de identidades semelhantes. Por exemplo, considere um cenário em que concede acesso a todos os pods que usam uma conta de serviço específica num espaço de nomes. Se alguém criar esse espaço de nomes e ServiceAccount num cluster membro da frota diferente, os pods nesse cluster recebem o mesmo acesso.

Para reduzir as probabilidades de este problema ocorrer, use um mecanismo de autorização para permitir apenas que um conjunto fidedigno de utilizadores crie, atualize ou elimine espaços de nomes e contas de serviço do Kubernetes.

  • Para o IAM, as seguintes autorizações fornecem este acesso:

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

  • Para o controlo de acesso baseado em funções (CABF) do Kubernetes, os ClusterRoles do exemplo seguinte configuram o 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"]

O que se segue?