switched method of determining aws account id to STS #286
Conversation
tkrueger
force-pushed
the
fix-aws-account-id-lookup
branch
from
9cd83fc to
c0fbb7d
Compare
This is more stable, as it also works when using temporary credentials. Signed-off-by: Thorsten Krüger <thorstenkg@gmail.com>
tkrueger
force-pushed
the
fix-aws-account-id-lookup
branch
from
c0fbb7d to
6db35d1
Compare
|
Thanks for having me ;-) Still trying to make the style checks in travis happy, but I think I know what it needed. |
|
To clarify what's going on here, in a recent version of train, we added support for detecting a "uuid" of the platform. For AWS, the Account ID was selected as the uuid. In the initial code, we parsed the UUID from the ARN of the current user, obtained from the IAM client. When using STS creds, no default username can be detected, and the API returns the error message "Must specify userName when calling with non-User credentials". |
There was a problem hiding this comment.
I don't believe this is an appropriate fix, unfortunately. Our current code assumes you are using IAM non-STS keys, and breaks for STS keys. I think this PR will break in the other direction. I suggest we use the IAM client call get_account_summary, or something else that assumes neither the current principal is a user nor a STS-authorized principal.
|
You might be right there... Unfortunately, Assuming that people are either using temporary credentials or user-based ones, how about trying first the old code, catch the exception and then try for STS? |
|
@tkrueger , I need to drink my coffee before reviewing PRs :-) Your code using STS to call So, no need to switch between the two approaches. |
There was a problem hiding this comment.
This works great - I tested it with STS ENV creds, and with an access-key based profile named in the ENV. In both cases, Train.create('aws').connection.unique_identifier returned the account ID (rather than erroring). Great work @tkrueger !
Description
Encountered error "Must specify userName when calling with non-User credentials" when using temporary AWS credentials through inspec aws.
Train and Platform Version
Inspec version 2.1.26 worked fine, 2.1.27 stopped working. Discovered that I was using train version 1.4.0. Tested this with the newest git clone from today. I'm not sure when/how inspec switched the dependency, but that shouldn't affect this issue.
Replication Case
run
bundle exec inspec exec --log-level=debug -t aws://when using AWS temporary credentials.Possible Solutions
Found references of this problem in other repos, along with indication that going through STS instead of IAM is more stable. Changed the aws transport to do so, and now the inspec command runs without complaints.
Stacktrace