Shifting Left in GCP: Proactive Security with Organizational Policies

There has been a strong trend lately in security to create preventative measures which will safeguard cloud assets from being exploited by malicious actors. GCP has built-in functionality to let you enforce certain rules or restrictions on how you’d like your resources to be deployed. Detective controls can be helpful for after-the-fact situations, but preventing the potentially-adverse behavior from the start will allow you to proactively reduce security incidents.

In this article, I’ll walk through how we can solve for a number of different security vulnerabilities and exposures that are specifically tailored for GCP with the use of preventative organizational policies. The beauty of organizational policy constraints is that you are able to specify which resources in what project or even folder should have these types of restrictions enforced. There are plenty of constraints within GCP that can be used for security, but we’ll dive into following examples below:

constraints/compute.skipDefaultNetworkCreation

This constraint allows us to prevent default networks from being created. Default networks are an inherent risk because they are exposed on management ports such as 22, 3389, and 3306, which an attacker may exploit to access resources within the default network from the public internet. Enforcing this constraint allows us to ensure that a custom network is created in place of these default networks.

constraints/compute.vmExternalIpAccess

Similar to preventing default network creation, we can restrict the assignment of publicly assigned IP addresses. This constraint will ensure that no compute instances are able to assign a publicly external IP address, which can be helpful to prevent external entities from accessing your GCP compute resources.

constraints/iam.allowedPolicyMemberDomains

As part of restricting IAM access to your organization and G Suite directory, this particular constraint can be implemented to specify which G Suite IDs are able to access your organization’s resources. In theory, only allowed domains should be provisioned into your organization to prevent unauthorized access to your GCP resources.

constraints/appengine.disableCodeDownload

Developers can place code into App Engine to be deployed to workloads within GCP. Source code can reside inside of GCP, but should be restricted from being downloaded to other locations such as local hosts. This constraint allows us to prevent users from being able to download source code from App Engine.

constraints/iam.disableServiceAccountKeyCreation

The creation of service account keys should be limited to designated use cases. This constraint ensures that users provisioned inside of GCP are not allowed to create their own service account keys, preventing the exposure of active, long-living credentials. It’s important to note that this does not restrict organization admins from creating service accounts, but instead prevents individual users from creating their own access keys.

Terraform can be used to enforce these policy constraints and modify as needed to mold to your specific environment and use cases. In this walkthrough, I’ll outline how simple it is to place these restrictive, preventative measures in place. The following steps will demonstrate how you can spin up these constraints in your own environment; I’d also recommend that you try this in your personal GCP organization or sandbox environment. We’ll deploy the Terraform code below and walk through the following steps to deploy our enforcement of policies:

1. Create a project where we’ll keep our service account used to run Terraform and deploy our organizational policies from.

2. Enable the API for resource manager, which will be used for deployment of our organization policies, as well as the compute API, which will allow us to validate some of our enforcements.

3. Create a service account that will be used to deploy the Terraform code locally. No need to assign permissions here as we’ll do that in the next step; however, make sure to download the credential file as a JSON that we’ll use in our Terraform code.

4. Assign permissions via a policy binding to our service account so that it is able to modify organization policies using a Cloud Shell command. Enter in your own organization ID & project name.

gcloud organizations add-iam-policy-binding <your_org_id> \
  --member serviceAccount:terraform-user@org-policy-demo-terraform.iam.gserviceaccount.com \
  --role roles/orgpolicy.policyAdmin

One that is complete, you should see the new role binding:

- members:
  - serviceAccount:terraform-user@org-policy-demo-terraform.iam.gserviceaccount.com
  role: roles/orgpolicy.policyAdmin

5. Clone the provided Github repo using the following command:

git clone https://github.com/ashishpatel-git/terraform-gcp-security.git

6. Replace the placeholders in your main.tf file to include your organization ID, your G Suite ID, the path to your credentials JSON file, and your project name. You can find your G Suite ID by running the command gcloud alpha organizations list on the Cloud Shell.

7. Initialize Terraform in the same directory using terraform init

8. Run a Terraform plan command using terraform plan

9. Finally, you can run a terraform apply command to deploy the organizational policies we have discussed.

Once your Terraform code has run, you can go into the GCP console to validate that the configurations are in place. Let’s look at one of the constraints within the console at the organization level. As you can see, the effective policy has changed to “Denied” and applies to all VM instances.

We can now validate that this is actually the case by going to Compute Engine and trying to create a VM with an external IP address. You’ll notice that we are no longer able to assign a public IP address to the VM instances.

It’s clear to see that you can enforce many different parameters to cater to various security requirements that your own organization may have (pun intended). Shifting left with prevention can help stop threats from existing in the first place, providing your security team with more time and less incidents.