Add passwordCommand option for SQL datastore credentials#9879
Add passwordCommand option for SQL datastore credentials#9879simvlad wants to merge 1 commit intotemporalio:mainfrom
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8de94ce5c9
ℹ️ About Codex in GitHub
Your team has set up Codex to 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 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| db, err = d.CreateRefreshableConnection(func() (string, error) { | ||
| return buildDSN(cfg, resolver) |
There was a problem hiding this comment.
Capture immutable DB name for refreshable DSN builder
When passwordCommand is enabled, this closure rebuilds DSNs from the mutable cfg pointer for every new physical connection. In common/persistence/sql/sqlplugin/postgresql/plugin.go, createDBConnection temporarily sets cfg.DatabaseName to probe default DBs and then defers resetting it to ""; after that reset, later pool reconnects will call this closure and generate DSNs with an empty database name. That can cause reconnects to target the wrong database or fail after the initial connection is recycled, so the refresh DSN builder should not depend on mutable cfg.DatabaseName state.
Useful? React with 👍 / 👎.
What changed?
Add a
passwordCommandconfig option for SQL datastores that executes an external command to fetch the database password instead of using a staticpasswordfield. When configured, each new physical database connection re-executes the command to get a fresh credential viaRefreshingConnector, enabling short-lived tokens (e.g. cloud IAM tokens) to be used as database passwords. Supported for MySQL, PostgreSQL (both pgx and pq drivers).Why?
Cloud-managed databases (e.g. AWS RDS, GCP Cloud SQL) authenticate using short-lived IAM tokens rather than static passwords. There was no way to integrate an external credential source into Temporal's SQL config without forking the code.
passwordCommandlets operators plug in any token-fetching tool (e.g.aws rds generate-db-auth-token) via config.This approach is vendor-agnostic: any command that writes a password to stdout works, with no SDK dependencies or provider-specific code in Temporal.
How did you test it?
Tested with GCP, setting up a Postgres database and using it for the server backend
Potential risks
passwordCommandexecutes an arbitrary external command. Misconfiguration will cause connection failuresMaxConnLifetime, there is no built-in mechanism to detect or handle expired credentials on existing connections. Richer integration (e.g. parsing expiry from the command output and automatically setting connection lifetime) is possible but intentionally omitted here as it would be vendor-specific. The good news, is that most cloud APIs return tokens with a known, fixed TTL (e.g. 15 minutes for AWS RDS, 1 hour for GCP Cloud SQL).