Organization policies that must be enabled to strengthen your google cloud security.

Madhu
Google Cloud - Community
4 min readOct 22, 2022

Greetings to all. Today, we'll explore how gcloud organization policy might help in establishing standards across the projects and see what would be the impact if no actions were taken.

What is organization policy and why do I need to change them?
Organization policies are made up of constraints that define the set of rules and restrictions for using resources across the projects. There are a few policies that could potentially have an impact on the projects, leaving them enabled by default. We will see a few of them which can be helpful in tightening the security of the GCP environment.

Note:- Changes to most of the organization policies will not affect the existing resources/permissions, they will be enforced only on new changes. However, there are very few policies that would revoke existing permissions as well, ensure to confirm the same before any policy enforcement.
Access the org policies via the below link
https://console.cloud.google.com/iam-admin/orgpolicies/list?organizationId=your_gcp_org_id_here

Below are some of the policies that would be good to be enforced to secure the GCP.

Disable the default network creations
Having this enabled will create a default VPC network in new projects and below default firewall rules that exposes RDP and ssh port as well as ICMP on all instances in the network to the entire internet which could lead to an attack exposure if instances get attached with public IP.

Ensure this org policy will be enforced to avoid the creation of a default network. If it is already being used in the current environment, ensure the above listed firewall rules are deleted on all existing projects.
Run the below command to audit all firewall rules across the projects and find any rule names that match above.

gcloud asset search-all-resources --asset-types=compute.googleapis.com/firewall --scope=organizations/your_org_id_here --format="table(displayName,project)"

Disable Automatic IAM Grants for Default Service Accounts
Having this enabled by default on your org policies will create a default service account for computing and cloud services that will have an editor role by default

surely hope you don’t want to provide access to any user as an editor who accesses the service account binded with the VM instance and any components which could be leveraged for taking various controls over the GCP project. Ensure this policy is enforced and recheck all your GCP project’s default service account privileges.

Below are the default service accounts that are created by gcloud
project-id@appspot.gserviceaccount.com
project-number-compute@developer.gserviceaccount.com

project-number@cloudservices.gserviceaccount.com
Read More on the default services here

Enforce Public Access Prevention
If you wanted to restrict someone from accidentally exposing the storage bucket publicly, this policy would help to mitigate such incidents. This will prevent the storage buckets from exposing them publicly. Also, enforcing this policy will revoke all existing buckets that have public permission allusers/allauthenticatedusers on the IAM level or ACL level.

If there are use cases to have objects exposed publicly and you can’t enforce this policy, do consider using fine-grained access for buckets, which will allow setting the permissions on the object level to the public rather than exposing the whole bucket to the public. Exposing the whole bucket to the public will leak the key identifiers of all objects in the bucket. Using fine-grained access you can programmatically enforce individual objects to the public. Refer to doc here on same.

Domain restricted sharing
By default, all domain entities are allowed to be added in IAM policies in gcloud, like gmail.com or any other domain. Enabling this policy by enforcing principals that belong to the either allowed or deny customer ID workspace domains would avoid the addition of unwanted domain IDs. By adding your workspace ID in enforcement, you can limit the domains that belong to your workspace domains by selecting allow policy type.

To get the customer IDs for your own workspace refer here.

Run an audit across your GCP org to find if there are any third-party domain ID’s been added to IAM policies and perform the cleanup.

gcloud beta asset search-all-iam-policies --scope=organizations/your_gcp_org_id_here

Disable VM serial port access
Access to VM serial port access doesn’t have IP restrictions. Anyone having instance ssh user and keys leads could get access to any person even without IAM access. Keeping this enforced would help ensure none of the VMs get VM serial port access enabled.

Disable service account key creation
By default, the creation of service account keys will set the key to expire to “Jan 10000”, which will lead to having the key to authenticate SA forever and never expire. This policy should be enforced in order to prevent key misuse and to establish a standard key rotation policy in the organization to limit key creations.
We have earlier discussed the service account key’s best security practice here

Restrict Public IP access on Cloud SQL instances
Choosing the default configurations on the creation of cloud SQL instance via console leads to having public IP attached. Though authorized networks are to be added specifically, having the SQL on the internal network is the best practice rather than getting them access via public IP. Enforcing this will help to reduce the Cloud SQL’s exposure over the public network.

I hope this will be helpful with auditing and enforcing some security standards in your GCP environment. See you soon again

--

--