Scoped policies are access policies that are scoped to specific folders or projects alongside an access policy that you can apply to the entire organization. You can use scoped policies to delegate administration of VPC Service Controls perimeters and access levels to folder-level and project-level administrators.
Organizations can only have one access policy at the organizational level, and you can apply the organizational-level access policy to any folder or project in your organization.
There might be instances when you want to delegate the management of a policy for a subset of an organization's resources, such as a folder, to a delegated administrator. You can create access policies that are scoped to specific folders or projects alongside an access policy that can apply to the entire organization. To delegate administration of VPC Service Controls perimeters and access levels to folder-level and project-level administrators, you can use scoped policies.
When you delegate administration of a scoped policy, the delegated administrators can modify or read that specific policy and not the organization's Access Context Manager policy. The scoped policies limit the resources that can be restricted in a VPC Service Controls perimeter, and the visibility of any access levels.
Scoped policies management
As an organization-level Access Context Manager administrator, you can create, modify, and delete scoped policies. You can specify Identity and Access Management (IAM) bindings on Access Context Manager policy directly, and allow further delegation of Access Context Manager policy administration to other users in the organization. A scoped policy administrator can configure service perimeters and access levels in policies. However, a scoped policy administrator cannot create a new policy or change the scope of the policy to apply to another folder or project.
Here is a sequence of how administrators manage the scoped policies:
The organization-level administrator creates a new access policy with a scope field referencing a specific folder or project.
The organization-level administrator assigns IAM permissions to the delegated administrator directly on the access policy resource. The delegated administrator now has permissions on the scoped policy but does not have permissions on any other policy unless the organization-level administrator explicitly assigns them to the delegated administrator.
The delegated administrator can now edit the policy to configure access levels and service perimeters. The delegated administrator can also grant IAM permissions on that policy to any other user.
When you delete a folder or a project, the policy that has the deleted folder or project as its scope is also deleted. Also, if you move a project to another node in the organization hierarchy, the policy scoped to the project is not automatically modified. You must delete the policy associated with the project, and then recreate the policy and specify the scope.
Scoped policies hierarchy
The organization resource is the root node of the Google Cloud resource hierarchy and all resources that belong to an organization exist as children of the organization node. Folders are a grouping mechanism on top of projects. Folders and projects exist as child nodes of the organization resource.
The following diagram shows an example organization that contains folders for each department, and the folders contain dev, test, and production projects.
In the example organization, the following constraints apply to a service perimeter or an access level in a scoped policy:
Service perimeters in a scoped policy can only restrict resources that exist in the scope of that policy. For example, a service perimeter in a policy scoped to the engineering folder can secure the example-dev, example-prod, and example-test projects because the projects are in the engineering folder.
If the scoped policy applies to the sales folder, then service perimeters in that policy cannot secure any of example-dev, example-prod, and example-test projects. However, the service perimeter in the scoped policy can allow access to projects in other folders by using ingress and egress rules.
Access levels in a scoped policy are only visible within the scope of the policy. If you create an access level in the policy scoped to the engineering folder, then only service perimeters and access levels in the engineering folder can use it. Service perimeters and access levels in other folders cannot use the access level defined in the engineering folder.
A location, such as a folder, in the example.com organization resource hierarchy can have multiple policies that contain an access level or service perimeter. When multiple policies exist, a request for resources in the example.com organization is evaluated based on the following rules:
A policy can contain only one scope, such as a folder, but you can create a policy for each level of an organization. For example, if the scope of policy 1 is the engineering folder, you cannot set the engineering folder as the scope of any other policy. You can set another policy with the scope set to the child of the engineering folder, such as example-prod.
If the scope of a policy applies to a project or a parent of the project, you can add the project to the policy. However, a project can be a member of only one service perimeter across all policies. For example, A policy with scope set to the organization example.com can define a service perimeter with example-dev. A policy with scope set to the engineering folder or scope set to the example-dev project can also add the example-dev project to a perimeter defined within either of them. However, only one of those three policies can contain this project.