Skip to Content

AWS CLI Access Denied
Despite Having Full Permissions

Poor error messages strike again.

Published on

Red "AccessDenied" text surrounded by random characters.

If your AWS user has an MFA device assigned to it, you might get "access denied" errors, despite having sufficient permissions or even full permissions. This is documented, but very poorly. The error messages don't mention anything about MFA.

For example, I was trying to list all buckets in S3:

aws s3 ls

…but I was getting the following error:

fatal error: An error occurred (AccessDenied) when calling the ListObjectsV2 operation: Access Denied

Sanity check

First of all, make sure you're actually authenticating as the correct user. This can easily be done with get-caller-identity(opens in new tab):

aws sts get-caller-identity

It returns basic data about the authenticated user:

	"Account": "123456789012",
	"Arn": "arn:aws:iam::123456789012:user/dodov"

If the user is correct and you've double checked your permissions, then it's likely an MFA problem.


You can follow the MFA authentication guide(opens in new tab) to get properly authenticated in a way that works. Essentially, you have to use get-session-token(opens in new tab) to generate an access key:

aws sts get-session-token --serial-number arn:aws:iam::123456789012:mfa/dodov --token-code 123123

Then, you can paste the resulting access key ID, secret access key, and session token in your ~/.aws/credentials file:

aws_access_key_id = xxxxxxxxxxxx
aws_secret_access_key = xxxxxxxxxxxxxxxxxxxxxxxxx
aws_session_token = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Once that's done, all you have to do is perform your AWS CLI commands as usual, but using this new named profile(opens in new tab):

aws s3 ls --profile my-mfa

Making it easier

There are many scripts out there that can manage your AWS CLI profiles and multi-factor authentication credentials. Simply search on GitHub(opens in new tab). The most advanced one seems to be aws-vault(opens in new tab).

Alternatively, if your organization uses SSO, you might have to use aws configure sso, which is documented in the SSO profile configuration article(opens in new tab).

If you happen to use Okta as your identity provider, be wary of aws-cli issue #7319(opens in new tab). You'll likely have to use the official Okta AWS CLI Assume Role(opens in new tab) tool, developed by the Okta team.