GCP Security Assessment Guide

Introduction

Consider a common scenario: a machine learning startup uses Google Cloud for analytics workloads. Data engineers create multiple service accounts for pipelines, and permissions get granted incrementally as needs arise. A service account key is accidentally committed to a public repository. Attackers who obtain the key may be able to access more than intended (for example, Cloud Storage buckets containing sensitive data) because the service account accumulated permissions over time.

GCP's IAM model can become difficult to audit as organizations scale. Service accounts proliferate, permissions accumulate, and access relationships become opaque. This guide covers GCP penetration testing guidelines, common vulnerabilities, and assessment strategies.

GCP Penetration Testing Guidelines

Google Cloud permits security testing on your own projects without prior notification, provided you follow acceptable use policies. You may test resources within projects you own or have authorization to test.

Prohibited activities include:

• Denial of Service attacks
• Spam or phishing from GCP resources
• Cryptomining
• Testing resources belonging to other customers
• Intentionally circumventing billing controls

Unlike AWS and Azure, Google doesn't require notification for penetration testing of your own resources. However, if your testing might trigger abuse detection systems, you may want to notify them to prevent service disruption.

Testing IAM and Service Accounts

Service accounts deserve particular scrutiny—they're often over-privileged and their keys can be exposed.

# List all service accounts
gcloud iam service-accounts list --project=<project-id>
 
# List keys (look for multiple or old keys)
gcloud iam service-accounts keys list --iam-account=<service-account-email>
 
# Check what roles a service account has
gcloud projects get-iam-policy <project-id> \
  --flatten="bindings[].members" \
  --filter="bindings.members:<service-account-email>" \
  --format="table(bindings.role)"

Common misconfigurations:

• Service accounts with roles/owner or roles/editor (overly broad)
• Service accounts that can impersonate other service accounts
• Permissions granted at organization or folder level unnecessarily
• Multiple user-managed keys (suggests poor key management)
• Keys older than 90 days (should be rotated)

Service Account Impersonation Chains: If Service Account A can generate tokens for Service Account B, compromising A grants access to B's permissions. Map these chains to understand actual privilege exposure.

Key Exposure: Search code repositories and CI/CD configurations for accidentally committed keys (JSON files with "type": "service_account").

Testing Cloud Storage Security

# Get IAM policy for a bucket
gsutil iam get gs://<bucket-name>
 
# Check uniform bucket-level access
gsutil uniformbucketlevelaccess get gs://<bucket-name>
 
# Check if bucket is publicly accessible
gsutil ls -L -b gs://<bucket-name> | grep -i "public"

Dangerous configurations include allUsers or allAuthenticatedUsers with any role. Without uniform bucket-level access, both ACLs and IAM policies apply, creating complexity and potential gaps.

Bucket Enumeration: Even private buckets can leak information if attackers can confirm their existence through different error responses.

Testing Compute Engine Security

Metadata Service: GCP's metadata service provides access to service account tokens. Test for SSRF vulnerabilities:

# From within a VM
curl -H "Metadata-Flavor: Google" \
  http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token

Unlike AWS IMDSv2, GCP's metadata service only requires the header, not a session token.

Firewall Rules: Find rules allowing broad access:

gcloud compute firewall-rules list --filter="sourceRanges=0.0.0.0/0"
gcloud compute firewall-rules list --format="table(name,network,direction,allowed,sourceRanges)"

Serial Port Output: VM serial console output may contain sensitive information:

gcloud compute instances get-serial-port-output <instance-name> --zone=<zone>

Startup Scripts: Check for secrets:

gcloud compute instances describe <instance-name> --zone=<zone> \
  --format="value(metadata.items[key='startup-script'].value)"

Testing GKE Security

# Check for legacy ABAC (should be disabled)
gcloud container clusters describe <cluster-name> --zone=<zone> \
  --format="value(legacyAbac.enabled)"
 
# Check if Workload Identity is enabled
gcloud container clusters describe <cluster-name> --zone=<zone> \
  --format="value(workloadIdentityConfig.workloadPool)"
 
# Check node pool configuration
gcloud container node-pools describe <pool-name> \
  --cluster=<cluster-name> --zone=<zone>

Without Workload Identity, pods can access the node's service account via the metadata server, leading to privilege escalation. Also check for client certificate authentication enabled and master authorized networks not configured.

Testing BigQuery and Data Services

# Get dataset access controls
bq show --format=prettyjson <project>:<dataset>

Look for public datasets and overly broad project-level access. Data Access audit logs are not enabled by default and must be explicitly configured.

Testing Cloud Functions

# List functions and their triggers
gcloud functions list --format="table(name,trigger,runtime)"
 
# Get function details
gcloud functions describe <function-name> --format=json

Test for HTTP-triggered functions without authentication, environment variables containing secrets, and service accounts with excessive permissions.

Organization Policies

Important policies to verify:

• constraints/iam.disableServiceAccountKeyCreation (prevents key exposure)
• constraints/compute.vmExternalIpAccess (restricts public IPs)
• constraints/storage.publicAccessPrevention (prevents public buckets)

Logging and Detection

# Check audit log configuration
gcloud logging sinks list
 
# Query for security-relevant events
gcloud logging read "protoPayload.methodName:SetIamPolicy"

Verify Admin Activity logs (enabled by default), Data Access logs (must be enabled), log sinks to secure storage, and alerting on suspicious activities.

Conclusion

GCP security assessment requires understanding its unique IAM model and the proliferation of service accounts. Service accounts are particularly high-risk—they accumulate permissions over time, their keys can be exposed, and they often have access to sensitive data.

Regular security testing helps identify misconfigurations before they're exploited. On-demand testing allows teams to assess GCP configurations as infrastructure evolves. RedVeil's AI-powered platform can help identify security issues in your GCP-hosted applications and infrastructure.

Start testing your GCP environment with RedVeil today.