Running rspec over dynomite model with local dynamodb instance results in MissingCredentialsError

genail · January 6, 2019, 5:27pm

Hi,
First of all great work! I’m looking forward to building my first application on Jets!

I’m trying to set up my Jets app with a local dynamodb instance (https://github.com/tongueroo/jets/wiki/Dynamodb-Local-Setup-Walkthrough) and model rspec tests. Running rspec results in the following error:

  1) App creates app
     Failure/Error: app.replace
     
     Aws::Errors::MissingCredentialsError:
       unable to sign request without credentials set
     # /var/lib/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/plugins/signature_v4.rb:72:in `sign_request'
     # /var/lib/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/plugins/signature_v4.rb:112:in `apply_signature'
     # /var/lib/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/plugins/signature_v4.rb:65:in `call'
     # /var/lib/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/plugins/helpful_socket_errors.rb:10:in `call'
     # /var/lib/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/plugins/retry_errors.rb:171:in `call'
     # /var/lib/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/json/handler.rb:11:in `call'
     # /var/lib/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/plugins/user_agent.rb:13:in `call'
     # /var/lib/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/seahorse/client/plugins/endpoint.rb:45:in `call'
     # /var/lib/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/plugins/param_validator.rb:24:in `call'
     # /var/lib/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/seahorse/client/plugins/raise_response_errors.rb:14:in `call'
     # /var/lib/gems/2.5.0/gems/aws-sdk-dynamodb-1.19.0/lib/aws-sdk-dynamodb/plugins/simple_attributes.rb:117:in `call'
     # /var/lib/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/plugins/jsonvalue_converter.rb:20:in `call'
     # /var/lib/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/plugins/idempotency_token.rb:17:in `call'
     # /var/lib/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/plugins/param_converter.rb:24:in `call'
     # /var/lib/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/plugins/response_paging.rb:10:in `call'
     # /var/lib/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/seahorse/client/plugins/response_target.rb:23:in `call'
     # /var/lib/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/seahorse/client/request.rb:70:in `send_request'
     # /var/lib/gems/2.5.0/gems/aws-sdk-dynamodb-1.19.0/lib/aws-sdk-dynamodb/client.rb:3163:in `put_item'
     # /var/lib/gems/2.5.0/gems/jets-1.4.8/vendor/dynomite/lib/dynomite/item.rb:209:in `replace'
     # /var/lib/gems/2.5.0/gems/jets-1.4.8/vendor/dynomite/lib/dynomite/item.rb:70:in `replace'
     # ./spec/models/app_spec.rb:4:in `block (2 levels) in <top (required)>'

Everything seems to be working fine in development environment though - I can access the local dynamodb instance from a controller using a web browser without any issues.

I am doing something wrong? Is running tests using rspec is the correct way of doing it?

Edit

Here’s the code:

require 'spec_helper'

describe App, type: :model do
  it "creates app" do
    app = App.new
    app.replace
  end
end

Edit 2
models/app.rb code:

class App < ApplicationItem
end

tung · January 6, 2019, 7:10pm

@genail Thanks for the kind words.

Haven’t look at dynamodb and dynomite in a while. Just debugged it. It’s a little rough around the edges.

Recommend creating a dynamodb-local IAM user. The tools like https://github.com/aaronshaf/dynamodb-admin assume you have AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY setup. Looks like Jets is calling out to get the AWS account id in some cases too. For the IAM User permission give it nothing, it doesn’t need any actual IAM permissions. Know it’s a little silly to create an IAM user for this, but dynamodb-local creates a DB on your filesystem that includes the AWS_ACCESS_KEY_ID in the DB name. It looks something like this.

