Secure your GCP organization perimeter with Organization Policies

Vishakha Srivastava
Google Cloud - Community
6 min readJan 24, 2023

When one thinks of the words “organization policies”, what comes to mind is a set of strict directives implemented to enable a security-compliant environment for maximum productivity. What’s more, to maintain the sanctity of these rules, one might require dedicated monitoring at all times. While it might make sense for legacy businesses and business models, the definition of these words varies quite a bit when it comes to the cloud, and more specifically Google Cloud. Let’s have a look at what organization policies mean in GCP and a few common use cases.

Organization policies in Google Cloud are conditions that can be implemented by the administrator at various hierarchical levels of your GCP landscape. When a policy is applied at a parent node — be it organization, folder or project — all child resources will immediately fall in line with the policy. An added plus is that no additional manual monitoring, maintenance or enforcement is required. Google Cloud ensures that the policy is adhered to and raises an exception if any violation is encountered.

Let’s look at a simple day-to-day use case for organization policy. When you create a new project in GCP, a VPC network is created automatically in the project, with subnets in each region.

What a default network looks like

… and so on.

But what if you want to exercise greater control over your VPC regions and CIDR ranges without having to deal with the default network? You can implement the organization policy to Skip the Default Network Creation at the organization node, which will simply skip this VPC network creation for all subsequently created projects:-

Enabling Skip the Default Network Creation: Step 1
Enabling Skip the Default Network Creation: Step 2
Enabling Skip the Default Network Creation: Step 3
Enabling Skip the Default Network Creation: Step 4
Enabling Skip the Default Network Creation: Step 5

You can then create custom VPC networks in your projects as per your precise requirements.

This begs the question, what about the previously created default VPCs and the resources dependent on this default VPC network? Well, GCP has you covered! Organization policy enforcement is not retrospective in GCP, so any newly implemented policy changes do not affect the resources which were created before the policy was implemented. Hence, for this use case, any previously created default VPCs and dependent resources remain unaffected.

Let’s look at a few contention cases. By default, between an allow and deny policy for the same constraint, the deny policy always takes precedence. This is very much in line with the core guiding principle of an organization policy, which ensures that your resources are not exposed to any untoward influences, whether inadvertently or maliciously. A blanket adherence to “deny” ensures that. But then, what if we want to exceptionally allow the policy for a single instance? What about allowing the policy a few particular resources? Organization Policy allows you the flexibility to do that as well. For example, for Define allowed external IPs for VM instances policy, we can enable a universal Deny which disallows any GCP VM instances from having an external IP.

Enabling Define allowed external IPs for VM instances: Step 1
Enabling Define allowed external IPs for VM instances: Step 2
Enabling Define allowed external IPs for VM instances: Step 3

In the same vein, if there are instances for which an external IP is a requirement, we can add a Custom Rule in addition to the Deny policy which allows the same as follows:-

Adding Custom Rules: Step 1
Adding Custom Rules: Step 2

One thing to note here is that the machine name(s) for this exception rule need to be in the format “projects/PROJECT_ID/zones/ZONE/instances/INSTANCE$”. Alternatively, we can utilize conditional tags, where you can allow or deny a policy based on whether a resource has a specific tag. All you need to do is provide a condition type, operator and value path and Google Cloud will take care of the rest:-

Adding Conditional Tags: Step 1
Adding Conditional Tags: Step 2

Organization policies in GCP can also be used as a starting point for your minimum viable cloud’s security hardening. Unauthorized user access remains one of the biggest concerns of cloud consumers worldwide, and organization policies provide a seamless way to restrict such access. Simply enable the Domain Restricted Sharing policy at the organization node and define the Cloud Identity/ Google Workspace customer IDs you want to whitelist. Once the policy is active, only the user identities belonging to the corresponding domains will be able to access your GCP landscape at all. In the same vein, the Domain Restricted Contacts policy can be enabled at the organization level, which helps us specify the set of domains that email addresses added to Essential Contacts can have. A complete and comprehensive list of the various Organization Policies offered by GCP can be found here, which can help you decide which constraints might be suitable for your organization’s needs.

A situation might arise in which the predefined constraints do not fulfil your policy requirements. For such a case, the organization policy administrator can create a custom constraint as well. Custom constraint is nothing but a YAML file with the specifics of the resources, methods, conditions and actions that encompass the constraint, and the service on which the constraints shall be applied. The conditions here are defined using Common Expression Language (CEL). Custom constraints are still covered by the Pre-GA Offerings Terms of the Google Cloud Terms of Service, hence might have limited support, and changes to pre-GA features might not be compatible with other pre-GA versions.

Once we have our organization policies in place, the next question is, how do we have centralized visibility of the policies so applied? Enter Policy Analyzer, which is another Pre-GA offering by GCP. With Policy Analyzer, one can run analysis queries to get a list of organization policies with a particular constraint and the resources to which the policy is attached. Analysis query further consists of two components — the constraint and the scope. Constraint specifies the resource name and the scope specifies the organization for the analysis. All organization policies within this scope that have the specified constraint will be included in the analysis. The queries can also be saved and shared if you are using REST APIs.

There we have it! To conclude, organization policies are conditional constraints that can be leveraged to enable the very basic resource configurations and security hardening around your GCP environment. They are simple, efficient and abstract away the more complex details of what goes on behind the curtains. Organization Policy implementation is a very strong step in creating a landing zone which is compliant with Google’s best practices, and ultimately helps create a high performing and secure cloud infrastructure foundation.

--

--

Vishakha Srivastava
Google Cloud - Community

Cloud Migration Consultant at Google. I write about things I work with everyday.