Database access security in GCP with Kubernetes ingress is not a checkbox. It is a design. It is permissions, network policy, identity, and ingress rules working as one system. When they drift apart, attackers find the cracks.
The first step is to cut public access. In GCP, use private IP for Cloud SQL or other managed databases. Route traffic only from the Kubernetes cluster’s VPC. Lock down firewall rules so that no external IP can talk to the database directly.
Then, control who gets in from inside the cluster. Identity-Aware Proxy can enforce user identity, but for workloads, use Workload Identity over service account keys. This removes static credentials and ties access to Kubernetes service accounts. Rotations, key storage, and leaks stop being your nightmare.
Ingress in Kubernetes has one job: manage traffic from outside into the cluster. By default, it does far more than you might want. For sensitive paths that connect to a database proxy or API, set up strict ingress controllers. Use HTTPS everywhere. Terminate TLS using managed certificates or cert-manager. Enable authentication at the ingress level before the request even hits the pod.