GCP Security Pitfalls: A Practical Checklist to Prevent with Service Accounts, IAM, and Audit Logs

Translated from 日本語 • View original

西田

Hello, this is Nishida from Colorkrew Security. These are three common security oversights in organizations using Google Cloud (GCP).

"The service account key was reused"
"Anyone can see BigQuery data."
"Audit logging is not enabled"

1. GCP's 3 major patterns of "leaking here"

Pattern (1): Lack of Management of Service Account Keys

A GCP service account is an "identity card" that allows applications to access GCP resources.

Problematic cases:

There are multiple SA keys with the equivalent of 'Project Editor' and 'Owner'.
No key rotation and use the same key for several years
The key is stored in a Git repository or shared drive

Measures:
Whenever possible, use Workload Identity without using an SA key (GCE/GKE allows you to call Google APIs without a key).

Pattern (2): IAM Privilege Bloat

In many cases, small teams grant "Editor permissions" to everyone and leave it as it is.

Checkpoints:

Are 'roles/owner' or 'roles/editor' assigned directly to your personal account?
Are there any accounts left for retirees or job changers?
Do you have an inventory of group memberships?

Pattern (3): Mispublication of Objects (GCS, etc.)

Granting permissions to 'allUsers' and 'allAuthenticatedUsers' in a Cloud Storage (GCS) bucket effectively means that it is publicly available globally.

2. IAM Design Points

Ensuring Least Privilege

'roles/editor' is useful but dangerous.
We recommend using custom roles that grant only the permissions you actually need.

# Bad example
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="user:dev@example.com" \
  --role="roles/editor"

# Good example: Only the services you need
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="user:dev@example.com" \
  --role="roles/cloudsql.client"

Utilizing Condition (Conditional IAM)

IAM bindings are conditioned by time and resource path.
Access to production can be restricted to specific projects only during business hours.

3. What to expect from Cloud Audit Logs

There are three types of GCP Audit Logs:

Log Type	Recording Contents	Default
Admin Activity	Changing Settings and IAM	Auto-enable (non-deactivated)
Data Access	Read and Modify Data	Disabled by default
System Event	Automated Operations Inside GCP	Auto-Enable

Special Note: Data Access logs are disabled by default.
To access BigQuery and GCS, you need to explicitly enable it.

4. Monitoring: Leveraging the Security Command Center (SCC)

GCP standard security dashboard.

Key issues detected by SCC:

Published GCS buckets
Suspicious use of SA keys
Detect excessive privileges
Abnormal data transfer to the outside world

Use the Premium Tier (formerly Security Health Analytics + Event Threat Detection) in SCC to improve the accuracy of threat detection.

5. Colorkrew Security's Approach

Colorkrew Security supports security design, inventory, and audit log design for GCP environments.
GCP is not always safe with "default settings". Keeping in mind the three points of SA key, IAM, and audit logs is the first step in GCP security.