Cloud Database Cert/IAM Connections

[vedosis]

Is your feature request related to a problem? Please describe.

When running Temporal Server in cloud-managed Kubernetes (AWS EKS, GCP GKE), users must manage database credentials as secrets. All major cloud providers support zero-secret database authentication using workload identity, but Temporal doesn't provide a way to use these features.

The existing Connect hook is undocumented and requires making local code changes and custom builds, making it impractical for most users.

Describe the solution you'd like

Add built-in support for cloud database authentication in Temporal's SQL configuration:

persistence:
  default:
    sql:
      pluginName: "mysql8"
      databaseName: "temporal"
      connectAddr: "my-db.us-west-2.rds.amazonaws.com:3306"
      cloudAuth:
        provider: "aws"
        region: "us-west-2"

For GCP:

persistence:
  default:
    sql:
      pluginName: "postgres12"
      databaseName: "temporal"
      connectAddr: "project:region:instance"
      cloudAuth:
        provider: "gcp"

Proposed scope:

• AWS RDS: IAM authentication with automatic token refresh (15-min lifetime)
• GCP Cloud SQL: IAM authentication with automatic token refresh (1-hour lifetime)
• Azure: Can be added if there's demand (would require new dependency, ~20-30MB)

Why this makes sense:

• github.com/aws/aws-sdk-go and cloud.google.com/go/* are already Temporal dependencies
• No new dependencies required for AWS/GCP support
• Aligns with cloud-native security best practices (zero-trust, workload identity)
• Infrastructure already exists for key rotation
  • see common/persistence/sql/sqlplugin/db_handle.go:49-68
  • MaxConnLifetime forces individual connections to close and reopen (e.g., every 12 minutes for AWS tokens that expire in 15 minutes)
  • When a new connection is created, the auth mechanism runs again
  • The connect callback (which includes the Connect hook) is called each time reconnect() happens

Describe alternatives you've considered

1. Document the Connect hook approach - Requires users to make custom-builds and maintain upstream merges.
2. External credential provider pattern - Adds deployment complexity,
3. Do nothing - Users continue managing secrets manually... Somewhere an SRE cries silent tears.

Additional context

This would eliminate the need for secret management for database credentials when running Temporal in AWS EKS or GCP GKE with workload identity configured.

Commitment and Resources:

This is a business priority for us. We're allocating dedicated engineering resources to implement this feature properly if Temporal confirms alignment. We will do the work and target initial PR(s) within 4-6 weeks.

Temporal already has the necessary connection rotation infrastructure (DatabaseHandle.reconnect()) and the required SDKs. The implementation is straightforward and aligns with cloud-native security best practices adopted across the industry.

[edisonpaul4]

we really need this!

[GabrielAlacchi]

+1, related #8724

[simvlad]

Thanks for opening this issue, great write-up and a detailed proposal. Your analysis is correct about the existing setup, and there shouldn't be any barriers to integrating those SDKs.

I have some time over the next few weeks to work on the implementation, as Temporal is interested in supporting this. In addition to the AWS/GCP work, I'll also include Azure Entra ID integration to support #8724. I also plan to extend the test suite to ensure we have proper coverage for these new auth flows. I'll provide the update at the end of the next week.

[simvlad]

I'll target OSS 1.31 release for this, which is currently planned for the end of April