Top 5 Organization Policy Services for Google Cloud

Top 5 Organization Policy Services for Google Cloud

The Google Cloud is a cloud service that enables users to create and manage virtual machines and Kubernetes clusters, store data, and run applications. When using Google Cloud, it’s important to implement technical boundaries that enforce your company’s security and privacy policies. Just as office buildings are secured with locks and by limiting access to certain areas, your cloud environment needs to have safeguards in place to maintain security and compliance. 

To help users implement safeguards (guardrails), Google Cloud created Organization Policy Services which offer ways to maintain programmatic control over cloud resources. With many available services, knowing where to begin is difficult so we compiled our top five recommendations to help you get started! Organisational Policy Services and other Cloud-native solutions can help you to take the security of your Google Cloud to the next level.

First Things First: How to Structure Your Google Cloud Environment

Before diving into our recommendations, let’s start with the basics–how to set up your Google Cloud. It’s important to structure your cloud environment in a way that lets you get the most out of the Organization Policy Services.

Organizations are the highest structural level in Google Cloud, demonstrated by the ‘Company’ in blue at the top of the chart. The organization defines the domains in which all other resources reside. Each resource belongs to a specific project. A project is an isolated part of the organization with its own resources, (IAM) permissions, virtual machines (VMs), and so on. 

Sorting projects into folders facilitates administration. Policies are set at the organization level and inherited by nodes, or projects/folders, lower in the hierarchy. However, you can exclude inheritance for certain nodes, if desired, enabling you to tailor permissions to each project’s needs. 

For every recommended Organisational Policy Constrain. I added a Terraform examples to deploy the constraints with IaaC.

1. Resource Location Restriction

This constraint policy enables companies to limit the physical location in which new cloud resources may be deployed. For example, a company can limit resources to only be deployed in the United States or Europe. These restrictions may be necessary for compliance reasons, such as the General Data Protection Regulations (GDPR) within the EU. 

By restricting resource locations to regions that are geographically closer to the end users, companies can reduce network latency, which may lead to better performance and improved user experience. Considering where data is stored and where employees are working is a helpful step to ensure optimal performance when setting up a cloud environment. 

These location choices can also support a company’s green initiatives. Some regions have stricter CO2 emission regulations than others. Choosing a data center in a region that requires lower emissions is a simple step companies can take to be more environmentally conscious.

Terraform example for gcp.resourceLocations

resource "google_org_policy_policy" "resource_locations" {
  name = "organizations/123456789/policies/gcp.resourceLocations"
  spec {
    rules {
      condition {
        expression = "resource.location == 'europe-west4'"
      }
      deny_all = "FALSE"
    }
  }
}

2. Define Allowed External IP Addresses for VM Instances

Defining allowed external IP addresses enables companies to control which users, devices, or networks can access their VM instances. This constraint is especially important when working with remote teams or contractors because it allows companies to grant access only to specific, trusted entities.

Restricting external IP addresses for VM instances also helps prevent unauthorized access to the company’s resources and reduces the change and impact of data breaches. Additionally, this policy makes it easier to identify unusual or suspicious activity because traffic from unexpected IP addresses can be flagged and investigated.

Terraform example for compute.vmExternalIpAccess

resource "google_org_policy_policy" "vm_external_ip_access" {
  name = "organizations/123456789/policies/compute.vmExternalIpAccess"
  spec {
    rules {
      deny_all = "TRUE"
    }
  }
}

3. Domain Restricted Sharing

This feature allows organizations to control how their users share content with people outside the company. It provides an extra layer of security to stored data and ensures that only authorized users can access sensitive information. 

Having this safeguard in place is particularly important when it comes to offboarding employees. If an employee used their personal account to access company data, that person will still have access after leaving the company. Similarly, if outside collaborators are granted access, they may maintain it long after their work is complete if no security measures are in place.

Terraform example for iam.allowedPolicyMemberDomains

resource "google_org_policy_policy" "allowed_policy_member_domains" {
  name = "organizations/123456789/policies/constraints.iam.allowedPolicyMemberDomains"
  spec {
    rules {
      domains = ["xebia.com"]
    }
  }
}

4. Define Trusted Image Projects

This policy enables companies to control which cloud storage buckets or projects are trusted sources for their compute engine instances’ images. Doing so helps ensure consistency across the company’s virtual machine instances, helping to prevent vulnerabilities caused by untested images.

Companies can also define which operating systems images can be used and assigned to a VM. In this way, a company can control costs by placing limits on the number and type of images that can be run, for example. This safeguard also helps to prevent malicious software from running on your virtual machines.

Terraform example for compute.trustedImageProjects

resource "google_org_policy_policy" "trusted_image_projects" {
  name = "organizations/123456789/policies/constraints.compute.trustedImageProjects"
  spec {
    rules {
      projects = ["red-hat-cloud/rhel-8", "palo-alto-networks/panos"]
    }
  }
}

5. Enforce Public Access Prevention

This restriction prevents data from being publicly accessible, reducing the risk of data breaches and other security incidents. Employees are also restricted from inviting all users, ensuring data is only accessible by trusted sources. This policy is a simple step with huge benefits.  

resource "google_org_policy_policy" "public_access_prevention" {
  name = "organizations/123456789/policies/constraints.storage.publicAccessPrevention"
  spec {
    boolean_policy {
      enforced = true
    }
  }
}

Get started today with Policy Organisational Constraints!

Our top five recommendations will help ensure your company’s resources and data is safe as you create and build in your Google Cloud. Ultimately, what additional services a company uses will depend on its specific needs. Don’t forget to evaluate and test the Policy Org Constrain of your choice before applying it to production workloads. Curious looking into more Org Policies, take a look at: https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints

Contact me to learn more about other solutions that can help you to take the security of your Google Cloud to the next level.