AWSSDK.Extensions.NETCore.Setup support for RDSAuthTokenGenerator

[chrischappell-rgare]

Describe the feature

RDSAuthTokenGenerator has static GenerateAuthToken and GenerateAuthTokenAsync methods to generate an auth token for RDS. It cannot have the credentials resolved by the NETCore.Setup package because there is no AWS service client instance constructed. AWSCredentials can be passed to a GenerateAuthToken overload or FallbackCredentialsFactory is used. Either way currently requires separate configuration than what is provided by NETCore.Setup.

NETCore.Setup does not provide a way of directly getting the configured AWSCredentials either. It would be beneficial to be able to get an AWSCredentials instance from AWSOptions so that only one configuration method needs to be implemented for an application.

Use Case

Use AWSSDK.Extensions.NETCore.Setup to configure AWS credentials for RDSAuthTokenGenerator.

Proposed Solution

ConfigurationExtensions.GetAWSOptions can currently be used to get an instance of AWSOptions that has the Profile and Region populated according to the configuration. There is a Credentials property on AWSOptions but it is null on the returned instance. If the AWSOptions could provide the resolved AWSCredentials instance it could be passed to RDSAuthTokenGenerator.

A new method or property could be added to AWSOptions to get the AWSCredentials or the Credentials getter could create the AWSCredentials when not set externally.

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

AWS .NET SDK and/or Package version used

AWSSDK.Extensions.NETCore.Setup 3.7.300
AWSSDK.RDS 3.7.309.5

Targeted .NET Platform

.Net 8

Operating System and version

Windows 10

[ashishdhingra]

@chrischappell-rgare Looks like you are looking forward to use the same set of AWS credentials that are resolved by AWSSDK.Extensions.NETCore.Setup package while creating service clients. Per code comment for AWSOptions.Credentials property, it specifies AWS Credentials used for creating service clients. If this is set it overrides the Profile property.. Service client is created here and credentials are resolved here. If you refer the logic, while creating service client, it uses the supplied credentials (if any) or else relies on credential profile chain or FallbackCredentialsFactory, while creating service clients. So AWSOptions.Credentials is for supplying credentials, not populating it with credentials that were resolved while creating service clients.

RDSAuthTokenGenerator is just a customer utility method provided in AWSSDK.RDS package and cannot be used as such during DI setup while using AWSSDK.Extensions.NETCore.Setup package.

