Google Cloud Security Checklist: What to Check in Your Project

Most Google Cloud security problems are not attacks. They are defaults that made sense for getting you started, left in place long after you stopped being started.

Here is the list I would run on a project I had just been handed, in order. The quotes below are Google's own words, and every item is checkable in a few minutes.

1. The identity every VM runs as

Start here. This is the one with the widest blast radius and the fewest people checking it.

When you enable Compute Engine, Google creates a default service account. Google's description of what happens next: "Depending on your organization policy configuration, the default service account might automatically be granted the Editor role on your project."

Editor on the project. Not on one machine, on the project.

Now the second half, because on its own the first half is survivable. That same account is, in Google's words, "Attached by default to all VMs that you created by using the Google Cloud CLI or the Google Cloud console."

Put those together. Every virtual machine you made through the console is running as an identity that may be able to edit almost everything in the project. If one of those machines is a web server, and that web server gets compromised, the attacker does not have a web server. They have the project.

Google is not quiet about this. They say: "We strongly recommend that you disable the automatic role grant by enforcing the iam.automaticIamGrantsForDefaultServiceAccounts organization policy constraint." And for projects where it has already happened: "If the default service account already has the Editor role, we recommend that you replace the Editor role with less permissive roles."

To check yours, go to IAM and admin, then IAM, and look for the principal ending in compute@developer.gserviceaccount.com. Whatever role sits next to it is what your machines can do.

2. Port 22, open to everyone, from the start

Every project gets a network called default, and that network arrives pre-populated with four firewall rules. Two of them are worth your attention.

default-allow-ssh permits tcp:22 from source range 0.0.0.0/0. default-allow-rdp permits tcp:3389 from 0.0.0.0/0.

That is SSH and Remote Desktop, reachable from every address on the internet, on a network you did not configure, in a project you just created. It exists so that your first machine is reachable without you having to learn firewall rules on day one, which is a reasonable trade for a tutorial and a bad one for anything real.

There is a third, default-allow-internal, which allows tcp and udp on every port from 10.128.0.0/9. That one is internal rather than public, and it means anything inside your network can reach anything else inside it on any port. Flat, by default.

Google notes these rules "can be deleted or modified as necessary". They are not permanent and nothing protects them. Go to VPC network, then Firewall, and see which of them are still there and which of your machines sit on that default network.

The fix is not usually to delete the rule and lock yourself out. Narrow the source range to the addresses you actually connect from, or move to Identity-Aware Proxy so you are not exposing the port at all.

3. "Authenticated" does not mean what you think

There are two special principals in Google Cloud that grant access to groups of people rather than to individuals, and the names mislead almost everyone the first time.

allUsers means anyone on the internet, no sign-in required. Everybody understands that one and treats it carefully.

allAuthenticatedUsers means anyone with a Google account.

Anyone. Not anyone in your company, not anyone you invited. Any person on earth with a Gmail address is an authenticated user. The word authenticated makes it sound like a fence, and there is no fence, because signing in to Google costs nothing and takes a minute.

This is how storage buckets people believed were internal turn out not to be. Search your IAM policies and bucket permissions for both strings. allAuthenticatedUsers in particular has almost no legitimate use, and finding it is usually finding a misunderstanding rather than a decision.

4. Stop it happening again

Cloud Storage has a setting called public access prevention. Turn it on and requests authorised through allUsers or allAuthenticatedUsers fail with a 401 or 403, no matter what anybody sets afterwards.

You can enforce it per bucket, or across a whole project, folder or organisation with the storage.publicAccessPrevention constraint. The organisation-level version is the one worth doing, because it stops the next person making the mistake rather than fixing this one.

This is the most valuable item on the list, and it takes about a minute. Everything else here is finding problems. This one removes a class of problem.

5. Keys that never expire

A service account key is a JSON file you download. It is a password that does not rotate, does not expire on its own, and works from anywhere in the world for whoever holds it.

They get created for a good reason and then they live forever. In a laptop's downloads folder, in a CI variable, in a chat message from two jobs ago, in a repository somebody made public later.

Go to IAM and admin, then Service accounts, and look at the keys on each one. For anything running inside Google Cloud, you should not need a key at all: attach a service account to the resource and it gets credentials automatically. Those are the keys worth removing first, because they are the ones nothing will break without.

6. The three roles that are too big

Owner, Editor and Viewer are the old basic roles, and they are still the easiest thing to click. Editor in particular gets handed out constantly because it makes the immediate problem go away.

Open IAM and count how many people and service accounts hold Owner or Editor at project level. For most small teams that number is higher than anyone would guess, and each one is a full set of keys to everything.

You do not have to fix this today. Write the list down, and each time somebody actually uses their access, ask what they needed it for. After a month you will know which ones can move to something narrower, from evidence rather than from guessing.

Where we are with this

Honestly: Liberra is an AI that connects to your cloud, keeps an index of what is in it, and answers questions like "what is open to the internet" without you opening six screens. That runs on AWS and Azure today, including a real Prowler scan on both. Google Cloud is next. I am not giving you a date, because a date promised before something ships is just a guess said confidently.

So run the list above yourself. It is free, and the first item alone is worth the afternoon.

One thing I will say about the shape of it, because it matters more than which clouds we cover. Liberra cannot delete anything, on any cloud. The delete commands are blocked in the code, not in a permission somebody has to configure correctly. A tool you point at your project to find security problems should not be able to become one, and the only version of that promise worth anything is the one the code enforces rather than the one the marketing page makes.

Founder, Liberra AI