Red Hat maps a passwordless path from OpenShift workloads to PostgreSQL

Red Hat has published a detailed implementation path for replacing long-lived application-to-database credentials with SPIFFE workload identities on OpenShift. The guide uses PostgreSQL as the first migration boundary and compares two authentication patterns: mutual TLS with short-lived X.509 credentials, and TLS with a federated JWT/OIDC token.

This is not a new product launch. It is a useful deployment blueprint for platform teams that already know Kubernetes Secrets are a poor long-term home for database passwords but cannot convert every service to workload identity at once.

What the pattern changes

In Red Hat’s walkthrough, the OpenShift zero trust workload identity manager supplies a running workload with a SPIFFE Verifiable Identity Document, or SVID. PostgreSQL keeps its existing roles and grants; SPIFFE and SPIRE establish who the caller is, while the database still decides what that identity may do.

That separation is central. Workload identity replaces the static credential used for authentication, but it does not replace authorization policy. Platform teams still need an explicit mapping from a SPIFFE identity to a database user or role.

Two routes to PostgreSQL

The first route uses mutual TLS. The application obtains a short-lived X.509 SVID from SPIRE and presents it as a client certificate. PostgreSQL trusts the SPIRE certificate authority, while the application validates the database server certificate. Red Hat positions this as the simpler choice where database certificate authentication is already accepted.

The second route uses a JWT SVID as the upstream workload identity. The application exchanges that assertion through an identity provider such as Microsoft Entra ID for an OAuth access token that PostgreSQL can validate. This adds an identity-provider dependency but fits organizations that require workload access to pass through the same corporate identity control plane used elsewhere.

Red Hat links runnable examples for both approaches and also points to SPIFFE Helper for applications that cannot call the SPIFFE Workload API directly.

Where to start

The guide recommends progressive adoption rather than a cluster-wide cutover. An application-to-database connection is a practical first pilot because the client can adopt SPIFFE while an existing database continues to use certificate or token authentication.

Teams evaluating the pattern should verify four things before rollout: how SPIFFE IDs map to database roles, whether applications tolerate short credential lifetimes and rotation, how OpenShift and SPIRE certificate authorities are distributed, and whether connection logs preserve a useful workload identity. The payoff is concrete only if the deployment removes a long-lived secret without weakening the authorization and audit controls behind it.