Support Azure Entra ID Authentication for PostgreSQL Backend

[GabrielAlacchi]

Is your feature request related to a problem? Please describe. When self-hosting temporal on Azure, it is generally preferred to use managed identity or service principal authentication based on Entra ID to authenticate with PGSQL to reduce the need for managing secrets. https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/security-entra-concepts

The mechanism in question simply substitutes the password in the PGSQL connection with a JWT.

A team in my organization is currently maintaining a set of patches that adds this support to temporal-server and temporal-sql-tool binaries. I'm wondering if there's any approach, we can take to upstream this into Temporal open-source release.

The internal patches we maintain do the following:

1. Add azure-identity SDK and add a config flag to temporal to enable its usage to fetch a token in the Postgresql temporal plugin code.
2. Add some error handling logic to force a re-connection whenever a query fails due to token expiry. This feels hacky to me, because temporal already seems to have a max-connection lifetime capability which can be tuned dynamically to the expiry of the token.

Describe the solution you'd like Bringing in our internal patches is a non-starter since it involves bringing in azidentity SDK components into temporal's build which will not be used outside of our niche use-case.

Other cloud providers also have similar token based auth schemes for PGSQL that involve managing the lifecycle of a time-bound token.

• https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html
• https://docs.cloud.google.com/sql/docs/postgres/iam-authentication#auto-vs-manual

I would propose a more generic plugin-based approach can be taken here to make it possible to use any cloud provider that follows a similar JWT auth pattern. I'm open to suggestions on the specific details on how that would work. Two ideas I have:

1. Use some plugin binary that can be invoked (either CLI or GO plugin https://pkg.go.dev/plugin) to get a token + expiry when creating a new connection. Cloud-specific connector plugins can likely be built separately from some separate contrib folder / separate repositories and brought in optionally by consumers in the container build.
2. Temporal can be configured to grab token + expiry from a file; can support for this be added to dynamic config?

Describe alternatives you've considered

• Password auth: Not ideal for our organization's security & compliance concerns.
• Custom fork: We are basically doing this now and can continue if strictly necessary. However, since other big 3 cloud providers support similar token-based auth schemes for PostgreSQL, we may widen the audience that is interested in this feature enough to build a mainline solution.

Additional context Happy to bring some cycles to contribute PRs to make this happen if we can align on a suitable approach. Our interest in contributing is limited to the Azure use-case, but we can lay the foundation for supporting other clouds in the process.

[GabrielAlacchi]

This might apply to MySQL as well on the big 3 clouds / other clouds.