Assume Role Profiles don't follow the CLI and Boto Convention for Configuration

[jjmartin]

#926 apparently added the ability to have assumeRole items in the aws credentials file

but the set up for this doesn't seem to be documented anywhere and it also doesn't follow what works in CLI and Boto and IS documented here: http://docs.aws.amazon.com/cli/latest/topic/config-vars.html#using-aws-iam-roles

so now if i want to use the cli on my machine and the aws sdk my config file and my credentials file needs

...
[assumeroleprofile]
role_arn = arn:aws:iam::accountnum:role/SuperRole
source_profile = main
...

could we just get the JS sdk to read the ~/.aws/config like both the CLI and Boto do?

[chrisradek]

@jjmartin
Sorry about the lack of documentation. We're working on updating our documentation around credentials so we'll get this worked in too.

We actually do plan on having the JS SDK read the ~/.aws/config file as well. As an aside, while the CLI/boto don't document it yet, they also support reading the assume role profiles config from the credentials file as well.

[jjmartin]

ok well thats good to know so i don't need it in both at least

[jjmartin]

after resetting my system just to use the credentials file - i don't think its the case that the CLI reads the source_profile from the credentials file (just FYI)

nevermind - i had forgotten to set my profile env var

[andreineculau]

Is there any update on this?

We've just burned ourselves because we were authenticated in the shell as "some assumed role on another AWS account", and then ran some nodejs scripts, only to find out that the communication was against the primary AWS account.

[chrisradek]

@andreineculau
How were your credentials set up? Were the assume role configurations set in the config file, with a matching profile in the credentials file?

[andreineculau]

@chrisradek yes

I have duplicate source_profile and role_arn in ~/.aws/credentials and ~/.aws/config. But I cannot see how that can work (the assume role requires MFA).

[andreineculau]

FWIW, this is our current compat-code i.e. if you are logged in via aws-cli assume role, then you're also logged in in aws-sdk-js (same credentials):

import aws from 'aws-sdk';
import ini from 'ini';

// compatibility with aws-cli
let awsProfile = process.env.AWS_PROFILE || process.env.AWS_DEFAULT_PROFILE;
if (awsProfile) {
  try {
    let configIni = ini.parse(fs.readFileSync(
      `${process.env.HOME}/.aws/config`,
      'utf-8'
    ));
    let awsProfileConfig = configIni[`profile ${awsProfile}`];
    if (awsProfileConfig && awsProfileConfig.role_arn) {
      let roleArn = awsProfileConfig.role_arn.replace(/:/g, '_').replace(/[^A-Za-z0-9\-_]/g, '-');
      let awsCliCacheFilename = `${awsProfile}--${roleArn}`;
      let awsCliCache =
          JSON.parse(fs.readFileSync(
            `${process.env.HOME}/.aws/cli/cache/${awsCliCacheFilename}.json`,
            'utf-8'
          ));
      let sts = new aws.STS();
      aws.config.credentials = sts.credentialsFrom(awsCliCache);
    }
  } catch (_err) {
  }
}

Ugly? yes!
But similarly ugly is the fact that AWS cannot get two clients to work together.

[erikerikson]

Also, the SharedIniFilesCredentials docs. Particularly the "Using the shared credentials file" and the callback details under "(void) refresh(callback)" sections.

[Edit: context for "Also" being "with regard to the documentation label"]

[andreineculau]

FWIW my snippet does NOT work with 1.14.10 (known working version is 1.11.190 - that's the version bump in homebrew which I currently use) because aws-cli decided to camouflage the filenames storing the temporary credentials in ~/.aws/cli/cache.
Tail culprit boto/botocore#1322 , followed by a bunch of previous commits.

An updated version of my hack is available at https://gist.github.com/andreineculau/a186c2181a3099a422abc293c8e79fef

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs and link to relevant comments in this thread.