37

I am trying to setup AWS CLI tools and was following instructions at http://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/set-up-ec2-cli-linux.html#setting_up_ec2_command_linux

However, after following all the steps and setting up my AWS_ACCESS_KEY and AWS_SECRET_KEY, I get

$ ec2-describe-regions
Client.UnauthorizedOperation: You are not authorized to perform this operation. (Service: AmazonEC2; Status Code: 403; Error Code: UnauthorizedOperation; Request ID: 55f02cc4-2e9f-4a0a-8b55-46bcc1973f50)

I then tried regenerating new credentials, but still getting the same error. I couldn't seem to find information about anyone else having this issue. I tried passing the keys using -O and -W, but that doesn't work either.

Any idea what I might be doing wrong?

wislo
  • 1,110
  • 2
  • 13
  • 24

4 Answers4

40

I am on free tier and found it easier to grant administrator policy to single user, which supports access from all of the amazon command line tools. you can downgrade the policy at a later time if you feel the policy is too lenient.

  1. visit https://console.aws.amazon.com/iam/home
  2. select policies in left hand menu
  3. create administrator policy from amazons existing policies
  4. select administrator checkbox and attach to your user

aws policy grant

Assuming you have set up your access keys, you should now have full command line access for given user.

before

› ec2-describe-regions
Client.UnauthorizedOperation: You are not authorized to perform this operation. (Service: AmazonEC2; Status Code: 403; Error Code: UnauthorizedOperation; Request ID: 3398ed18-1caf-4c04-865b-a54f796c653c)

after

› ec2-describe-regions
REGION  eu-central-1    ec2.eu-central-1.amazonaws.com
REGION  sa-east-1   ec2.sa-east-1.amazonaws.com
REGION  ap-northeast-1  ec2.ap-northeast-1.amazonaws.com
REGION  eu-west-1   ec2.eu-west-1.amazonaws.com
REGION  us-east-1   ec2.us-east-1.amazonaws.com
REGION  us-west-1   ec2.us-west-1.amazonaws.com
REGION  us-west-2   ec2.us-west-2.amazonaws.com
REGION  ap-southeast-2  ec2.ap-southeast-2.amazonaws.com
REGION  ap-southeast-1  ec2.ap-southeast-1.amazonaws.com

amazons UX takes some time before you get used to it

random-forest-cat
  • 33,652
  • 11
  • 120
  • 99
  • 8
    I can't believe that you just recommended that they give the user _administrator privileges_ to do a single ec2 operation. – danielpops Dec 03 '18 at 23:39
  • @danielpops i am happy to update the answer - what policy would you recommend? i've hinted that the policy is too lenient but i realize most users will gloss over this so im happy to improve the answer overall. this is what worked for me when i was learning AWS but i also dont want to encourage bad practices. – random-forest-cat Dec 04 '18 at 13:37
  • you should recommend the appropriate level of permission to solve the OP’s access issue, which is solely to allow the single action ec2:DescribeRegions, versus what you proposed which is access to every action in over 90 services that AWS offers – danielpops Dec 05 '18 at 21:26
  • @wislo’s answer (currently) below is appropriate and should be the accepted answer – danielpops Dec 05 '18 at 21:28
27

It is very unfortunate that the basic guide on using EC2 CLI tools doesn't even mention this, but looks like my issue was that I didn't have the correct policy setup under my IAM account. 

{
"Version": "2012-10-17",
"Statement": [{
  "Effect": "Allow",
  "Action": "ec2:Describe*",
  "Resource": "*"
}]
}

See this link for more details: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ExamplePolicies_EC2.html

wislo
  • 1,110
  • 2
  • 13
  • 24
  • 2
    This is really poor IMHO. Google are going to walk over AWS because of these issues. Things should just work. Effectively everything is still in beta, and the costs of reacting to change are significant. Role based policy is all very well, but leave it open by default, and warn us people. – mckenzm Feb 15 '15 at 19:52
  • 3
    @mckenzm Are you proposing that the default security policy should be "allow all access to everything"? That would be a monumental mistake. And it's not what Google Cloud does either - no-one does. Permission has to be explicitly granted. – jarmod Oct 16 '18 at 13:44
  • 1
    At least for the root user. Deny all by default is all very well for something like RACF, where there will be formal administration, but there should be some "out of the box" access for the default/root user, even if it is opt-in at setup. Otherwise why even have keys if they are not going to work? – mckenzm Oct 17 '18 at 00:08
  • 3
    @mckenzm that in fact is the default for the root user. It's why you should disable the root user credentials once you've set up initial IAM groups and users. All IAM credentials have zero permission by default and have to be actively given permissions. – jarmod Oct 19 '18 at 02:09
3

Some policies have to be assigned to IAM users and groups instead of IAM roles. We were assigning policies like AdministratorAccess or AmazonEC2FullAccess to an IAM role created for federation, and AWS CLI commands failed with the same response.

Assigning policies to IAM users and groups ensured that the policies worked. We assigned policies like the AmazonEC2FullAccess policy to admins. For listing regions and instances, as is required in describe-regions command, policies like AmazonEC2ReadOnlyAccess is sufficient as they contain the necessary statements to allow restricted actions on the required resources.

Vineet Reynolds
  • 76,006
  • 17
  • 150
  • 174
  • 2
    The statement "Some policies have to be assigned to IAM users and groups instead of IAM roles" is misleading. There's no inherent need to do this. If you are presenting persistent IAM user credentials then the IAM policies attached to that IAM user or that IAM user's groups are relevant. If you are presenting temporary session credentials (retrieved from STS by assuming an IAM role, as is typical for federated access) then the IAM policies attached to that IAM role are relevant. – jarmod Oct 16 '18 at 14:06
  • This is very inaccurate. Policies can be attached to users or groups or roles and the net effect should be more or less the same (with some caveats that are not applicable here) – danielpops Dec 03 '18 at 23:39
0

With multi-factor authentication (MFA) policies now becoming increasingly adopted and applied, I found my "direct" use of security key + secret being blocked as Unauthorized because of an explicit Deny permission set in another attached policy.

    {
        "Sid": "BlockAnyAccessOtherThanAboveUnlessSignedInWithMFA",
        "Effect": "Deny",
        "NotAction": "iam:*",
        "Resource": "*",
        "Condition": {
            "BoolIfExists": {
                "aws:MultiFactorAuthPresent": "false"
            }
        }
    }

In other words, nothing except IAM and other, previously specified actions would be allowed without MFA being set first.

Running the STS get-session-token with the ARN of any previously-registered MFA device generates temporary (12 hour) credentials.

$ aws sts get-session-token --serial-number arn-of-the-mfa-device --token-code code-from-token

{
    "Credentials": {
        "SecretAccessKey": "secret-access-key",
        "SessionToken": "temporary-session-token",
        "Expiration": "expiration-date-time",
        "AccessKeyId": "access-key-id"
    }
}

These now become the Access Key and Secret for subsequent CLI calls.

export AWS_ACCESS_KEY_ID=example-access-key-as-in-previous-output
export AWS_SECRET_ACCESS_KEY=example-secret-access-key-as-in-previous-output
export AWS_SESSION_TOKEN=example-session-token-as-in-previous-output

Source: https://repost.aws/knowledge-center/authenticate-mfa-cli

changingrainbows
  • 2,551
  • 1
  • 28
  • 35