chore(terraform): load dashboard supabase DB URL from Secret Manager

[ben-fornefeld]

Summary

• create a dedicated GCP Secret Manager secret for dashboard-api's SUPABASE_DB_CONNECTION_STRING
• pass the secret version through the provider-gcp Nomad module and read the value at deploy time instead of using a plain Terraform variable
• remove the now-unused root/module Terraform variable and keep the secret version placeholder managed separately from the real secret value

Validation

• ran terraform fmt -recursive in iac/provider-gcp
• ran terraform validate in iac/provider-gcp

[cursor]

PR Summary

Medium Risk
Changes how dashboard-api receives its Supabase DB connection string, so misconfigured/empty Secret Manager values could break deploys at runtime. Scope is limited to Terraform wiring and secret resources, with no application logic changes.

Overview
Moves dashboard-api’s SUPABASE_DB_CONNECTION_STRING from a sensitive Terraform variable to a dedicated GCP Secret Manager secret, wiring the secret version through the Nomad module and reading/trimspaceing it at deploy time while removing the now-unused Terraform input variable and keeping the placeholder secret version managed via ignore_changes.

^{Reviewed by Cursor Bugbot for commit 409783a. Bugbot is set up for automated code reviews on this repo. Configure here.}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 409783a8e1

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Preserve existing Supabase DB secret during migration

For environments that currently set supabase_db_connection_string via Terraform input, this introduces a breaking migration path: the variable is removed in this commit, while the new managed secret version is initialized to a blank placeholder (" "). On the first terraform apply, Nomad reads that placeholder and dashboard-api receives an empty SUPABASE_DB_CONNECTION_STRING, so it falls back to POSTGRES_CONNECTION_STRING instead of the previously configured Supabase DB. This silently changes runtime DB wiring until operators manually add a new secret version and redeploy, so the migration should preserve the previous value for at least one apply (or include an explicit transition step).

Useful? React with 👍 / 👎.

[ben-fornefeld]

not necessary

[claude]

LGTM — straightforward migration of the Supabase DB connection string from a plain Terraform variable to Secret Manager, following the established pattern already used for other secrets in this codebase.

Extended reasoning...

Overview\nThis PR modifies five Terraform files in iac/provider-gcp to move the supabase_db_connection_string for dashboard-api from a plain sensitive Terraform variable into GCP Secret Manager. A new secret resource and placeholder version (with ignore_changes = [secret_data]) are created in api.tf, the variable is dropped from both variables.tf files, and the Nomad module receives the secret version object instead, reading the actual value via a google_secret_manager_secret_version data source at deploy time.\n\n### Security risks\nThis is a net security improvement. Previously the connection string was passed as a Terraform variable, meaning it would be stored in Terraform state in plaintext. The new approach stores only a placeholder in state and retrieves the real value from Secret Manager at runtime, consistent with how other sensitive credentials (postgres read replica, redis, etc.) are already handled.\n\n### Level of scrutiny\nLow — this is a mechanical refactor following an established pattern already used multiple times in the same module. The author validated with terraform fmt -recursive and terraform validate. No logic changes, only wiring changes.\n\n### Other factors\nNo bugs were found by the bug hunting system. The change is small, self-contained, and mirrors the postgres_read_replica_connection_string pattern exactly.