Org Policies by default
There are currently (October, 2021) more than 60 organization policies in Google Cloud. What would be a list of the more important ones to enable is a recurrent topic from customers, especially at the beginning of their journey to cloud. I will try to answer that in this article.
A bit of context
An organization policy is a restriction or constraint that you can set over the use of a service. For example, you may want to restrict the use of public IPs to some specifics VMs only (or none). The restriction is set on a resource hierarchy node, meaning you set it at the organization, folder, or project level. The types of restrictions and how inheritance is applied is well explained in the public documentation.
I will just mention there are two types, list and boolean. A list allows you to specify the set of allowed or denied values, such as the VMs allowed to have an external IP. A boolean is to enforce a given restriction, such as whether external service account keys can be created.
How to choose
Now comes the question, and the doubts. Org policies are there to serve as guardrails for your teams, to ensure you stay within compliance and improve your security posture. So maybe the first approach could be: if it is for being more secure, why not to enable all of them?
Well, you may think you have solved the problem of deciding. I'd say it's just the opposite because now you have new ones. Enabling a constraint means deciding about things related to your deployments on GCP, the services you will use, your teams' workflows, your policies for different environments… and configuring it properly. This requires comprehensive knowledge that usually takes time to gain and resources to execute. E.g. you may enable to use private OS images only, but not have the proper team with the skills to create those hardened images. And of course some policies may not make any sense to you because you don't plan to use the service it applies to.
Then, how to create a sensible list of org policies to consider? My approach will be to choose the more common ones which are quick wins with an estimated low effort for an average company, meaning many customers might benefit from applying such policies.
I will introduce them but won't elaborate on them, you can find the details for each policy and some examples on the public documentation. Let's see that list!
And the winners are…
- Restrict Public IP access on Cloud SQL instances
Self-explanatory, you should keep your systems out of public reach as much as possible. Planning for mainly private connectivity is a must. - Enforce Public Access Prevention
Secure your Cloud Storage data from public exposure, in the same spirit as with the network. Only authorized people and not all users should have access to your data. - Enforce uniform bucket-level access
Ensure all your Cloud Storage objects have the same permissions applied, that of the bucket. That will make easier to control and audit every object has appropriate permissions. - Disable VM serial port access
An interactive serial port is rarely required, and an attack vector to gain access. If you need its output you can get it from Cloud Logging. - Define allowed external IPs for VM instances
Again, keep your systems out of public reach as much as possible avoiding the use of public IPs. - Domain restricted sharing
Restrict which domains can be added to an IAM policy and get permissions on your resources. Only users in your organization should, you don't want to allow random gmail accounts access your systems, do you? - Disable service account key creation
Service account keys represent a big responsibility and security risk, and you should employ Google-managed keys as much as possible. For the few cases when that's not possible you may want to read this article. - Disable service account key upload
Another way to use user-managed keys is to create them locally and upload them to Cloud. Again, try not to rely on it. - Restrict shared VPC project lien removal
A shared VPC project is a very important piece in a deployment since its VPC usually hosts many service projects. Protect yourself from errors adding one more step (and IAM permissions) to delete it.
Anything else?
After reading this list a common ask is: with so many org policies, wouldn't you enable anything else? Apart from those for services you may not use, there are other policies that may be technically interesting but still more difficult to implement or with a perceived little value. Considering these concerns, I have compiled a second list with those that I think more relevant.
- Google Cloud Platform — Detailed Audit Logging Mode
Cloud Storage can log both the request and response, and this may be relevant for those industries subject to specific compliance requirements. - Require OS Login
OS Login is a superior mechanism to SSH to log into a machine (I need to write an article on this). I understand changing procedures is not a trivial task, but it's worth. - Shielded VMs
If you can use shielded images, you can easily get the benefits of security controls shielded VMs offer against rootkits and remote attacks. - Restrict Cloud NAT usage
Instead of using public IPs you should use services like Cloud NAT to gain external access. Still, this access should be under control and possibly only for some proxies. - Restrict Non-Confidential Computing
Encryption of data in use in Cloud, is a really interesting feature especially for regulated industries and highly sensitive workloads. Google Cloud makes it really simple to achieve. - Define trusted image projects
Allowing only a curated set of OS images, either from you or provided and maintained by Google, it's a way to improve your stability and security. - Disable Automatic IAM Grants for Default Service Accounts
Default service accounts with default (wide) permissions are good for testing things but not the best approach for your production workloads. Disabling these grants, though, implies you need to explicitly grant the required permissions to each service account.
Recap
I created this list(s) to give you both a recommendation and a starting point to discuss which org policies better fit your company. Obviously creating any list can leave out some policies that may fulfill a valid use case. I think most of the ones listed here will resonate with your business, but you should review them and consider any others that may apply to your use case.
A reasonable approach could be to use this list to start with, after a quick check it makes sense. Then as you continue your journey to Cloud and gain experience you will learn by yourself which others may be relevant. I hope I helped in that journey!
