Securing Your Cloud, Part 1: Google Cloud Platform Done Right

This is part 1 of GRAYTECH.ONE's "Securing Your Cloud" series — practical hardening for the three big clouds. Part 2 covers Azure, part 3 covers AWS.

Google Cloud Platform is the least forgiving of the three big clouds when you get identity wrong — and the most forgiving when you set it up right. The problem: most small teams never set it up right. They sign up, create a project, click "Enable API," and start pasting service account keys into scripts. Six months later they have a folder of .json key files that could spin up a crypto farm on their card, and no idea which one still works.

Here's the sane baseline, in priority order.

1. Kill long-lived service account keys

GCP service accounts support a dozen auth methods, but the one everybody uses — downloadable JSON keys — is the one Google's own threat reports flag most. A leaked key is a permanent skeleton key: it doesn't expire, doesn't rotate, and doesn't log in like a human would.

• Run the built-in scanner: gcloud recommender and IAM's "intelligence" view flag unused keys and over-privileged accounts. Act on everything it surfaces.
• Replace keys with Workload Identity. Anything running in GKE, Cloud Run, or a Compute Engine VM should use the built-in service identity — no key file exists to steal. This is the single biggest GCP win for most small teams.
• If a third party demands a key, scope it to one role on one project, set an expiry reminder, and store it in Secret Manager — not a shared drive.

2. Lock down the project hierarchy early

GCP's resource hierarchy (Organization → Folder → Project) is your blast-radius dial. The cheap version: separate prod and everything-else projects from day one, so an experiment can never touch production data. Attach IAM grants at the highest level that works — but prefer project-level bindings over organization-wide ones.

Two policies worth setting before you do anything else:

• Domain-restricted sharing — org policy that blocks buckets and datasets from being shared outside your domain. Public data leaks are almost always a bucket someone set to "allUsers" for one demo and forgot.
• Disable service account key creation as a default org policy. Exceptions become explicit, reviewed decisions instead of silent habits.

3. Get the network posture right the boring way

GCP's VPC defaults are better than AWS's — no public IP by default, firewall rules deny by default — but the default VPC that comes with every new project has permissive rules baked in. Delete the default-allow rules, then:

• No 0.0.0.0/0 on SSH or RDP. IAP tunnels (Identity-Aware Proxy) give you SSH and RDP through the console with zero open ports. It's free. Use it.
• Private Google Access for internal-only instances so they can reach Google APIs without public IPs.
• VPC Service Controls if you're handling anything regulated — they draw a hard perimeter around your managed services that even leaked credentials can't cross.

4. Turn on the free log sources

Cloud Audit Logs are on by default — the mistake is nobody reading them. At minimum: export Admin Activity logs to a bucket with retention, and set alerts on the four events that matter:

1. A service account key is created
2. An IAM role is granted at the org or folder level
3. A bucket's IAM is set to public
4. A firewall rule opens 0.0.0.0/0 to SSH, RDP, or database ports

Those four cover the majority of real GCP breaches in the wild. A 20-line Cloud Function or a Log Router sink to a chat webhook turns each one into a page instead of a discovery.

5. The GCP five-minute audit

1. gcloud asset search-all-resources --scope=organizations/YOUR_ORG --asset-types=cloudresourcemanager.googleapis.com/Project — do you recognize every project?
2. IAM page → sort by Owner and Editor — every human there should be justified out loud.
3. gcloud storage buckets list --format="csv(name,iamConfiguration)" — scan for allUsers or allAuthenticatedUsers.
4. Check service account key count: Security Command Center → "Service account keys older than 90 days."
5. VPC firewall rules: filter for 0.0.0.0/0 on ports 22, 3389, 3306, 5432, 5432. Each hit is a finding.

GCP rewards teams that keep identity tight and networks boring. Get those two right and the platform's defaults do most of the guarding for you — which is exactly what a small team needs: security you set once and stop thinking about.