You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using AWS, it is possible to use the AWS JDBC Driver for PostgreSQL which significantly simplifies connecting to a database from an application using IAM authentication.
It would be amazing to have something similar within azure, such that I can specify the driver and any parameters within the JDBC connection string to empower database access.
Generally, I connect as the admin within migration scripts to configure additional roles and permissions within the database. Connecting as the additional roles which map to workload-indentities within AKS is slightly painful currently as the application needs to be aware of the PostgreSQL endpoint of Azure such that it can:
create an access token from the given identity-token
refresh the token before it expires (ensures any new connections being opened within the long-running app work)
Having the ability to abstract this logic into a driver feels right, as the application is unaware of the implementation details around authentication to PostgreSQL besides a driver.
The text was updated successfully, but these errors were encountered:
When using AWS, it is possible to use the AWS JDBC Driver for PostgreSQL which significantly simplifies connecting to a database from an application using IAM authentication.
It would be amazing to have something similar within azure, such that I can specify the driver and any parameters within the JDBC connection string to empower database access.
Generally, I connect as the admin within migration scripts to configure additional roles and permissions within the database. Connecting as the additional roles which map to workload-indentities within AKS is slightly painful currently as the application needs to be aware of the PostgreSQL endpoint of Azure such that it can:
Having the ability to abstract this logic into a driver feels right, as the application is unaware of the implementation details around authentication to PostgreSQL besides a driver.
The text was updated successfully, but these errors were encountered: