Práticas recomendadas para usar a Identidade da carga de trabalho da frota

Como você viu em Usar a identidade da carga de trabalho da frota, a federação de identidade da carga de trabalho em toda a frota é um recurso poderoso que simplifica a configuração da autenticação no Google Cloud para seus aplicativos em todos os projetos. No entanto, ela pode ter considerações de controle de acesso além das considerações para a federação de identidade da carga de trabalho normal para o GKE. Neste guia, apresentamos alguns exemplos desses possíveis problemas e como organizar suas frotas para minimizar possíveis riscos.

Antes de ler este guia, você precisa estar familiarizado com os conceitos descritos em Usar a identidade de carga de trabalho da frota.

Para conferir as práticas recomendadas sobre a adoção de outros recursos da frota, consulte Planejar recursos da frota.

Pools de identidade de frotas e projetos

Para entender por que a federação de identidade da carga de trabalho em toda a frota exige uma adoção cuidadosa, principalmente ao trabalhar com frotas de vários projetos, vamos analisar mais de perto como a federação de identidade da carga de trabalho para o GKE e a federação de identidade da carga de trabalho da frota funcionam. Em ambos os casos, as cargas de trabalho são autenticadas usando tokens de curta duração gerados pelos clusters, e cada cluster é adicionado como um provedor de identidade a um pool de identidades de carga de trabalho especial. As cargas de trabalho executadas em um namespace específico podem compartilhar a mesma identidade do IAM nos clusters.

Confira o que acontece com a federação de identidade da carga de trabalho do GKE quando ela é ativada nos clusters. A federação de identidade da carga de trabalho para o GKE está ativada para clusters do Autopilot por padrão.

1. O GKE cria um pool de identidades de cargas de trabalho gerenciado pelo Google no projeto do cluster: PROJECT_ID.svc.goog.id.
2. O GKE adiciona os clusters como provedores de identidade ao pool.
3. Como resultado, as cargas de trabalho executadas em um namespace específico compartilham a mesma identidade do IAM nos clusters de um projeto. A identidade está neste formato: serviceAccount:PROJECT_ID.svc.id.goog[K8S_NAMESPACE/KSA_NAME].

A federação de identidade da carga de trabalho em toda a frota é ativada automaticamente quando você adiciona um cluster com a federação de identidade da carga de trabalho para o GKE ativada a uma frota, incluindo clusters do Autopilot, clusters padrão com o recurso explicitamente ativado e clusters do GKE fora do Google Cloud.

Confira o que acontece quando um usuário registra um cluster com a federação de identidade da carga de trabalho do GKE ativada em uma frota:

1. O pool de identidades de carga de trabalho FLEET_PROJECT_ID.svc.goog.id gerenciado pelo Google no projeto host da frota será criado, se o pool ainda não existir. É o mesmo que o pool de Identidades da carga de trabalho do projeto host da frota.
2. O cluster é adicionado como um provedor de identidade ao pool.
3. Como resultado, as cargas de trabalho executadas em um namespace específico compartilham a mesma identidade do IAM nos clusters da frota. Chamamos isso de semelhança implícita das identidades da carga de trabalho da frota. A identidade está neste formato: serviceAccount:FLEET_PROJECT_ID.svc.id.goog[K8S_NAMESPACE/KSA_NAME]. As cargas de trabalho da frota em projetos diferentes podem chamar as APIs do Google usando a mesma identidade para autenticação.

Como isso sugere, se a frota incluir apenas clusters de um projeto e todos estiverem registrados nela, o resultado será o mesmo que se você estivesse apenas usando a federação de identidade da carga de trabalho para o GKE sem frotas: todos os clusters são provedores de identidade no pool de identidades de cargas de trabalho em todo o projeto, e as cargas de trabalho usam as mesmas identidades que usariam com a federação de identidade da carga de trabalho para o GKE. No entanto, quando a frota tem clusters de membros em vários projetos, a federação de identidade da carga de trabalho combina os pools de identidade por projeto em um único pool de identidades para toda a frota, hospedado no projeto host da frota.

Como você vai notar nos exemplos a seguir, algumas complexidades podem ocorrer quando há apenas uma sobreposição parcial entre o conjunto de clusters em um projeto e o conjunto de clusters nesse projeto que são membros de uma frota.

Cenário 1: frota de projeto único com todos os clusters registrados

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.

