A Guide to GCP Organization Policy: Managing Access

Originally published by Sonrai Security.

Written by Tally Shea.

Governance, security and compliance become difficult projects at scale. If you’re an enterprise operating out of Google Cloud, you’re likely looking for ways to manage access, enforce guardrails, and make configuration constraints to resources across your organization. Below, we will introduce all you need to know about GCP Organization Policies and describe how you can leverage them to centralize control over your environment.

What is a GCP Organization Policy?

Organization Policy is a powerful tool provided by Google Cloud, designed to give you centralized and systematic control over your cloud resources. This policy is not just a feature; it’s a cornerstone for managing and securing your cloud environment effectively. So, what exactly is it?

A GCP Organization Policy is a set of rules and constraints that govern how resources in your Google Cloud environment can be used. It’s the backbone of resource management, ensuring that your organization’s cloud usage stays within security, compliance and governance boundaries.

GCP Organization Policies centralize control. It’s like having a command center for all your cloud resources, where you can set up guardrails for your development teams, ensuring they operate within secure boundaries while still working efficiently.

GCP hierarchy structure. Learn more about hierarchy evaluation here.

Key Concepts of GCP Organization Policy

Now, let’s break down the key elements of a GCP Organization Policy:

• The Policy: At its core, an Organization Policy is a collection of rules applied to your organization’s resources. It’s like a rulebook that dictates what can and cannot be done within your cloud environment. There are built-in (Google owned) policies or custom policies.
• Rules: These are the specific directives within the policy that determine how and when a constraint is applied. Think of them as individual instructions or clauses in your rulebook. For instance, a rule might enforce a constraint only on resources tagged with environment=development.
• Constraints: These are the actual restrictions applied by the policy. Constraints in GCP policy are like the laws in your rulebook. They define the boundaries for the behavior of your cloud services. For example, “Disable Source Code Download” for AppEngine, or “Restrict which KMS Cryptokey types may be created” for Cloud KMS.
• Inheritance: When you set a policy at the organization level, it cascades down and applies to all the resources under it – like folders and projects. This inheritance ensures that policies are uniformly applied across your organization, providing a consistent management approach and less manual work.

Examples of GCP Org Policy

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

The above constraint policy limits the geo location of new resource deployments to Europe-West4.

name: 
organizations/ORGANIZATION_ID/policies/gcp.disableCloudLogging
spec:
rules:
-condition:
expression:resource.matchTag(\"ORGANIZATION_ID/environment\",\"development\")title:""
enforce:true
  – enforce: false

The above constraint disables Cloud Logging for resources that are tagged with environment=development, but enables it everywhere else.

GCP Organization Policy Best Practices

Some recommended GCP Organization Policy best practices to enforce that are relatively low hanging fruit include:

• Restrict public IP access on cloud SQL instances: Self-explanatory, you want to keep your workloads inaccessible to the public.
• Enforce uniform bucket-level access: Ensure all objects have the same permission and access best practices applied.
• Restrict Domain Sharing: Restrict which domains (think: a random gmail user) can be added to an IAM policy and get permissions on your resources.
• Disable automatic IAM grants for default service accounts: Default service accounts with default (read: broad) permissions are good for testing things but risky for handling prod workloads.
• Disable service account key creation: By default, service account keys do not expire until far, far in the future. This means they essentially do not expire. Enforcing this policy helps prevent key misuse and encourage key rotation policy in the org and limit new creations.

A general word of caution when creating organization-level policies: test them out in a separate folder or project before activating across the org. This helps avoid ‘breaking’ anything important or sensitive if a policy deployment goes wrong.

Using Organization Policy for IAM

Now, there is a difference between IAM policy and organizational policy. Google Cloud offers IAM policies to define who can take what actions on which resources. The Principal defines the ‘who.’ Next, is the ‘what actions’, which is defined by roles and their associated permissions. Finally, ‘which resource’ is defined by where your policy is applied to – where in your cloud can the principal execute their privilege.

However, you can use IAM policies at the organizational scope to function like a gcp org policy.

Some points to note: 1) GCP is deny by default, meaning if there is no deny or allow policy attached to an identity, the identity will not hold access by default. 2) A deny policy will override any allow permission.

Example Use Case for GCP IAM Organization Policy

Leveraging the organizational scope when applying IAM policies is a powerful tool because of its cascading effect. IAM policies are inherited down from a parent resource. Let’s say you want your CFO to have ‘read’ access across your entire business so they can audit how your enterprise is spending money. You can set a policy at the org level offering them the ‘Billing Account Costs Manager’ predefined role so each BU inherits this access.

Managing Policy Inheritance

As we’ve introduced, org policies work hierarchically, meaning the rules set there or at a parent resource trickle downstream to folders and projects and subsequent resources and identities. This lends identities to acquire privilege not explicitly defined to them. Now combine these org policies with policies set at resource or identity scopes and you have numerous competing permissions and constraints.

Permissions can become muddled very quickly in the cloud, making insight into what any given identity’s effective permissions are, difficult. If you’re a multi cloud enterprise, this permission and access management gets even more difficult.