I am tired of hardcoding database passwords in my Terraform variables. I want to integrate GCP Secret Manager so that I can reference secrets during deployment.
How do I configure the Terraform provider to read from Secret Manager? Is there a standard pattern for fetching these values at runtime? I want to make sure my IaC is secure and follows the principle of least privilege.
Terraform accesses sensitive data by using the google_secret_manager_secret_version data source to retrieve values at runtime, authenticated via a service account with the secretAccessor IAM role.
4 answers
Integrating Secret Manager correctly requires a clean lifecycle for your sensitive values and a strict adherence to permissions.
- Define the secret in GCP first and store the secret version payload.
- Use the data source for your secret in the Terraform configuration file.
- Reference the data source attribute in your resource blocks instead of using variables.
- Apply the IAM role roles/secretmanager.secretAccessor specifically to the identity running the Terraform process.
You should utilize the google_secret_manager_secret_version data source to pull your values at runtime rather than storing them in variables. This ensures that the sensitive payload is fetched only during the Terraform plan or apply execution from your authenticated shell or service account, which keeps the cleartext out of your state files and local variable files.
I remember auditing a legacy monolith back in 2019 where the developer had base64 encoded the database credentials inside a standard variables file thinking it was secure enough. I had to spend three days scrubbing the entire VCS history after we realized those values were floating in plain text throughout the CI/CD logs.
Ever since that mess, I insist that developers use a proper secret lifecycle. You fetch the payload dynamically, map it to the resource attribute during the apply phase, and ensure your service account has strictly the secret accessor role.
Using the native data source is often preferred for operational simplicity because it ties directly into the GCP API at runtime, but using an external vault provider is sometimes necessary if you have multi-cloud compliance requirements. The native data source approach is cleaner for purely GCP environments as it keeps your architecture focused without adding third-party dependencies. However, if your security team mandates central secret auditing across non-GCP platforms, you might find that a cross-platform provider is better suited for your long-term governance strategy.
