Add new CredentialSource, "ChainSource"

[McDoit]

I would like to see a feature where you can just use a normal CredentialProfile resolution chain as a CredentialSource

Expected Behavior

Instead of having to specify EcsContainer, Ec2InstanceMetadata, Enviroment or a default credential to use as a base for AssumeRole, have a ResolutionChain that uses the normal search path for credentials:

1. The client configuration, or what is explicitly set on the AWS service client.
2. BasicAWSCredentials that are created from the AWSAccessKey and AWSSecretKey AppConfig values, if they’re available.
3. A credentials profile with the name specified by a value in AWSConfigs.AWSProfileName (set explicitly or in AppConfig).
4. The default credentials profile.
5. SessionAWSCredentials that are created from the AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_SESSION_TOKEN environment variables, if they’re all non-empty
6. BasicAWSCredentials that are created from the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables, if they’re both non-empty.
7. IAM Roles for Tasks for Amazon EC2 Container Service (Amazon ECS) tasks.
8. EC2 instance metadata.

Source: https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/net-dg-config-creds.html

Current Behavior

Having to specify EcsContainer, Ec2InstanceMetadata, Enviroment or a default credential to use as a base for AssumeRole, all seperatly

Possible Solution

Implement new CredentialSource ResolutionChain that uses the normal search path for credentials:

1. The client configuration, or what is explicitly set on the AWS service client.
2. BasicAWSCredentials that are created from the AWSAccessKey and AWSSecretKey AppConfig values, if they’re available.
3. A credentials profile with the name specified by a value in AWSConfigs.AWSProfileName (set explicitly or in AppConfig).
4. The default credentials profile.
5. SessionAWSCredentials that are created from the AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_SESSION_TOKEN environment variables, if they’re all non-empty
6. BasicAWSCredentials that are created from the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables, if they’re both non-empty.
7. IAM Roles for Tasks for Amazon EC2 Container Service (Amazon ECS) tasks.
8. EC2 instance metadata.

Context

This would enable us to have one way to assume roles, no matter if using a own account, running on EC2, in lambda or in ECS and then make it easier to port code and development between different environments. Also possible to assume a role when producing the code (no God-role for developers where everything works), and then having the same setup and structure when deploying it

On code startup, we can just programatically make sure that the AWSProfileName exist in the netcredential store (or normal config file), and if not create it there and use this new CredentialSource as the source

[klaytaybai]

You can use Amazon.Runtime.FallbackCredentialsFactory.GetCredentials() to accomplish this

[McDoit]

The idea was something like this:

In the config:

<!--?xml version="1.0" encoding="utf-8" ?-->
<configuration>
    <appsettings>
        <add key="AWSProfileName" value="web-profile">
    </add></appsettings>
</configuration>

At app startup (or similar):

var webProfile = new CredentialProfile("web-profile", new CredentialProfileOptions
{
    CredentialSource = "GetCredentials",
    RoleArn = "role_arn"    
});

var nc = new NetSDKCredentialsFile();

nc.RegisterProfile(webProfile);

In the code: var s3Client = new AmazonS3Client();

So the idea is to retrive credentials, from somewhere, and use those to AssumeRole Without having to setup every role manually on servers, tasks or at dev machines, and then control who can assume what role centrally

[github-actions[bot]]

We have noticed this issue has not received attention in 1 year. We will close this issue for now. If you think this is in error, please feel free to comment and reopen the issue.