$ ls /usr/local/Caskroom/dynamodb-local/latest/*.db
/usr/local/Caskroom/dynamodb-local/latest/your-aws-secret-access-key_us-west-2.db
$

Make sure as you are creating the dynamodb tables both in JETS_ENV=development and JETS_ENV=test that it’s writing to the same your-aws-secret-access-key_us-west-2.db file.

I created an example repo to help answer this: https://github.com/tongueroo/jets-dynamodb-example

Here’s how I tested:

Checked that config/dynamodb.yml is pointed to http://localhost:8000 for both dev and test

Test development with jets console.

$ jets c
Jets booting up in development mode!
>> post = Post.new(title: "test title")
=> #<Post:0x000056129f5859f0 @attrs={:title=>"test title"}>
>> post.replace
=> {"id"=>"f564b8f82192556e13357bc226bd97238288bebf", :title=>"test title", "created_at"=>"2019-01-06T18:53:13Z", "updated_at"=>"2019-01-06T18:53:13Z"}
>> Post.scan.count
I, [2019-01-06T18:53:18.727636 #17317]  INFO -- : It's recommended to not use scan for production. It can be slow and expensive. You can a LSI or GSI and query the index instead.
I, [2019-01-06T18:53:18.727694 #17317]  INFO -- : Scanning table: demo-dev-posts
=> 3
>>

Then I checked that the .db file was created in the right space on the filesystem: /usr/local/Caskroom/dynamodb-local/latest/your-aws-secret-access-key_us-west-2.db Also used dynamodb-admin to check if the table exists:

dynamodb-admin-check-dev

Then did the same thing for testing. First migrate the test DB.

  $ JETS_ENV=test jets dynamodb:migrate ./dynamodb/migrate/20190106175741-create_posts_migration.rb
  Running database migrations
  DynamoDB Table: posts Status: ACTIVE
  $

Remember to check the /usr/local/Caskroom/dynamodb-local/latest/ folder the *.db file again. And dynamodb-admin again

dynamodb-admin-check-test

Then I was able to run the test, but not without a workaround. It looks like need to set the AWS_REGION. Will dig into fixing this in time.

  $ AWS_REGION=us-west-2 rspec
  Post
    loads attributes

  Finished in 0.06104 seconds (files took 4.69 seconds to load)
  1 example, 0 failures

  $

The spec is here: models/post_spec.rb

Hope that helps!

PS. Would love for someone to help maintain dynomite. Also, as a part of this released a new version of dynomite and jets. Currently, jets is vendorizing dynomite but would like to remove the vendoring of it in time.

genail · January 9, 2019, 1:11pm

@tung Thanks for the explanation! Sorry for the delay but just today I’ve found the time to work on it.

I examined everything as you said. It gave me a better understanding of how everything works. I managed to fixed my issue differently in the end, and I do not fully understand how actually I did that. To the point:

The solution is to copy ~/.aws/credentials to spec/fixtures/home/.aws/credentials and ~/aws/config to spec/fixtures/home/.aws/config.

I’ve found out about it because I ran strace over rspec process. Noticed these two entries near the end:

13:57:11.135769 stat("spec/fixtures/home/.aws/credentials", 0x7fff9003c680) = -1 ENOENT (No such file or directory)
13:57:11.135827 stat("spec/fixtures/home/.aws/config", 0x7fff9003c6f0) = -1 ENOENT (No such file or directory)

I believe this is not the cleanest solution to this problem and what I did is a pretty bad hack. Do you have an idea why its looking for aws credentials there instead of my HOME?

tung · January 9, 2019, 1:50pm

RE: Do you have an idea why it’s looking for aws credentials there instead of my HOME?

I do actually. The generated starter spec_helper.rb sets up the HOME env so that it points to a different folder to supposedly help us avoid accidentally calling the AWS API. Here’s the template source code itself.

github.com

tongueroo/jets/blob/master/lib/jets/commands/templates/skeleton/spec/spec_helper.rb.tt#L3-L4


# Ensures aws api never called. Fixture home folder does not contain ~/.aws/credentails
ENV['HOME'] = "spec/fixtures/home"

This pretty much says that the spec is calling out to the real AWS DynamoDB API instead of the dynamodb-local. Maybe that’s what you want; maybe not?

Real DynamoDB costs money. That’s one of the reasons it usually preferred to run specs over dynamodb-local. Generally, I try to run specs on local databases. For example, specs hit a local MySQL database, not a real RDS database.

Unsure exactly why the spec is calling out to the real DynamoDB, which results in you setting up a spec/fixtures/home/.aws/credentials Perhaps some the source code might help.

genail · January 9, 2019, 2:08pm

I do actually. The generated starter spec_helper.rb sets up the HOME env so that it points to a different folder to supposedly help us avoid accidentally calling the AWS API.

Oh, that explains it!

This pretty much says that the spec is calling out to the real AWS DynamoDB API instead of the dynamodb-local. Maybe that’s what you want; maybe not?

Well, that’s a pretty bad idea. I don’t see any changes on my AWS account so I assume it only uses my real AWS credentials to authenticate. When I browse dynamodb-admin on my local dynamodb instance I see that my test case has created a valid record so we’re good there.

Unsure exactly why the spec is calling out to the real DynamoDB, which results in you setting up a spec/fixtures/home/.aws/credentials Perhaps some the source code might help.

Is there anything I can do to help?

I have a suspicion that my development environment is also authenticating with AWS before letting me in. When I changed my aws_secret_access_key, it did not let me into development console jets c

Aws::STS::Errors::SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.
  /var/lib/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/seahorse/client/plugins/raise_response_errors.rb:15:in `call'
  /var/lib/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/plugins/jsonvalue_converter.rb:20:in `call'
  /var/lib/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/plugins/idempotency_token.rb:17:in `call'
  /var/lib/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/plugins/param_converter.rb:24:in `call'
  /var/lib/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/plugins/response_paging.rb:10:in `call'
  /var/lib/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/seahorse/client/plugins/response_target.rb:23:in `call'
  /var/lib/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/seahorse/client/request.rb:70:in `send_request'
  /var/lib/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-sts/client.rb:1169:in `get_caller_identity'
  /var/lib/gems/2.5.0/gems/jets-1.4.8/lib/jets/aws_info.rb:55:in `account'
  /var/lib/gems/2.5.0/gems/memoist-0.16.0/lib/memoist.rb:170:in `account'
  /var/lib/gems/2.5.0/gems/jets-1.4.8/lib/jets/application.rb:226:in `default_iam_policy'
  /var/lib/gems/2.5.0/gems/jets-1.4.8/lib/jets/application.rb:217:in `set_iam_policy'
  /var/lib/gems/2.5.0/gems/jets-1.4.8/lib/jets/application.rb:112:in `load_app_config'
  /var/lib/gems/2.5.0/gems/jets-1.4.8/lib/jets/application.rb:137:in `load_configs'
  /var/lib/gems/2.5.0/gems/jets-1.4.8/lib/jets/application.rb:15:in `setup!'
  /var/lib/gems/2.5.0/gems/jets-1.4.8/lib/jets/booter.rb:12:in `boot!'
  /var/lib/gems/2.5.0/gems/jets-1.4.8/lib/jets/core.rb:18:in `boot'
  /var/lib/gems/2.5.0/gems/jets-1.4.8/lib/jets/cli.rb:48:in `boot_jets'
  /var/lib/gems/2.5.0/gems/jets-1.4.8/lib/jets/cli.rb:20:in `start'
  /var/lib/gems/2.5.0/gems/jets-1.4.8/lib/jets/cli.rb:5:in `start'
  /var/lib/gems/2.5.0/gems/jets-1.4.8/exe/jets:14:in `<top (required)>'
  /usr/local/bin/jets:23:in `load'
  /usr/local/bin/jets:23:in `<top (required)>'

tung · January 9, 2019, 2:42pm

RE: I have a suspicion that my development environment is also authenticating with AWS before letting me in. When I changed my aws_secret_access_key, it did not let me into development console jets c

Yup, Jets grabs the AWS account id early on during boot process to set up things like a default application IAM policy. Wondering why for you it bombs like so though. Thought that https://github.com/tongueroo/jets/pull/61/files from the kind contribution from onnimonni fixed this.

Just tested it myself and it works as expected on my machine.

$ jets c
You can also get rid of this message by setting AWS_REGION or configuring ~/.aws/config with the region
INFO: You're missing AWS credentials. Only local services are currently available
Jets booting up in development mode!
>>

So there might be something specific to your machine here. Looks like you’re running a recent version of Jets. Even checked my aws-sdk-core-3.44.2 version and it matches with yours. Unsure right now

tung · January 9, 2019, 3:22pm

I see, using the example dynamodb project https://github.com/tongueroo/jets-dynamodb-example and completely unsetting all credentials I am able to reproduce the error.

$ jets c
You can also get rid of this message by setting AWS_REGION or configuring ~/.aws/config with the region
INFO: You're missing AWS credentials. Only local services are currently available
Jets booting up in development mode!
>> post = Post.new(title: "my title", desc: "my desc")
=> #<Post:0x000055584cace848 @attrs={:title=>"my title", :desc=>"my desc"}>
>> post.replace
Traceback (most recent call last):
       16: from /home/ec2-user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/seahorse/client/plugins/response_target.rb:23:in `call'
       15: from /home/ec2-user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/plugins/response_paging.rb:10:in `call'
       14: from /home/ec2-user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/plugins/param_converter.rb:24:in `call'
       13: from /home/ec2-user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/plugins/idempotency_token.rb:17:in `call'
       12: from /home/ec2-user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/plugins/jsonvalue_converter.rb:20:in `call'
       11: from /home/ec2-user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/aws-sdk-dynamodb-1.19.0/lib/aws-sdk-dynamodb/plugins/simple_attributes.rb:117:in `call'
       10: from /home/ec2-user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/seahorse/client/plugins/raise_response_errors.rb:14:in `call'
        9: from /home/ec2-user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/plugins/param_validator.rb:24:in `call'
        8: from /home/ec2-user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/seahorse/client/plugins/endpoint.rb:45:in `call'
        7: from /home/ec2-user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/plugins/user_agent.rb:13:in `call'
        6: from /home/ec2-user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/json/handler.rb:11:in `call'
        5: from /home/ec2-user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/plugins/retry_errors.rb:171:in `call'
        4: from /home/ec2-user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/plugins/helpful_socket_errors.rb:10:in `call'
        3: from /home/ec2-user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/plugins/signature_v4.rb:65:in `call'
        2: from /home/ec2-user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/plugins/signature_v4.rb:112:in `apply_signature'
        1: from /home/ec2-user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/plugins/signature_v4.rb:72:in `sign_request'
Aws::Errors::MissingCredentialsError (unable to sign request without credentials set)
>>

Think that the jets bootup process grabbing the AWS account id was probably a red herring

Think this is earlier finding was related though.

The tools like https://github.com/aaronshaf/dynamodb-admin assume you have AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY setup.

Wow, so it looks like it’s not just the tools that assume you have AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY setup, but the aws-sdk-dynamodb itself when using dynamodb-local? Guess this is why when I created a dynamodb-local IAM user with no permissions and set it up that way it worked. Then while I was doing all the debugging, I exported at AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY and ran the migrations and test and it worked but only because I had those set.

$ JETS_ENV=test jets dynamodb:migrate dynamodb/migrate/20190106175741-create_posts_migration.rb
Running database migrations
Calling create_table with params:
{:table_name=>"demo-test-posts",
 :key_schema=>[{:attribute_name=>"id", :key_type=>"HASH"}],
 :attribute_definitions=>[{:attribute_name=>"id", :attribute_type=>"S"}],
 :provisioned_throughput=>{:read_capacity_units=>5, :write_capacity_units=>5}}
DynamoDB Table: posts Status: ACTIVE
$ AWS_REGION=us-west-2 bundle exec rspec

Post
  loads attributes

Finished in 0.02702 seconds (files took 1.23 seconds to load)
1 example, 0 failures

$

When I unset the AWS_ACCESS_KEY_ID again, then we’re back to the darn Aws::Errors::MissingCredentialsError error.

This is totally a workaround, but cannot think of a better way the moment.

Create a dynamodb-local IAM user with no permissions and using that to run tests.
In your ~/.bash_profile or ~/.profile set

export DYNAMODB_TEST_AWS_SECRET_ACCESS_KEY=actual-secret-access-key-of-dynamodb-local-iam-user-but-has-no-permissions
export DYNAMODB_TEST_AWS_ACCESS_KEY_ID=actual-access-key-id-of-dynamodb-local-iam-user-but-has-no-permissions

Then in your spec_helper do something like this:

github.com

tongueroo/jets-dynamodb-example/blob/1214d84af4f31e5ad9c45ece98e965c59c2dfb79/spec/spec_helper.rb#L6-L14


# Work around dynamodb-local assumption that AWS_ACCESS_KEY_ID is set
# https://community.rubyonjets.com/t/running-rspec-over-dynomite-model-with-local-dynamodb-instance-results-in-missingcredentialserror/31/5
if ENV['DYNAMODB_TEST_AWS_SECRET_ACCESS_KEY']
ENV['AWS_SECRET_ACCESS_KEY'] = ENV['DYNAMODB_TEST_AWS_SECRET_ACCESS_KEY']
end
if ENV['DYNAMODB_TEST_AWS_ACCESS_KEY_ID']
ENV['AWS_ACCESS_KEY_ID'] = ENV['DYNAMODB_TEST_AWS_ACCESS_KEY_ID']
end
ENV['AWS_REGION'] ||= 'us-west-2'

In this way, you can still have your normal AWS cli commands work in the terminal, and only the spec uses this dynamodb-local IAM credentials testing.

Know this is a workaround. Hoping there’s a better solution out there here, and am interested if you find one.

tung · January 9, 2019, 3:28pm

Thought of a possibly better approach. Think that maybe we should stub out the call

/var/lib/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-sts/client.rb:1169:in `get_caller_identity'

That way it won’t hit the API at all for specs. That’s a much better approach.

tung · January 9, 2019, 3:37pm

Nope, it looks like aws-sdk validates the parameters even earlier before the signing process:

$ jets c
You can also get rid of this message by setting AWS_REGION or configuring ~/.aws/config with the region
INFO: You're missing AWS credentials. Only local services are currently available
Jets booting up in development mode!
>> post = Post.new(title: "my title", desc: "my desc")
=> #<Post:0x000055c2312240b8 @attrs={:title=>"my title", :desc=>"my desc"}>
>> post.replace
Traceback (most recent call last):
       16: from /home/ec2-user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/seahorse/client/plugins/response_target.rb:23:in `call'
       15: from /home/ec2-user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/plugins/response_paging.rb:10:in `call'
       14: from /home/ec2-user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/plugins/param_converter.rb:24:in `call'
       13: from /home/ec2-user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/plugins/idempotency_token.rb:17:in `call'
       12: from /home/ec2-user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/plugins/jsonvalue_converter.rb:20:in `call'
       11: from /home/ec2-user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/aws-sdk-dynamodb-1.19.0/lib/aws-sdk-dynamodb/plugins/simple_attributes.rb:117:in `call'
       10: from /home/ec2-user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/seahorse/client/plugins/raise_response_errors.rb:14:in `call'
        9: from /home/ec2-user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/plugins/param_validator.rb:24:in `call'
        8: from /home/ec2-user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/seahorse/client/plugins/endpoint.rb:45:in `call'
        7: from /home/ec2-user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/plugins/user_agent.rb:13:in `call'
        6: from /home/ec2-user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/json/handler.rb:11:in `call'
        5: from /home/ec2-user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/plugins/retry_errors.rb:171:in `call'
        4: from /home/ec2-user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/plugins/helpful_socket_errors.rb:10:in `call'
        3: from /home/ec2-user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/plugins/signature_v4.rb:65:in `call'
        2: from /home/ec2-user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/plugins/signature_v4.rb:112:in `apply_signature'
        1: from /home/ec2-user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/aws-sdk-core-3.44.2/lib/aws-sdk-core/plugins/signature_v4.rb:72:in `sign_request'
Aws::Errors::MissingCredentialsError (unable to sign request without credentials set)
>>

Unsure how to improve the workaround without digging further. Let me know if you figure out a better way. Cheers.

tung · January 19, 2019, 4:59am

For others: Probably the simplest way to use dynamodb in your application is to use IAM user with an actually AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY vs the above workaround. It’s a bit of bummer because AWS_PROFILE is quite handy. Interested if there’s some better approach here