Better documentation around how gossm looks for creds

[chiefy]

trafficstars

Just had an issue here (and I haven't had time to confirm it) but it looks like the user had some AWS_ environment vars set and gossm wasn't attempting to pick up ~/.aws/credentials

Would be nice to have a note on how gossm looks for creds (pretty sure it just uses the AWS lib, right?)

[andymac4182]

This would be great as I am having issues using this with Granted https://github.com/common-fate/granted where it sets the environment variables including AWS_PROFILE causing gossm to attempt to use the SSO credentials instead of the environment variables that it would normally do under the AWS SDK.

Looks like someone else tried to fix this for their use case as well https://github.com/tedsmitt/gossm/commit/1ec27688084f7f3ee342c9b69ba12302d45b6d07 @tedsmitt

[jaymecd]

Similar problem here, it seems extended profile is not supported.

I have 1 user profile source and role profile target configured in custom file locations.

export AWS_CONFIG_FILE=/Users/jaymecd/ws/my-project/.local/aws/config
export AWS_SHARED_CREDENTIALS_FILE=/Users/jaymecd/ws/my-project/.local/aws/credentials

• content of $AWS_SHARED_CREDENTIALS_FILE file:

  [source]
  # user that only has permission to assume "target" role
  aws_access_key_id = AKIA.......
  aws_secret_access_key = .........
  

• content of $AWS_CONFIG_FILE file:

  [profile source]
  role_session_name = source
  region_name = eu-central-1
  
  [profile target]
  role_session_name = target 
  source_profile = source
  role_arn = arn:aws:iam::111222333444:role/TargetRole
  region_name = eu-central-1
  

Running start with target profile - unexpected behaviour - profile is not detected:

$ time gossm start -p target
[Expire] gossm default mfa credential file /Users/jaymecd/ws/my-project/.local/aws/credentials
[err] [err][cmd.initConfig:217] failed to refresh cached credentials, no EC2 IMDS role found, operation error ec2imds: GetMetadata, exceeded maximum number of attempts, 3, request send failed, Get "http://169.254.169.254/latest/meta-data/iam/security-credentials/": dial tcp 169.254.169.254:80: connect: host is down

real	0m12.052s
user	0m0.020s
sys	0m0.024s

Running start with source profile (allowed only to assume target role) - expected behaviour - granted sts:AssumeRole permission only:

$ time gossm start -p source
region (eu-central-1)
[err] operation error SSM: DescribeInstanceInformation, https response error StatusCode: 400, RequestID: 14718550-65ca-4742-8f6f-4c7721ac35b2, api error AccessDeniedException: User: arn:aws:iam::111222333444:user/source is not authorized to perform: ssm:DescribeInstanceInformation on resource: arn:aws:ssm:eu-central-1:111222333444:* because no identity-based policy allows the ssm:DescribeInstanceInformation action

real	0m0.345s
user	0m0.025s
sys	0m0.035s

However, AWS CLI runs correctly and resolves extended profile:

$ aws sts get-caller-identity --profile source
{
    "UserId": "AIDA...",
    "Account": "111222333444",
    "Arn": "arn:aws:iam::111222333444:user/source"
}

$ aws sts get-caller-identity --profile target
{
    "UserId": "AROA...:target",
    "Account": "111222333444",
    "Arn": "arn:aws:sts::111222333444:assumed-role/TargetRole/target"
}

UPD: discovered that AWS SDK effectively handles credentials lookup by default. Just need to declare session as sess := session.Must(session.NewSession()) and provide AWS_SDK_LOAD_CONFIG=true envvar, so SDK parses $AWS_CONFIG_FILE as well. Or simulate this logic using SharedConfigFiles option.