Credentials + sts and default aws cli expectations

[softprops]

On the maturity path for organizations using aws there's often a step where engineers move away from using local IAM API key credentials that have a wide range of access towards a model where they leverage temporary assumed role based access for specific actions.

This is common enough that its built directly in aws cli tooling

One point of friction I've run into with introducing rusoto based cli tooling is that it's credential provider supports the most basic case of reading access keys and secret keys from credential files.

I'm interested in removing this friction. I realize that it is possible to provide similar functionality but it seems tool developers need to reimplement that for each tool made.

I'm looking for suggested direction where one would be able to export AWS_PROFILE and be able to assume rusoto tools would pick up on aws credential configs that declare a source profile and role to assume.

Since rusoto sts depends on core and core depends on credential, credential could not easily depend on sts. There is an impl of a credential provider for sts in the sts crate but it doesn't seem to leverage the aws credential file the rest of aws tooling supports.

Is there any interest from others using rusoto within there organizations for praying a more out of the box solution that brings rusoto up to parity with what some aws users expect?

I don't yet know how much of a special case I am.

[iliana]

The request is to add the role_arn/source_profile functionality to ProfileProvider, right? I think that should be possible.

(In terms of organization usage, I've found the role_arn/source_profile functionality to be limited — it doesn't work with credential_process, see https://github.com/boto/botocore/issues/1329#issuecomment-348358369 — so I tend to not use it in favor of using credential_process with some nice scripts everywhere.)

[softprops]

The request is to add the role_arn/source_profile functionality to ProfileProvider, right?

Yep. problem is that the sts functionality lives in a crate that depends on core and core depends on credential. I'm not sure if this core-credential enough to live below core :)

I'll take a look at the botocore link

[iliana]

sts functionality lives in a crate that depends on core and core depends on credential

Oh, right. That's a rough issue.

Maybe we can move the ProvideAwsCredentials trait into a rusoto_credential_core, so that sts can depend on that and credential can depend on sts?

[jahkeup]

It also seems that a profile/config file reading API, usable for other non-built-in callers to use, would be handy. This would help for new (unhandled/unsupported) configuration scenarios like in #1120 where they're having to parse the config files in order to make the desired STS call with their mfa tokens.