Closed jbak31 closed 1 month ago
The latest updates on your projects. Learn more about Vercel for Git ↗︎
So I like what you are trying to achieve here, but I'd like to see it be WAAAAAAAY more generic. Why should this only support AWS, what about Google, what about Azure, and really what if I'm using Vault or some other identity rotation service to rotate / generate my credentials.
I'm going to assume that MT plays quite well with Microsoft.Extensions.Options, if not maybe that's the work to do. Then you can source your credentials from a custom RDS token source that feeds into Microsoft.Extensions.Options.
So I like what you are trying to achieve here, but I'd like to see it be WAAAAAAAY more generic. Why should this only support AWS, what about Google, what about Azure, and really what if I'm using Vault or some other identity rotation service to rotate / generate my credentials.
I'm going to assume that MT plays quite well with Microsoft.Extensions.Options, if not maybe that's the work to do. Then you can source your credentials from a custom RDS token source that feeds into Microsoft.Extensions.Options.
@phatboyg / @drusellers fair enough - I would be keen to make this a generic implementation so that the token generation part can be injected by the consumers themselves.
@phatboyg / @drusellers
Currently for SQL Transport only a static password is allowed.
However, for connecting with Amazon RDS, or Aurora or TimeScale Db or any other modern database, we would want to generate an access token rather than using the plain text password. This PR adds this feature.
This currently only supports AWS RDS token generation, however additional token generators around this can be easily extended.
Additional fields added to the
SqlTransportOptions
AuthenticationMode
defaults to Password, but can also be set toAccessToken
TokenIssuerOptions
which sends in the options specific to the Access Token generator being used.