The alert fired at 02:17. Unauthorized query against a production GCP database. The Kubernetes cluster logs showed nothing unusual—at first glance.
Securing GCP database access from workloads running in Kubernetes is no longer optional. Attackers exploit gaps between cluster-level RBAC, service account scopes, and database IAM roles. To lock this down, you must control identity, network paths, and credential lifetimes with precision.
Start with GCP IAM as the single source of truth. Avoid static database credentials entirely. Use Cloud SQL IAM or IAM DB authentication to bind access to GCP identities. Map Kubernetes service accounts to GCP service accounts using Workload Identity. This ensures pods inherit the exact IAM permissions you define—no more, no less.
Restrict outbound connectivity from Kubernetes namespaces. Use VPC Service Controls to prevent traffic to databases outside your protected perimeter. Combine with Network Policies in Kubernetes to whitelist only the pods that need database access. Log and monitor every connection attempt at both the Kubernetes and GCP network layers.