One of the additional benefits of building a resource hierarchy is the ability to centrally set constraints on what users can configure on a Google Cloud service. Applying organization policies to a resource hierarchy at the root level helps to comply with a company’s security policies across all projects.
Let’s look at the following example. Suppose one of the outcomes of a security audit in your company is a request to limit external access to Compute Engine VMs. It was discovered that users create VMs with a public IP, and firewall rules allow access from the internet to VMs on certain ports. As your company has multiple projects, controlling how VMs are configured would be challenging. Although organization policies don’t enforce policies retrospectively, they can control how new resources are configured. To help the company to improve its security posture, you can configure the Define allowed external IPs for VM instances policy at your organization level.
You can set this policy up by selecting your organization as the scope and editing the policy in Organization Policies in IAM & Admin, as presented in the following screenshot:
Figure 12.25 – Listing policies for an organization
In the Rules section of the Edit policy view, you can define on which resources a policy will be enforced (for example, a specific VM name or a tag). In our example, it will be denied for all VMs:
Figure 12.26 – Customizing a policy that limits assigning a public IP to VMs
Once the policy is modified, you can verify whether it works as expected. The following screenshot shows the Create an instance view, where a user is presented with a warning that a specific organization policy is in place and that it is not allowed to add an external address to a VM:
Figure 12.27 – Verifying that an organization policy takes effect, and a user cannot assign a public IP to a VM
Suppose another audit revealed that users create resources outside of their home country. As your company has a regulatory obligation to keep workloads and data within a country, you need to prevent this from happening. In this case, you can use the Google Cloud Platform – Resource Location Restriction policy at the organization level to enforce all new resources only to be created in a specific Google Cloud region, for example, only in europe-central2 (Warsaw). You can define the scope of the policy in the Rules section, creating an allow entry with the following condition: in:europe-central2-locations (all zones in the europe-central2 region), as presented in the following screenshot:
Figure 12.28 – Creating an organization policy rule to allow creating resources only in europe-central2 zones
Now, if users want to create resources, depending on the service, either only the europe-central2 region will be available for selection or an attempt to create a resource in another region will fail. The following figure shows that a user wants to create a Google Cloud Storage bucket and Warsaw is the only region available. This proves that the policy is working as expected.
Figure 12.29 – A location policy allows creating resources only in the selected region
Check the list of all available policies that you can apply to your organization at .
Up to this point, we have focused on providing access or restricting it for users or groups at the organization, folder, or project level. A similar approach can also be applied to service accounts, the special accounts that are used not by humans but by applications. In the next section, we will provide more insights into this topic.