Suporte a pastas em perímetros de serviço

Com o recurso de associação baseada em pastas do VPC Service Controls, é possível definir perímetros de serviço com pastas do Google Cloud como membros. Ao ajudar você a proteger uma hierarquia de pastas inteira com uma única configuração de perímetro, esse recurso reduz a sobrecarga administrativa do gerenciamento de perímetro em grande escala.

Este documento explica como funciona o suporte a pastas em perímetros e aborda o seguinte:

  • Principais conceitos, comportamentos e benefícios do uso de pastas em perímetros.

  • Interações entre associação baseada em pastas, recursos aninhados e regras de hierarquia de recursos, como herança e precedência de avaliação.

  • Como pesquisar perímetros configurados para projetos e pastas.

  • Práticas recomendadas e limitações conhecidas para usar esse recurso.

Sobre a associação de pastas em perímetros

Uma Google Cloud pasta pode conter vários projetos, outras pastas ou uma combinação de ambos. Embora seja possível adicionar projetos individuais em uma pasta a um perímetro de serviço, recomendamos adicionar a pasta mãe. Ao especificar uma pasta como um recurso protegido ao criar um perímetro, o VPC Service Controls inclui todos os recursos dessa pasta, como projetos e pastas aninhadas.

Quando você adiciona projetos a uma pasta configurada em um perímetro, o VPC Service Controls adiciona automaticamente esses projetos ao mesmo perímetro. Não é necessário atualizar a configuração do perímetro para incluir esses projetos. Da mesma forma, quando você remove projetos da pasta, o VPC Service Controls remove automaticamente esses projetos do perímetro.

Pastas aninhadas e herança

O VPC Service Controls restringe todos os recursos em uma pasta que você configurou em um perímetro, como pastas aninhadas e os recursos delas. Quando você adiciona uma pasta a um perímetro, o VPC Service Controls restringe automaticamente todos os projetos nessa pasta e nas subpastas dela.

Precedência da avaliação de associação de recursos

Um recurso do Google Cloud pode ser protegido por apenas um perímetro de serviço regular no modo restrito e um no modo de teste. Se um recurso ou as pastas principais dele estiverem associados a vários perímetros, a associação de nível mais baixo na hierarquia de recursos vai determinar o perímetro efetivo.

O VPC Service Controls avalia a precedência de forma independente para o modo restrito e o modo de teste:

  • Precedência do modo restrito: o perímetro restrito efetivo é determinado pelo recurso mais baixo na hierarquia (o próprio projeto ou a pasta ancestral mais próxima) que é explicitamente atribuído a um perímetro restrito.
  • Precedência do modo de teste: o perímetro do modo de teste efetivo é determinado pelo recurso mais baixo na hierarquia que é explicitamente atribuído a um perímetro do modo de teste ou implicitamente herdado de um recurso aplicado explicitamente.

Configurar um perímetro do modo de teste para um projeto ou subpasta não desativa nem substitui um perímetro restrito configurado em uma pasta ancestral.

Exemplos de precedência

  • Exemplo 1 (substituição direta de projeto no modo restrito): se você configurar uma pasta mãe (folders/1) em um perímetro restrito (sp1) e configurar explicitamente um projeto nessa pasta (projects/1) em um perímetro restrito diferente (sp2), projects/1 será protegido por sp2. A atribuição direta de projeto tem precedência sobre a herança de pasta. Todos os outros projetos em folders/1 (como projects/2) permanecem protegidos pelo sp1 por herança de pastas.

  • Exemplo 2 (herança de pastas no modo de teste): quando você configura uma pasta (folders/1) em um perímetro de serviço no modo de teste, todos os projetos nessa pasta (projects/1 e projects/2) herdam a configuração do perímetro de teste (sp1), a menos que seja explicitamente desativada. A simulação se comporta de maneira idêntica à herança do modo restrito, a menos que um recurso aninhado seja configurado explicitamente com um perímetro do modo de teste diferente.

  • Exemplo 3 (avaliação independente de perímetros restritos e de simulação): o VPC Service Controls avalia as associações restritas e de simulação de forma independente. Se você configurar uma pasta mãe (folders/1) em um perímetro restrito (sp1) e atribuir explicitamente um projeto nessa pasta (projects/1) a um perímetro do modo de teste (sp2), projects/1 vai continuar protegido por sp1 no modo restrito e, ao mesmo tempo, será avaliado no modo de teste por sp2. A atribuição de um projeto a um perímetro do modo de teste não substitui nem desativa o perímetro restrito da pasta mãe.

  • Exemplo 4 (hierarquia de pastas multinível e precedência de subpastas): em uma hierarquia de pastas multinível, o VPC Service Controls avalia a precedência em cada nível da hierarquia. Se uma pasta ancestral (folders/2) for configurada em um perímetro restrito (sp1), todos os projetos contidos (projects/1 e projects/2) vão herdar a aplicação de sp1. Quando os perímetros do modo de teste são atribuídos em diferentes níveis, como atribuir o ancestral folders/2 ao perímetro do modo de teste sp2 e o projeto projects/2 (na subpasta folders/1) ao perímetro do modo de teste sp1, cada projeto herda a configuração de modo de teste do ancestral mais próximo. Como resultado, projects/1 é avaliado na simulação sp2, mas projects/2 é avaliado na simulação sp1.

