Google Cloud (GCP) Security Checklist

Google Cloud has strong defaults in many areas, but projects grow quickly and permissions accumulate. This checklist covers the controls that matter most for startups and SaaS teams running on GCP.

Identity and access management

• Avoid basic roles like Owner and Editor for day-to-day use. Grant predefined or custom roles with least privilege.
• Use groups for human access rather than individual bindings.
• Enforce MFA for all Google accounts with access, through Google Workspace or Cloud Identity settings.
• Review IAM regularly with the IAM Recommender, which suggests removing unused permissions.

Service accounts

Service accounts are the most common source of excessive privilege in GCP.

• Do not use the default compute service account with the Editor role for workloads. Create dedicated service accounts per workload.
• Avoid service account keys. Use attached service accounts and Workload Identity Federation for external systems, such as CI/CD.
• Restrict who can impersonate service accounts, as iam.serviceAccountUser and token creator roles allow privilege escalation.
• Use organisation policies to block service account key creation where possible.

Cloud Storage

• Enforce public access prevention at the organisation or project level.
• Use uniform bucket-level access, disabling object ACLs.
• Use signed URLs with short expiry for temporary access, generated only after authorisation checks.
• Enable versioning or retention policies for critical data.

Networking

• Limit firewall rules allowing 0.0.0.0/0, especially on SSH and RDP. Use Identity-Aware Proxy for administrative access.
• Use Private Google Access and private IPs for databases.
• Consider VPC Service Controls to reduce data exfiltration risk for sensitive services.

Cloud Run and Cloud Functions

• Require authentication unless a service is meant to be public, and avoid granting allUsers invoker access by accident.
• Assign a dedicated service account with minimal permissions to each service.
• Use ingress settings to restrict internal services to internal traffic or a load balancer.

Secrets

• Store secrets in Secret Manager, not environment variables in plaintext or code.
• Grant secret access per workload, not project-wide.

Logging and detection

• Keep Admin Activity audit logs and enable Data Access logs for sensitive services.
• Route logs to a central, protected project.
• Enable Security Command Center at a tier appropriate for your needs.

Organisation policies worth enabling

Testing your GCP exposure

SecurityInfinity tests your internet-facing GCP services, including Cloud Run, load balancers, storage and exposed ports, and application flaws like SSRF that could reach the metadata server. Start free.

Frequently asked questions

Do I need permission to pentest Google Cloud?

Google does not require you to notify them before testing your own projects, but you must follow its acceptable use policy and terms.

Is the default service account dangerous?

In many projects it has the broad Editor role. Any workload running as it, if compromised, can affect most of the project.

What is Workload Identity Federation?

A way for external workloads, such as GitHub Actions, to access GCP without service account keys, using short-lived tokens.