victorskl / yawsso

Yet Another AWS SSO - sync up AWS CLI v2 SSO login session to legacy CLI v1 credentials
MIT License
304 stars 27 forks source link

Does not sync credentials for profiles that use source_profile #9

Closed b-dean closed 4 years ago

b-dean commented 4 years ago

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:

[default]
sso_start_url = https://foo.awsapps.com/start#/
sso_region = us-east-1
sso_account_id = 123456789
sso_role_name = Engineering
region = us-east-1
output = json

[profile dev]
role_arn = arn:aws:iam::456789123:role/FullAdmin
source_profile = default
region = us-east-1
output = json

[profile qc]
role_arn = arn:aws:iam::789123456:role/FullAdmin
source_profile = default
region = us-east-1
output = json

[profile prod]
role_arn = arn:aws:iam::987654321:role/DevOps
source_profile = default
region = us-east-1
output = json

When I run yawsso It works for the default profile but fails on dev:

$ yawsso
2020-06-05 08:47:12,409 yawsso.cli   INFO     yawsso 0.3.0
2020-06-05 08:47:12,900 yawsso.cli   INFO     aws-cli/2.0.17 Python/3.7.3 Linux/4.4.0-174-generic botocore/2.0.0dev21
2020-06-05 08:47:12,903 yawsso.cli   INFO     Current named profiles in config: ['dev', 'qc', 'prod']
2020-06-05 08:47:12,903 yawsso.cli   ERROR    Your `dev` profile is not valid AWS SSO profile. Try `aws configure sso` first.

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.

victorskl commented 4 years ago

Right! I will check out how to support source_profile. Should be doable.

victorskl commented 4 years ago

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

b-dean commented 4 years ago

Thanks, I'll try it out today and let you know how it works.

b-dean commented 4 years ago

@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?

victorskl commented 4 years ago

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

https://pypi.org/project/yawsso/0.4.0rc2/

b-dean commented 4 years ago

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.
b-dean commented 4 years ago

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.

victorskl commented 4 years ago

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

https://pypi.org/project/yawsso/0.4.0rc3/

victorskl commented 4 years ago

Closed with https://github.com/victorskl/yawsso/pull/17 for pip install -U yawsso==0.4.0