Pesquisar perímetros configurados efetivos

Como os recursos podem herdar a proteção de perímetro das pastas ancestrais, use o método LookupConfiguredServicePerimeter para identificar quais perímetros de serviço protegem um projeto ou uma pasta.

A API retorna o seguinte:

  • servicePerimeter: o nome totalmente qualificado do perímetro aplicado efetivo.
  • servicePerimeterDryRun: o nome totalmente qualificado do perímetro de teste efetivo.
  • restrictedResource: o recurso específico (projeto ou pasta) a que o perímetro restrito está diretamente anexado.
  • restrictedResourceDryRun: o recurso específico em que o perímetro de teste está diretamente anexado.

Para mais informações, consulte Pesquisar perímetros configurados.

Exclusão de projetos dos perímetros

Para excluir um projeto de um perímetro no nível da pasta, atribua explicitamente esse projeto a um perímetro separado que não restringe nenhum serviço e permite todo o tráfego de entrada e saída. Como as configurações explícitas do projeto têm precedência sobre os perímetros no nível da pasta, o projeto é excluído do perímetro da pasta.

Para informações sobre como atualizar perímetros, consulte Atualizar um perímetro de serviço.

Políticas com escopo

Os perímetros de serviço em uma política com escopo restringem apenas os recursos que existem no escopo dessa política. Para que uma pasta seja incluída como membro em um perímetro restrito, a política de acesso precisa ser definida no escopo dessa pasta ou de um ancestral dela (como uma pasta mãe ou a organização).

Práticas recomendadas

Confira as práticas recomendadas a seguir ao gerenciar perímetros baseados em pastas.

Migração segura de projetos para perímetros de pasta

Ao fazer a transição de associações explícitas a projetos para associações baseadas em pastas, siga estas etapas para evitar interrupções não intencionais na aplicação do perímetro:

  1. Adicione a pasta principal de destino ao perímetro de serviço.
  2. Mova os projetos para essa pasta mãe na hierarquia de recursos.
  3. Aguarde pelo menos 48 horas: mantenha as entradas explícitas do projeto na configuração do perímetro por pelo menos 48 horas. Esse período permite que a propagação da hierarquia de recursos seja concluída em todos os sistemas.
  4. Remova as configurações explícitas de projeto do perímetro. Os projetos permanecem protegidos por herança de pastas.

Movimentações de hierarquia

Mover pastas ou projetos muda a proteção de perímetro efetiva deles. Para evitar negações de acesso inesperadas, coordene todas as movimentações na hierarquia com o administrador do Resource Manager.

Se você mover projetos configurados em um perímetro para outra pasta e adicionar essa pasta ao mesmo perímetro, mantenha as configurações explícitas de associação de projeto no perímetro por pelo menos 48 horas. Esse período de espera permite a propagação da hierarquia de recursos e evita problemas inesperados de aplicação do perímetro quando você remove as configurações explícitas do projeto do perímetro.

Limitações

  • A associação baseada em pastas não é compatível com pontes de perímetro. As pontes de perímetro só aceitam recursos de projeto.

  • O VPC Service Controls não é compatível com recursos de API no nível da pasta.

  • Devido a um problema conhecido, a configuração de um projeto de rede VPC como um recurso protegido em um perímetro de simulação substitui a aplicação baseada em pastas. Se um projeto de rede for adicionado explicitamente a um perímetro do modo de teste, ele perderá a proteção de perímetro restrito herdada das pastas ancestrais.

  • A associação a pastas não é compatível com APIs que não sãoGoogle Cloud e com perímetros configurados com allowed_service_patterns. Para permitir o acesso a esses padrões de serviço, os projetos ou redes VPC de origem precisam ser adicionados explicitamente ao perímetro, em vez de serem herdados por uma pasta.

A seguir