As a workaround, you may register IAmazonSecurityTokenService dependency (refer https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/net-dg-config-netcore.html#net-core-dependency-injection), and use AssumeRoleAsync() to assume a role which has required permissions for RDS. You may then access short-term temporary credentials using AssumeRoleResponse.Credentials property. Kindly test if these work with RDSAuthTokenGenerator.

Needs review with the team for any workaround. But the requested functionality is outside the design of AWSSDK.Extensions.NETCore.Setup package.

[ashishdhingra]

Reviewed this with team. This is a feature request to expose credentials resolved by AWSSDK.Extensions.NETCore.Setup package.

[jkuek]

I have run into the same issue.

My ASP.NET Core application normally runs on EC2, but I run it locally for debugging purposes.

I have specified the profile in appsettings.json:

  "AWS": {
    "Profile": "AdministratorAccess-Preprod",
    "Region":  "ap-southeast-2"
  },

This works for all my other AWS SDK use(e.g. RDS, SQS, SNS), but not for the call to get a token for RDS IAM auth:

var password = RDSAuthTokenGenerator.GenerateAuthToken(hostname, (int)port, username);

Currently, I have to explicitly set the AWS credentials in environment variables or through appsettings.json to work around the issue. It would be preferable if RDSAuthTokenGenerator could load the application default credentials as the other services do.

[chase-miller]

@ashishdhingra I believe that #3715 would close this issue.

[chrischappell-rgare]

It looks like that solution would work for this, although it wasn't as obvious as a method on AWSOptions would be. The credentials may need to be accessed at app startup before dependency injection is possible.

Injected credentials would work if getting a new RDS token for each connection. If the Npgsql PeriodPasswordProvider is used to cache and rotate the token then the credentials need to be accessible without injection. It would look something like this:

var options = builder.Configuration.GetAWSOptions();
var credentials = new DefaultAWSCredentialsFactory(options).Create();
builder.Services.AddNpgsqlDataSource(builder.Configuration.GetConnectionString("db"), builder =>
{
	builder.UsePeriodicPasswordProvider((connectionString, token) => ValueTask.FromResult(
		RDSAuthTokenGenerator.GenerateAuthToken(
			credentials, connectionString.Host, connectionString.Port, connectionString.Username)), 
		TimeSpan.FromMinutes(12), 
		TimeSpan.FromSeconds(5));
});

[chase-miller]

It looks like that solution would work for this, although it wasn't as obvious as a method on AWSOptions would be. The credentials may need to be accessed at app startup before dependency injection is possible.

How might AWSOptions be extended?

Injected credentials would work if getting a new RDS token for each connection. If the Npgsql PeriodPasswordProvider is used to cache and rotate the token then the credentials need to be accessible without injection. It would look something like this:

var options = builder.Configuration.GetAWSOptions();
var credentials = new DefaultAWSCredentialsFactory(options).Create();
builder.Services.AddNpgsqlDataSource(builder.Configuration.GetConnectionString("db"), builder =>
{
	builder.UsePeriodicPasswordProvider((connectionString, token) => ValueTask.FromResult(
		RDSAuthTokenGenerator.GenerateAuthToken(
			credentials, connectionString.Host, connectionString.Port, connectionString.Username)), 
		TimeSpan.FromMinutes(12), 
		TimeSpan.FromSeconds(5));
});

Another option might be to use the AddNpgsqlDataSource overload that takes an IServiceProvider like the following:

builder.Services
   .AddDefaultAWSOptions(sp => sp.GetRequiredService<IConfiguration>().GetAWSOptions())
   .AddCredentialsFactory();

builder.Services.AddNpgsqlDataSource(builder.Configuration.GetConnectionString("db"), (sp, builder) =>
{
	var credentials = sp.GetRequiredService<IAWSCredentialsFactory>().Create();
	builder.UsePeriodicPasswordProvider((connectionString, token) => ValueTask.FromResult(
		RDSAuthTokenGenerator.GenerateAuthToken(
			credentials, connectionString.Host, connectionString.Port, connectionString.Username)), 
		TimeSpan.FromMinutes(12), 
		TimeSpan.FromSeconds(5));
});

[chrischappell-rgare]

Another option might be to use the AddNpgsqlDataSource overload that takes an IServiceProvider like the following:

builder.Services
.AddDefaultAWSOptions(sp => sp.GetRequiredService().GetAWSOptions())
.AddCredentialsFactory();

builder.Services.AddNpgsqlDataSource(builder.Configuration.GetConnectionString("db"), (sp, builder) =>
{
var credentials = sp.GetRequiredService().Create();
builder.UsePeriodicPasswordProvider((connectionString, token) => ValueTask.FromResult(
RDSAuthTokenGenerator.GenerateAuthToken(
credentials, connectionString.Host, connectionString.Port, connectionString.Username)),
TimeSpan.FromMinutes(12),
TimeSpan.FromSeconds(5));
});

That AddNpgsqlDataSource overload with an IServiceProvider is actually brand new. It wasn't available when I last looked at this. That does provide the dependency injection hook needed to integrate with IAWSCredentialsFactory, but the point remains for situations where dependency injection is not available.

How might AWSOptions be extended?

A public method on AWSOptions to create the credentials would be intuitive. Similar to CreateServiceClient. It does seem to be a bit redundant in having IAWSCredentialsFactory and the Credentials property on AWSOptions. The Credentials property was the way to provide a custom subclass or configuration of AWSCredentials and it integrated well with dependency injection by following up with CreateServiceClient. That would still be an option for custom credentials without creating a custom implementation of IAWSCredentialsFactory.