GCP Organisation Policy

Gaurav Gupta
6 min readMar 27, 2023

--

An organisation policy in GCP is a restriction/constraint that you can set over the use of a GCP service. For example, you may want to restrict the use of public IPs for a GCP project or to some specifics VMs only. The restriction is set on a resource hierarchy node, meaning you set it at the organisation, folder, project or GCP resource level.

In order to define an organisation policy, you choose a constraint, which is a particular type of restriction against either a Google Cloud service or a group of Google Cloud services. You configure that constraint with your desired restrictions.

A constraint has two types: either list or boolean.

List constraints evaluate the constraint with a list of allowed or denied values that you provide, such as an allowlist of IP addresses that can connect to a virtual machine.

Boolean constraints are either enforced or not enforced for a given resource, and govern a specific behavior, such as whether external service accounts can be created.

Source: Google Cloud

When an organisation policy is set on a resource hierarchy node, all descendants of that node inherit the organisation policy by default. If you set an organisation policy at the root organisation node, then the configuration of restrictions defined by that policy will be passed down through all descendant folders, projects, and service resources.

A user with the Organization Policy Administrator role can set descendant resource hierarchy nodes with another organization policy that either overwrites the inheritance, or merges them based on the rules of hierarchy evaluation. This provides precise control for how your organization policies apply throughout your organization, and where you want exceptions made.

Org policies are there to serve as guardrails for your teams, to ensure you stay within compliance and improve your security posture.

Organisation Policy Overview:

As per today’s date, there are 97 organisation policy available in GCP cloud.

The following gcloud command lists all set Organization Policies associated with organisation:

gcloud resource-manager org-policies list — organization=$ORG-ID

The following command lists all available constraints in addition to set Organization Policies associated with organisation

gcloud resource-manager org-policies list — organization=$ORG-ID — show-unset

Organisation Policy UI on Google Cloud Portal

Important Org policy list:

  1. Define allowed external IPs for VM instances: constraints/compute.vmExternalIpAccess — This list constraint defines the set of Compute Engine VM instances that are allowed to use external IP addresses. By default, all VM instances are allowed to use external IP addresses. To secure your organisation from any attack via public IP, we can enforce this policy to deny the use of public IP with VM.
  2. Disable VM serial port access: constraints/compute.disableSerialPortAccess — This boolean constraint disables serial port access to Compute Engine VMs belonging to the organization, project, or folder where this constraint is set to True. By default, customers can enable serial port access for Compute Engine VMs on a per-VM or per-project basis using metadata attributes. Enforcing this constraint will disable serial port access for Compute Engine VMs, regardless of the metadata attributes.
  3. Enforce Public Access Prevention: constraints/storage.publicAccessPrevention — Secure your Cloud Storage data from public exposure by enforcing public access prevention. This governance policy prevents existing and future resources from being accessed via the public internet by disabling and blocking ACLs and IAM permissions that grant access to allUsers and allAuthenticatedUsers. Enforce this policy on the entire organisation (recommended), specific projects or specific folders to ensure that no data is publicly exposed. This policy overrides existing public permissions. Public access will be revoked for existing buckets and objects after this policy is enabled.
  4. Skip default network creation: constraints/compute.skipDefaultNetworkCreation — This boolean constraint skips the creation of the default network and related resources during Google Cloud Platform Project resource creation where this constraint is set to True. By default, a default network and supporting resources are automatically created when creating a Project resource.
  5. Restrict Public IP access on Cloud SQL instances: constraints/sql.restrictPublicIp — This boolean constraint restricts configuring Public IP on Cloud SQL instances where this constraint is set to True. This constraint is not retroactive, Cloud SQL instances with existing Public IP access will still work even after this constraint is enforced. By default, Public IP access is allowed to Cloud SQL instances.
  6. Service account key expiry duration in hours: constraints/iam.serviceAccountKeyExpiryHours — This list constraint defines the maximum duration allowed for service account key expiry. By default, created keys never expire. The allowed duration is specified in hours, and must come from the list below. Only one allowed value can be specified, and denied values are not supported. Specifying a duration not in this list will result in an error. [1h, 8h, 24h, 168h, 336h, 720h, 1440h, 2160h]. To enforce this constraint, you must set it to replace the parent policy in the Cloud Console, or set inheritFromParent=false in the policy file if using the gcloud CLI. This constraint can’t be merged with a parent policy. Enforcement of the constraint is not retroactive and will not change pre-existing keys.
  7. Google Cloud Platform — Resource Location Restriction: constraints/gcp.resourceLocations: This list constraint defines the set of locations where location-based Google Cloud resources can be created. By default, resources can be created in any location.Policies for this constraint can specify multi-regions such as asia and europe, regions such as us-east1 or europe-west1 as allowed or denied locations. Allowing or denying a multi-region does not imply that all included sub-locations should also be allowed or denied. For example, if the policy denies the us multi-region (which refers to multi-region resources, like some storage services), resources can still be created in the regional location us-east1. On the other hand, the in:us-locations group contains all locations within the us region and can be used to block every region.
  8. Restrict shared VPC project lien removal: constraints/compute.restrictXpnProjectLienRemoval — This boolean constraint restricts the set of users that can remove a Shared VPC host project lien without organization-level permission where this constraint is set to True. By default, any user with the permission to update liens can remove a Shared VPC host project lien. Enforcing this constraint requires that permission be granted at the organization level.
  9. Restrict VM IP Forwarding: constraints/compute.vmCanIpForward — This list constraint defines the set of VM instances that can enable IP forwarding. By default, any VM can enable IP forwarding in any virtual network. VM instances must be specified in the form: under:organizations/ORGANIZATION_ID, under:folders/FOLDER_ID, under:projects/PROJECT_ID, or projects/PROJECT_ID/zones/ZONE/instances/INSTANCE-NAME. This constraint is not retroactive.
  10. Restrict Load Balancer Creation Based on Load Balancer Types- constraints/compute.restrictLoadBalancerCreationForTypes — This list constraint defines the set of load balancer types which can be created for an organization, folder, or project. Every load balancer type to be allowed or denied must be listed explicitly. By default, creation of all types of load balancers is allowed.

--

--

Gaurav Gupta
Gaurav Gupta

No responses yet