Conforme descrito na seção anterior, usar a federação de identidade da carga de trabalho em toda a frota é o mesmo que usar a federação normal para o GKE, e não há riscos adicionais.

Cenário 2: frota de projeto único com alguns clusters registrados

Nesse cenário, uma frota contém dois clusters, ambos no projeto host da frota Projeto 1. O projeto host da frota também contém um terceiro cluster que não é membro da frota e tem a federação de identidade da carga de trabalho para GKE ativada.

O que isso significa:

• Os clusters 1, 2 e 3 são adicionados pelo GKE ao pool de identidades de carga de trabalho do projeto project-1.svc.goog.id.
• Os clusters 1 e 2 são adicionados pela frota ao pool de Identidade da carga de trabalho da frota, que, por ser o projeto host da frota, também é o pool de Identidade da carga de trabalho do projeto project-1.svc.goog.id.

O administrador quer conceder permissões às cargas de trabalho em execução em um namespace em todos os clusters da frota. Ele usa serviceAccount:project-1.svc.goog.id[namespace/ksa] como identidade para conceder acesso. No entanto, as cargas de trabalho nesse namespace no Cluster 3, que não faz parte da frota, agora compartilham o mesmo acesso. Isso ocorre porque o Cluster 3 está no pool de identidades de cargas de trabalho do projeto, que (porque é o projeto host da frota) é o mesmo que o pool de identidades de cargas de trabalho da frota. Em outras palavras, o administrador pode ter a intenção de conceder permissões apenas a clusters em uma frota, mas, devido à implementação da federação de identidade da carga de trabalho da frota, os clusters que não são da frota também podem ter acesso.

Possível mitigação

Uma solução possível é criar um projeto dedicado para hospedar a frota sem clusters, aplicado pela política da organização personalizada na API do contêiner. Isso fornece uma separação clara do domínio de confiança do pool de identidade da carga de trabalho da frota dos domínios de confiança no nível do projeto do GKE.

O administrador pode escolher o domínio de confiança apropriado ao conceder permissões para cargas de trabalho. Por exemplo, eles podem usar serviceAccount:project-0.svc.goog.id[namespace/ksa] para conceder permissões a uma carga de trabalho com namespace em toda a frota. O cluster 3, que não é membro da frota, não faz parte desse pool de identidades de carga de trabalho nessa configuração e, portanto, não tem acesso.

Essa solução funciona para clusters no Google Cloud e clusters anexados.

Cenário 3: frota de vários projetos com alguns clusters registrados

Nesse cenário, uma frota tem membros de dois projetos, Projeto 1 e Projeto 2.

O administrador quer conceder permissões a cargas de trabalho em execução em um namespace em todos os clusters do Projeto 1 usando a federação de identidade da carga de trabalho normal para o GKE. No entanto, como o Cluster 4 está registrado na frota e o Projeto 1 é o host da frota, as cargas de trabalho no Cluster 4 no Projeto 2 também vão receber as mesmas permissões.

Possível mitigação

Como no cenário anterior, uma possível mitigação aqui é criar um projeto host de frota dedicado sem clusters. Isso permite que o administrador diferencie as identidades do pool de identidades da frota e do pool de identidades do projeto de cada cluster ao configurar o controle de acesso.

Cenário 4: considere a semelhança de namespace

Os pools de identidade da carga de trabalho não são a única área que pode gerar confusão ao usar a federação de identidade da carga de trabalho. Como apresentado em Planejar recursos da frota, muitos recursos da frota, incluindo a federação de identidade da carga de trabalho, usam a suposição de semelhança de namespace para simplificar a configuração e o gerenciamento em toda a frota. Isso significa que o recurso trata namespaces com o mesmo nome em vários clusters de membros da frota como se fossem o mesmo namespace. Neste exemplo, um administrador concedeu permissões a cargas de trabalho no namespace NS1 em execução nos clusters de membros da frota Cluster 1 e Cluster 2.

No entanto, um usuário criou, de maneira acidental ou maliciosa, um namespace com o mesmo nome em outro cluster de membro da frota. Devido à suposição da semelhança de namespace, as cargas de trabalho nesse namespace recebem automaticamente os mesmos privilégios que as cargas de trabalho NS1 legítimas nos clusters 1 e 2.

Possível mitigação

Defina permissões para que apenas um pequeno grupo de papéis confiáveis possa criar namespaces em clusters.