Closed choonming closed 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
@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.
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
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 = ...
@choonming are you still experiencing issues?
@mbarneyjr sorry for the late response but it does work now. thank you for your patience 👍
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
This is my .aws/config
The credentials in
.aws/config
is stored under[shared]
. If I tried to assume the role using theshared
profile, it will work as it should but only fails when I try to assume the roledev