trek10inc / awsume

A utility for easily assuming AWS IAM roles from the command line.
https://awsu.me
MIT License
487 stars 90 forks source link

awsume not fetching profle credentials #127

Closed choonming closed 3 years ago

choonming commented 3 years ago

Updated to the latest version 4.5.0. Tried to assume role for a profile that normally worked and tested it worked on version 4.4.1. After upgrading, I'm getting the error

Awsume error: Invalid profile [default] Missing keys aws_access_key_id, aws_secret_access_key, or credential_source, or credential_process

This is my .aws/config

[default]
region = eu-west-1
output = json
sts_regional_endpoints = regional
cli_pager=

[profile shared]
source_profile = default
mfa_serial = arn:aws:iam::123456789:mfa/user

[profile dev]
source_profile = tutuka-ops
role_arn = arn:aws:iam::234567890:role/administrators
mfa_serial = arn:aws:iam::123456789:mfa/user
role_session_name = user

The credentials in .aws/config is stored under [shared]. If I tried to assume the role using the shared profile, it will work as it should but only fails when I try to assume the role dev

mbarneyjr commented 3 years ago

It seems like your profile shared defines a source_profile property, but is not a role profile (does not have a role_arn property). According to the configuration reference, source_profile:

Specifies a named profile with long-term credentials that the AWS CLI can use to assume a role that you specified with the role_arn parameter. You cannot specify both source_profile and credential_source in the same profile.

It appears that your [shared] profile has a source_profile that points to the default profile, but the default profile does not contain long-term credentials, only default cli options

If shared is supposed to be a role, you must supply a role_arn with either source_profile or credential_source. If you specify source_profile, it must point to a profile with long-term credentials (aws_access_key_id and aws_secret_access_key). If shared itself has long-term credentials, it should not have a source_profile property

choonming commented 3 years ago

@mbarneyjr this is interesting because prior to upgrading to version 4.5.0, there was never an issue of such configuration. Not to mention, when I run the following command aws sts get-caller-identity --profile dev, it completes successfully.

Therefore I do not understand how can awsume behave differently than what is expected? The profile shared do have a long term credentials and it is stored in .aws/credentials under [shared] section of the file. The [default] section is just used for setting defaults.

mbarneyjr commented 3 years ago

Your shared profile is invalid, it's referencing default as a source_profile, where there's two issues. 1) Your default profile isn't a profile with credentials, just cli configuration, and 2) there is no role_arn property on your shared profile, so there's nothing to assume or do with a source profile's credentials

If you awsume dev, it should see the role_arn and source_profile properties on the dev profile. It'll first awsume tutuka-ops (the source_profile property) and then use those credentials to assume the role arn specified by the role_arn property. If you awsume shared, it'll notice that shared is an invalid profile and will give you the error you're seeing

mbarneyjr commented 3 years ago

Assuming shared contains long lived credentials and is not a role that you'd like to assume, I think the configuration you're looking for would be something like this, based on what you sent initially:

~/.aws/config:

[default]
region = eu-west-1
output = json
sts_regional_endpoints = regional
cli_pager=

[profile shared]
mfa_serial = arn:aws:iam::123456789:mfa/user

[profile dev]
source_profile = tutuka-ops
role_arn = arn:aws:iam::234567890:role/administrators
mfa_serial = arn:aws:iam::123456789:mfa/user
role_session_name = user

~/.aws/credentials:

[shared]
aws_access_key_id = ...
aws_secret_access_key = ...

[tutuka-ops]
aws_access_key_id = ...
aws_secret_access_key = ...
mbarneyjr commented 3 years ago

@choonming are you still experiencing issues?

choonming commented 3 years ago

@mbarneyjr sorry for the late response but it does work now. thank you for your patience 👍