The database breach started with a single misconfigured delivery pipeline. One overlooked permission let a service account touch data it was never supposed to see. Hours later, the team realized their automated deployment system was the weakest point in their security.
Delivery pipelines on GCP need to do one thing well: move code from build to production safely. But when that pipeline needs database access, the stakes get higher. Every credential, role, and permission is now part of the attack surface. Without strict controls, the same automation that powers releases can also power a leak.
The first rule is least privilege. Your CI/CD system on GCP should never have full access to a production database unless absolutely required. Use separate service accounts for build, deploy, and migration steps. Bind IAM roles with precision. If a job’s only purpose is to run read-only queries for migrations, give it only that.
Rotate credentials and avoid storing secrets in plain text. Use Google Secret Manager or similar tooling to inject secrets only at runtime. Keep them out of source control. Review permissions often; pipelines grow messy over time. What started as a clean YAML file can drift into a permissions tangle if ignored.