Bypassing AWS Cli profile to use IAM Roles

While trying to upgrade some legacy AWS instances which were already configured and working, I just needed to start configuring and using EC2 IAM Roles.

I just attached a simple (and permissive) EC2 role to my instance to see what I could do with it.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "s3:List*",
                "s3:Get*"
            ],
            "Effect": "Allow",
            "Resource": "*"
        }
    ]
}

and started to furiously type my copy command
aws s3 cp s3://my-own-and-only-bucket/file .

Problem was that someone had already configured some profiles for the aws cli, even worst, the default profile was also configured and it was being used for some random operation I wasn't able to find out.

Checking AWS Documentation on configuration precedence

1. Command line options – Overrides settings in any other location. You can specify --region, --output, and --profile as parameters on the command line.

2. Environment variables

3. *CLI credentials file *( ~/.aws/credentials on Linux or macOS, or at C:\Users\USERNAME.aws\credentials on Windows.)

4. CLI configuration file ( ~/.aws/config on Linux or macOS, or at C:\Users\USERNAME.aws\config on Windows.)

5. Container credentials

6. Instance profile credentials – You can associate an IAM role with each of your Amazon Elastic Compute Cloud (Amazon EC2) instances.

And as the default profile didn't have all the needed S3 permissions I kept hitting the annoying 403 Forbidden.

It really crossed my mind first to delete the credentials file and second to rename the default profile to something else. I just had no way to know what process would break next.

So, to bypass the credentials file default profile and make the aws cli use the IAM Role, all I needed to do was to create a dummy almost empty profile setting the output ( for example) ...

vim ~/.aws/credentials

[profile dummy]
output = json

... and force my copy command to use that profile
aws s3 cp s3://my-own-and-only-bucket/file . --profile dummy

Turns out that without the access keys on that profile, it ended up using the next available credentials: the IAM role.

Now I could resume with the upgrade ... as soon as I found out what was using those credentials.