aws-sdk-js: Getting 'CredentialsError: Missing credentials in config' when using assume role

version: aws-sdk@2.205.0 OS: macOS Sierra 10.12.6

Issue: I’ve been using access key to run aws cli for a while and today I’m asked to switch to using assume role. setting up is simple (attached) and I’ve verified assumed role working with aws cli. then I switch back to working on my nodejs application, and received an error I haven’t seen before.

Error:

{ [CredentialsError: Missing credentials in config]
  message: 'Missing credentials in config',
  code: 'CredentialsError',
  errno: 'EHOSTUNREACH',
  syscall: 'connect',
  address: '<my_ip>',
  port: <my_port>,
  time: Thu Mar 01 2018 14:50:33 GMT-0800 (PST),
  originalError: 
   { message: 'Could not load credentials from any providers',
     code: 'CredentialsError',
     errno: 'EHOSTUNREACH',
     syscall: 'connect',
     address: '<my_ip>',
     port: <my_port>,
     time: Thu Mar 01 2018 14:50:33 GMT-0800 (PST),
     originalError: 
      { code: 'EHOSTUNREACH',
        errno: 'EHOSTUNREACH',
        syscall: 'connect',
        address: '<my_ip>',
        port: 80,
        message: 'connect EHOSTUNREACH <my_ip> - Local (<my_local_ip>)' } } }

Related issue: #1483

My set up: ~/.aws/config

[profile default]
region = <my_region>
role_arn = <arn_for_assume_role>
source_profile = <my_profile_name>

~/.aws/credentials

[my_profile_name]
aws_access_key_id = <my_access_key>
aws_secret_access_key = <my_secret>

~/.bash_profile

export AWS_SDK_LOAD_CONFIG=1
export AWS_SHARED_CREDENTIALS_FILE=$HOME/.aws/credentials
export AWS_CONFIG_FILE=$HOME/.aws/config

Reading #1483 helped me understanding this issue by a lot but still not enough to get it fixed:

  • I’ve logged process.env at runtime and it does include all env variables I exported from bash_profile
  • I’ve logged aws.config (var aws = require('aws-sdk');):
    • aws.config.credentials is null at runtime
    • aws.config.region is correct

I can get around this issue quickly by change the profile name to default in my ~/.aws/credentials to

[default]
aws_access_key_id = <my_access_key>
aws_secret_access_key = <my_secret>

With that change, I can get this as aws.config.credentials at runtime:

SharedIniFileCredentials {
     expired: false,
     expireTime: null,
     accessKeyId: '<my_access_key>',
     sessionToken: undefined,
     filename: undefined,
     profile: 'default',
     disableAssumeRole: true,
     preferStaticCredentials: false }

I noticed there is an argument for SharedIniFileCredentials called disableAssumeRole and it’s true when i used key access. I’m wondering if you can show me what did I miss here in order to access AWS via node js sdk with assume role at run-time.

Many thanks in advance!

The test code I have:

var aws = require('aws-sdk');

aws.config.update({
  region : '<my_region>'
});

var s3 = new aws.S3();
// Note: the bucket and key used here have been verified by accessing via aws cli, using either assume-role or key access
s3.getObject({
  Bucket : '<my_bucket>',
  Key : '<key_to_my_file>'
}).promise().then(function (s3obj){
  console.log('successful');
}).catch(function (error) {
  console.error(error);
});

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 1
  • Comments: 18 (7 by maintainers)

Most upvoted comments

Just wanted to add here that I recently encountered this Missing credentials in config error, while using aws-sdk. I was sure this was working before, so I tested the aws cli and saved a file into S3 without issue. At that point the only difference was the use of the aws-sdk, so I upgrade and surprise, Missing credentials in config was gone and I was able to save a file in S3 using aws-sdk.

@duxing I think the reason you aren’t able to assume a role using the default credentials is because your roleArn is supplied in the ~/.aws/config file instead of the ~/.aws/credentials file.

If you set the environment variable AWS_SDK_LOAD_CONFIG to a truthy value (like 1), then the SDK will load data from the config file as well. This is currently opt-in because support for the config file was added well after the credentials file, and there was a backwards-incompatibility risk otherwise.

Let me know if this doesn’t solve the issue for you! I admittedly couldn’t find this in our docs so I’m adding a note to update them as well.