Closed b-dean closed 4 years ago
Right! I will check out how to support source_profile
. Should be doable.
Hey, added source_profile
support with https://github.com/victorskl/yawsso/pull/10 and, released 0.4.0rc1
avail now in https://pypi.org/project/yawsso/0.4.0rc1/
If you have previous installation, upgrade with pip install -U yawsso==0.4.0rc1
I leave you for testing RC as I haven't used source profile intensively. Unless any other issues or improvements, final 0.4.0
will be GA as schedule in milestone https://github.com/victorskl/yawsso/milestone/2
Thanks, I'll try it out today and let you know how it works.
@victorskl, I tried it out a bit and it's not quite working. it gets creds that don't have the assumed roles from the profiles
the information in my ~/.aws/cli/cache/*.json
has credentials that do work and have the right roles
something like:
{
"Credentials": {
"AccessKeyId": "ASIA***********",
"SecretAccessKey": "***************************",
"SessionToken": "********************",
"Expiration": "2020-06-08T20:59:26+00:00"
},
"AssumedRoleUser": {
"AssumedRoleId": "AROA***********:botocore-session-1591646365",
"Arn": "arn:aws:sts::<dev account number>:assumed-role/FullAdmin/botocore-session-1591646365"
}
}
If I'm understanding your change it seems like what it'd be doing is getting a set of the source profile creds maybe 3 times, rather than creds that are for the assumed role in the ~/.aws/.config
for each profile
when I call get the current caller identity with sts, I have this:
$ aws sts get-caller-identity
{
"UserId": "AROA***********:botocore-session-1591646365",
"Account": "<dev account number>",
"Arn": "arn:aws:sts::<dev account number>:assumed-role/FullAdmin/botocore-session-1591646365"
}
note that the botocore session thing matches the one in the ~.aws/cli/cache/*.json
file
whereas when I use a v1 auth app with the creds from yawsso I get something like:
access denied: User: arn:aws:sts::<source profile account number>:assumed-role/AWSReservedSSO_Engineering_9d053aad2178539b/ben@example.com is not authorized ...
which is the wrong role.
I'm sorry if I'm not explaining this well. Does that make sense?
Thanks Ben @b-dean You explained right! I was confused with sso cache vs cli cache. I understand now, and able to reproduce your use case. I fixed with this PR https://github.com/victorskl/yawsso/pull/14
Can you try test RC2 and verify it? It contains fix for source profile, and other milestone features. If all good, I will release final one soon. Thanks.
pip install -U yawsso==0.4.0rc2
still having issues. Here's some output w/ --trace
$ yawsso --trace
2020-06-15 12:07:01,223 yawsso.cli TRACE Logging level: TRACE
2020-06-15 12:07:01,223 yawsso.cli TRACE args: Namespace(bin=None, command=None, debug=False, default=False, default_only=False, export_vars=False, profiles=None, trace=True, version=False)
2020-06-15 12:07:01,223 yawsso.cli TRACE AWS_CONFIG_PATH: /home/ben/.aws/config
2020-06-15 12:07:01,223 yawsso.cli TRACE AWS_CREDENTIAL_PATH: /home/ben/.aws/credentials
2020-06-15 12:07:01,223 yawsso.cli TRACE AWS_SSO_CACHE_PATH: /home/ben/.aws/sso/cache
2020-06-15 12:07:01,223 yawsso.cli TRACE Cache SSO JSON files: ['/home/ben/.aws/sso/cache/7b47eb434575710830b971195df642ca62a3e843.json', '/home/ben/.aws/sso/cache/botocore-client-id-us-east-1.json']
2020-06-15 12:07:01,725 yawsso.cli DEBUG aws-cli/2.0.17 Python/3.7.3 Linux/4.4.0-184-generic botocore/2.0.0dev21
2020-06-15 12:07:01,726 yawsso.cli DEBUG Current named profiles in config: ['dev', 'qc', 'prod', 'it']
2020-06-15 12:07:01,726 yawsso.cli TRACE Syncing profile... dev: {'role_arn': 'arn:aws:iam::012345678901:role/FullAdmin', 'source_profile': 'default', 'region': 'us-east-1', 'output': 'json'}
2020-06-15 12:07:01,726 yawsso.cli TRACE Using cached SSO login: /home/ben/.aws/sso/cache/7b47eb434575710830b971195df642ca62a3e843.json
2020-06-15 12:07:02,373 yawsso.cli TRACE Fetching credentials using assume role for `dev`
2020-06-15 12:07:03,945 yawsso.cli TRACE Command was: aws sts assume-role --output json --profile dev --role-arn arn:aws:iam::012345678901:role/FullAdmin --role-session-name yawsso-session-1592237223 --duration-seconds 43200 --region us-east-1
2020-06-15 12:07:03,945 yawsso.cli TRACE Output was: An error occurred (ValidationError) when calling the AssumeRole operation: The requested DurationSeconds exceeds the 1 hour session limit for roles assumed by role chaining.
2020-06-15 12:07:03,945 yawsso.cli ERROR Error executing command: `aws sts assume-role`. Exception: An error occurred (ValidationError) when calling the AssumeRole operation: The requested DurationSeconds exceeds the 1 hour session limit for roles assumed by role chaining.
Note the thing in the aws docs on troubleshooting roles about role changing
If you use role chaining (using a role to assume a second role), your session is limited to a maximum of one hour. If you then use the DurationSeconds parameter to provide a value greater than one hour, the operation fails.
It makes me think that the AWS CLI v2 must not be doing that because the session I get lasts for longer than an hour.
Okay; fix with PR https://github.com/victorskl/yawsso/pull/16 Role chaining is inevitable in this scenario, so I make it fall back to 1 hour role chaining limit. You can always yawsso
again if cred are expired, anyway. Please check RC3, should work!
pip install -U yawsso==0.4.0rc3
Closed with https://github.com/victorskl/yawsso/pull/17 for pip install -U yawsso==0.4.0
The setup I have is one account is the organization account that has the SSO and then there are several other accounts where I use the sso from the org account when assuming a role. Example:
When I run
yawsso
It works for the default profile but fails on dev:I would expect that it would get the credentials from the cache in
~/.aws/cli/cache
for these source_profile assumed role situations. In fact, if I get those creds and put them in my~/.aws/credentials
then older tools without sso support (like terraform, docker-credential-ecr-login, etc) work fine.