Environment variables not being used

[mogopz]

Something seems to have changed with v1.2.0 and environment variables aren't being picked up. The account defined in my ~/.aws/credentials file basically has no permissions other than the ability to assume roles in other accounts.

I use assume-role which sets all the environment variables for me (debug snippet below).

➜ assume-role <aws_account> <role_name>
Success! IAM session envars are exported.
AWS_CONFIG_REGION="ap-southeast-2";
AWS_USERNAME="xxxxxxx";
MFA_DEVICE_ARGS="--user-name xxxxxxxxx --query MFADevices[0].SerialNumber --output text --profile default";
MFA_DEVICE="arn:aws:iam::xxxxxxxxxx:mfa/xxxxxxxxxx";
SESSION_ARGS="";
SESSION="";
ROLE_SESSION_ARGS="--role-arn arn:aws:iam::xxxxxxxxxx:role/xxxxxxxx --external-id xxxxxxxxxxx --duration-seconds 3600 --role-session-name 1609835656";
ROLE_SESSION="{
    "Credentials": {
        "AccessKeyId": "xxxxxxxxxxxxxxx",
        "SecretAccessKey": "xxxxxxxxxxxxx",
        "SessionToken": "xxxxxxxxxxxxxxx",
        "Expiration": "2021-01-05T09:34:17+00:00"
    },
    "AssumedRoleUser": {
        "AssumedRoleId": "xxxxxxxxxxxxx",
        "Arn": "arn:aws:sts::xxxxxxxxxx:assumed-role/xxxxxxxx/1609835656"
    }
}";
SESSION_TIMEOUT="43200";
ROLE_SESSION_TIMEOUT="3600";
AWS_PROFILE_ASSUME_ROLE="";

But then when I use gossm v1.2.0 it's still using the default account defined in ~/.aws/credentials - if I use v1.1.1 it works as expected.

➜ gossm start
AccessDeniedException: User: arn:aws:iam::xxxxxxxxxxxx:user/xxxxxxxxxxx is not authorized to perform: ssm:DescribeInstanceInformation on resource: arn:aws:ssm:ap-southeast-2:xxxxxxxxxxxx:*
    status code: 400, request id: c73de091-f822-4189-b4f8-0abf646b6edb

[gjbae1212]

@mogggggg Maybe it' need to additonal ssm:DescribeInstanceInformation permission. ssm:DescribeInstanceInformation is using to find possible instances that can access over ssm-agent.

[mogopz]

@gjbae1212 But if it was using the account details from the environment variables it shouldn't need that, right? The account I'm assuming has the Administrator role.

I'm also not sure why the permissions would be different between v1.20 and v1.1.1?

[gjbae1212]

@mogggggg gossm with v1.20 have added new feature used ssm:DescribeInstanceInformation.

15

[mogopz]

Thanks @gjbae1212, unfortunately I still don't think it's working as intended. The role I'm assuming via env vars has the AdministratorAccess policy attached to it so I shouldn't need to add any new permissions.

The issue seems to be that gossm isn't looking at these env vars anymore. I've just attached the AdministratorAccess to my user defined in ~/.aws/credentials and it now looks like gossm is at working but it's looking at that AWS account (which has no EC2 resources in it) instead of the one where I've assumed the role.

➜ gossm start
[start-session] profile: default, region: ap-southeast-2, target:
InvalidParameter: 1 validation error(s) found.
- minimum field size of 1, StartSessionInput.Target.

If I use the previous version of gossm it works fine, so I think this is a bug.

[gjbae1212]

@mogggggg Refined a little of code. Test it with gossm v1.2.1.

[mogopz]

@gjbae1212 Wow, you're so fast! Unfortunately I'm getting the same problem. Here's a snippet comparing between v1.2.1 and v1.1.0

➜ ./gossm-1-2-1 start
[update] aws ssm plugin
UnauthorizedOperation: You are not authorized to perform this operation.
    status code: 403, request id: de97146c-f579-415b-a803-6975a0e3ca50

➜ ./gossm-1-1-0 start
[update] aws ssm plugin
? Choose a target in AWS:  [Use arrows to move, type to filter]
<big list of all my instances>

[jonasneves]

I use temporary AWS credentials via env vars as well and I've been having the same issue:

$ gossm start

RequestExpired: Request has expired.
    status code: 400, request id: 2b17a0f6-88ca-454c-a2d4-5a2750362bd1

I can run any command with awscli without any issues:

$ aws sts get-caller-identity

{
    "UserId": "AXXXXXXXX:jneves@xxxxxxx.com",
    "Account": "8000000000",
    "Arn": "arn:aws:sts::800000000:assumed-role/Role/jneves@xxxxxx.com"
}

[tedsmitt]

Hey guys, I've raised a PR to fix this.

[toshimaru]

I confirmed the issue has been resolved on version v1.2.3. thanks @tedsmitt . <3

[mogopz]

Yep, looks good from my end too - thanks @tedsmitt!