As políticas com escopo são definidas para pastas ou projetos específicos, além de uma que pode ser aplicada a toda a organização. É possível usar políticas com escopo para delegar a administração de perímetros e níveis de acesso do VPC Service Controls a administradores no nível da pasta e do projeto.
As organizações só podem ter uma política de acesso no nível organizacional, e você pode aplicar a política de acesso de nível organizacional a qualquer pasta ou projeto na sua organização.
Pode haver instâncias em que você quer delegar o gerenciamento de uma política para um subconjunto dos recursos de uma organização, como uma pasta, a um administrador delegado. É possível criar políticas de acesso com escopo para pastas ou projetos específicos, além de uma política que pode ser aplicada a toda a organização. Para delegar a administração de perímetros e níveis de acesso do VPC Service Controls a administradores de pastas e projetos, use políticas com escopo.
Quando você delega a administração de uma política com escopo, os administradores delegados podem modificar ou ler essa política específica, e não a política do Access Context Manager da organização. As políticas com escopo limitam os recursos que podem ser restritos em um perímetro do VPC Service Controls e a visibilidade de todos os níveis de acesso.
Gerenciamento de políticas com escopo
Como administrador do Access Context Manager no nível da organização, você pode criar, modificar e excluir políticas com escopo. É possível especificar vinculações do Identity and Access Management (IAM) diretamente na política do Access Context Manager e permitir maior delegação da administração de políticas do Access Context Manager a outros usuários na organização. Um administrador de política com escopo pode configurar perímetros de serviço e níveis de acesso nas políticas. No entanto, um administrador de política com escopo não pode criar uma nova política ou alterar o escopo dela para aplicar a outra pasta ou projeto.
Veja uma sequência de como os administradores gerenciam as políticas com escopo:
O administrador no nível da organização cria uma nova política de acesso com um campo de escopo que referencia uma pasta ou projeto específico.
O administrador no nível da organização atribui permissões do IAM ao administrador delegado diretamente no recurso da política de acesso. O administrador delegado agora tem permissões na política com escopo, mas não tem permissões em nenhuma outra política, a menos que o administrador no nível da organização as atribua explicitamente ao administrador delegado.
O administrador delegado agora pode editar a política para configurar níveis de acesso e perímetros de serviço. Ele também pode conceder permissões do IAM nessa política a qualquer outro usuário.
Quando você exclui uma pasta ou um projeto, a política que tem a pasta ou o projeto excluído como escopo também é excluída. Além disso, se você mover um projeto para outro nó na hierarquia da organização, a política com escopo para o projeto não será modificada automaticamente. Exclua a política associada ao projeto e recrie a política e especifique o escopo.
Hierarquia de políticas com escopo
O recurso da organização é o nó raiz da hierarquia de recursos do Google Cloud, e todos os recursos que pertencem a uma organização existem como filhos do nó dela. Além dos projetos, as pastas são um mecanismo de agrupamento. As pastas e os projetos existem como nós filhos do recurso da organização.
O diagrama a seguir mostra um exemplo de organização que contém pastas para cada departamento, e as pastas contêm projetos de desenvolvimento, teste e produção.
Na organização de exemplo, as restrições a seguir se aplicam a um perímetro de serviço ou a um nível de acesso em uma política com escopo:
Os perímetros de serviço em uma política com escopo só podem restringir recursos que existem no escopo dessa política. Por exemplo, um perímetro de serviço em uma política com escopo para a pasta de engenharia pode proteger os projetos example-dev, example-prod e example-test porque os projetos estão na pasta de engenharia.
Se a política com escopo se aplicar à pasta de vendas, os perímetros de serviço nessa política não poderão proteger nenhum dos projetos example-dev, example-prod e example-test. No entanto, o perímetro de serviço na política com escopo pode permitir acesso a projetos em outras pastas usando regras de entrada e saída.
Os níveis de acesso de uma política com escopo são visíveis apenas no escopo da política. Se você criar um nível de acesso na política com escopo para a pasta de engenharia, somente os perímetros de serviço e os níveis de acesso na pasta de engenharia poderão usá-lo. Os perímetros de serviço e os níveis de acesso em outras pastas não podem usar o nível de acesso definido na pasta de engenharia.
Um local, como uma pasta, na hierarquia de recursos da organização example.com pode ter várias políticas que contêm um nível de acesso ou perímetro de serviço. Quando há várias políticas, uma solicitação de recursos na organização example.com é avaliada com base nas regras a seguir:
Uma política pode conter apenas um escopo, como uma pasta, mas é possível criar uma política para cada nível de uma organização. Por exemplo, se o escopo da política 1 for a pasta de engenharia, não será possível defini-la como o escopo de qualquer outra política. É possível definir outra política com o escopo definido como o filho da pasta de engenharia, como example-prod.
Se o escopo de uma política se aplicar a um projeto ou a um pai do projeto, você poderá adicioná-lo à política. No entanto, um projeto pode ser membro de apenas um perímetro de serviço em todas as políticas. Por exemplo, uma política com escopo definido como a organização example.com pode definir um perímetro de serviço com example-dev. Uma política com escopo definido como a pasta de engenharia ou o escopo definido para o projeto example-dev também pode adicionar o projeto example-dev a um perímetro definido dentro de qualquer um deles. No entanto, apenas uma dessas três políticas pode conter esse projeto.