Rusoto: Rusoto automatic providers do not apply source_profile or role_arn

[clee]

Other AWS CLI tools (including the official python awscli) automatically switch to the role defined by the role_arn in the ~/.aws/credentials file. Rusoto should automatically do this when using either rusoto_credential::ChainProvider or rusoto_credential::ProfileProvider.

For example, my ~/.aws/credentials file contains:

[default]
aws_access_key_id = AKIAEXAMPLEACCESSKEY
aws_secret_access_key = Secret/Access/Key

[sandbox]
role_arn = arn:aws:iam::123456789012:role/some-role
source_profile = default

When I export AWS_PROFILE=sandbox, commands like aws s3 ls and all the rest work as expected, showing me the contents from the sandbox role's view of things.

This does not work with any Rusoto providers. I had to copy the aws_access_key_id and aws_secret_access_key definitions into the sandbox profile definition for anything to work, and even then, the role_arn wasn't applied so I had to figure out how to use an StsAssumeRoleSessionCredentialsProvider.

It would be really nice if the default ChainProvider sorted this out for me, or even the ProfileProvider because what's the point of loading the profile if we don't load it correctly?

[iliana]

This is more difficult than it would seem at first because the STS API calls necessary are in rusoto_sts, which ultimately depend on rusoto_credential, and we can't have a circular dependency. This is why there are some credential providers in rusoto_sts, but none of them read from the profile (yet).

[clee]

Maybe this could be resolved by splitting rusoto_credential into, say, rusoto_credential_base (which crates like rusoto_sts could depend on), and a new higher-level rusoto_credential?

Ah, I see that you already had this idea! Neat.

[jahkeup]

source_profile and role_arn support was also requested over in #1559

It seems like there's a fair amount of type reorganizing (besides STS & config inheritance/chaining implementation) in order to add full support for these parameters.

[tomykaira]

I usually use AWS Java SDK and Go SDK, and I faced this problem while trying rusoto.
Because AssumeRole with AWS_PROFILE is a common practice in multi AWS accounts and AWS organization setup, this feature is wanted in the library, not in user code.

I quite agree with idea to make higher level credentials crate. I am not sure, but AWS Java SDK also looks like to have low-level credentials provider layer and high-level layer for ~/.config and ~/.credentials, and sts module is not included in core, but required to use profiles with role_arn.

I implemented basic handling of this case.
I am quite new to Rust, so the code must be awkward, but I am happy if it helps you.
https://gist.github.com/tomykaira/9b4b39b91dc750dfd2c7521eac7c4c59

[zeapo]

This is more difficult than it would seem at first because the STS API calls necessary are in rusoto_sts, which ultimately depend on rusoto_credential, and we can't have a circular dependency. This is why there are some credential providers in rusoto_sts, but none of them read from the profile (yet).

@iliana I started working on a solution where parsing the profile checks for all potential keys defined by the credentials' spec and exposes it into a hash. Then an StsProfileCredentialsProvider would take a ProfileProvider and does the job in assuming the profile requested in the latter.

User friendliness wise, we can't automatically guess if the rusoto_sts crate was added (as far as my rust knowledge goes). Therefore we can't mimic other SDKs (such as Java that uses Sts if the jar is in the classpath). Therefore, the user will have to manually rely on the StsProfileCredentialsProvider. Which ofc will default to ProfileCredentialsProvider if the selected profile is indeed a simple credentials profile and does not need to assume a role.

I'll open a PR this weekend or next week when it's finished