Fixing 5 Common AWS IAM Errors

Amazon Web Services (AWS) Identity & Access Management (IAM) is a foundational service that provides security in the cloud. It allows you to manage access to your AWS services, resources, and applications. It's a core service for AWS, but nothing's perfect. And while using it, you may encounter errors. But don't sweat it! Let’s dig into the cause and resolution for five common AWS IAM errors.

Get started with ACG and transform your career with courses and real hands-on labs in AWS, Microsoft Azure, Google Cloud, and beyond.

IAM roles can be used to delegate access to your AWS resources across different AWS accounts that you own. For example, you can share resources in one account with users in a different account. This is made possible by establishing trust relationships between the trusting account and your other AWS trusted accounts.

Let’s take the case where you want to give users in your development account access to resources in your production account. This could be a case where there is a need to promote an update made in development to production. This type of access is called cross-account access. If permissions aren’t set up correctly, you may encounter the error below.

Error
An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam:::user is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::user:role/role

Cause
There are two possible causes for this AccessDenied error: the user in your development account doesn’t have permission to call sts:AssumeRole, or the trust relationship in the production account is not configured correctly.

Assuming you’ve already created a role in your production account that a user in your development account can assume (to retrieve temporary security credentials), consider the solutions below. 

Solution #1
Verify the IAM policy attached to the user in your development account grants that user permission to the sts:AssumeRole action for the role in your production account they are attempting to assume. You must explicitly grant this permission using a policy similar to what’s shown below.

{
 "Version": "2012-10-17",
 "Statement": [{
   "Effect": "Allow",
   "Action": ["sts:AssumeRole"],
   "Resource": "arn:aws:iam::user:role/role"
 }]
}

Solution #2
Maybe the user in your development account already has permission to the sts:AssumeRole action, but the error still occurs. The next step is to verify that your development account (the account from which you are calling AssumeRole) is set up in your production account as a trusted entity for the role the user is attempting to assume. A role similar to what’s shown below in your production account should do the trick.

{
 "Version": "2012-10-17",
 "Statement": [
   {
     "Effect": "Allow",
     "Principal": {
       "AWS": "arn:aws:iam::user:user-name"
     },
     "Action": "sts:AssumeRole",
     "Condition": {}
   }
 ]
}

Upon success of assuming the role, the AssumeRole API returns a set of temporary security credentials that can be used to access the production account with the permissions specified in role.

When providing access to resources in your AWS account, consider the principle of least-privileged permissions. Least-privileged permissions grant only the minimum level of access necessary to perform a given task. This principle highlights the fact that users and services cannot access resources until access is explicitly granted. 

Let’s take the case of a user attempting to call the list bucket operation on an Amazon S3 bucket using the command line interface. The user is met with the error below.

Error
An error occurred (AccessDenied) when calling the ListBuckets operation: Access Denied

Cause
The AccessDenied error occurs because the user attempting to perform this action has not been explicitly granted access to list the bucket contents. The user will not have access to perform this action unless you explicitly grant it. 

Solution
The easy solution is to attach an Inline Policy, similar to the snippet below, to the user.

{
   "Version": "2012-10-17",
   "Statement": [
       {
           "Sid": "VisualEditor0",
           "Effect": "Allow",
           "Action": [
               "s3:ListAllMyBuckets",
               "s3:ListBucket",
               "s3:HeadBucket"
           ],
           "Resource": "*"
       }
   ]
}

To provide an additional level of security, you can name objects in the Resource element instead of using the wildcard *, which represents all resources. If you’re not familiar with the Resource element, it specifies the object or objects that the policy covers. 

The example below allows access to all items within a specific Amazon S3 bucket using the Resource, the Amazon Resource Name (ARN), and the wildcard *.

{
   "Version": "2012-10-17",
   "Statement": [
       {
           "Sid": "VisualEditor0",
           "Effect": "Allow",
           "Action": [
               "s3:ListAllMyBuckets",
               "s3:ListBucket",
               "s3:HeadBucket"
           ],
           "Resource": "arn:aws:s3:::bucket_name/*"
       }
   ]
}

Looking to get AWS certified or level up your cloud career? Learn in-demand AWS skills by doing — with ACG.

When attempting to perform an operation, you may see an error stating you’re not authorized to perform that operation. Let’s take the case of listing EC2 instances in an account using the describe-instances action.

Error
An error occurred (UnauthorizedOperation) when calling the DescribeInstances operation: You are not authorized to perform this operation.

Cause
The UnauthorizedOperation error occurs because either the user or role trying to perform the operation doesn’t have permission to describe (or list) EC2 instances. 

Solution
The easy solution is to attach an Inline Policy, similar to the snippet below, giving the user access.

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

It is important to highlight that the DescribeInstances action cannot be defined with an ARN in the Resource element. Some services do not allow you to specify actions for individual resources and require that you use the wildcard * in the Resource element instead. While you can define resource level permissions for a subset of the EC2 APIs, the DescribeInstances action currently does not support resource level permissions.  In this case, if you add an ARN number to the Resource element, you will continue to see the UnauthorizedOperation error.

Want to Prevent the deletion of an Amazon S3 Bucket? Use the AWS Policy Generator tool to create policies that control access to AWS products and resources!

When managing your AWS resources, you often need to grant one AWS service access to another service to accomplish tasks. Let’s take the case where you need to query a DynamoDB table from a Lambda function. The following Lambda code snippet, to query the USERS table, results in the error shown below. 

table = boto3.resource('dynamodb').Table('USERS')

response = table.query(KeyConditionExpression=Key('USER_ID').eq(userid))

Error
arn:aws:sts::user:assumed-role/role/function is not authorized to perform: dynamodb:Query on resource: arn:aws:dynamodb:region:account:table/USERS

Cause
This error is caused because the Lambda's execution role does not have permission to query the USERS DynamoDB table.

Solution
The simple solution is to modify the Lambda’s execution role by attaching an Inline Policy similar to the following:

{
   "Version": "2012-10-17",
   "Statement": [
       {
           "Sid": "VisualEditor0",
           "Effect": "Allow",
           "Action": "dynamodb:Query",
           "Resource": "arn:aws:dynamodb:region:account:table/USERS"
       }
   ]
}

The same method can be followed to allow Lambda access to Amazon S3. The method described above will work if the Lambda function and S3 bucket are in the same AWS account. However, if they are in different accounts, you will need to grant Amazon S3 permissions on both the Lambda execution role and the bucket policy.

When creating or modifying a policy, you may encounter an error that states the policy must contain a valid Version string. This Version policy element is not the same as multiple version support for managed policies. The Version policy element specifies the language syntax rules that should be used to process the policy. This can be a point of confusion for those new to IAM as they often try to use the current date for the Version policy element; however, the Version is limited to a few select values. For example, using the current date for the Version string, similar to what’s shown below, will cause an error.

{
   "Version": "2020-07-30",
   "Statement": [
       {
           "Sid": "VisualEditor0",
           "Effect": "Allow",
           "Action": [
               "ec2:DescribeInstances"
           ],
           "Resource": "*"
       }
   ]
}

Error
This policy contains the following error: The policy must contain a valid version string

Cause
The error occurs because Version is limited to a few select values.

Solution
The solution is to use one of the valid Version element values. Currently, IAM supports the following Version element values:

• 2012-10-17 - This is the current version of the policy language.
• 2008-10-17 - This is an older version of the policy language and doesn’t support newer features. 

If you do not include a Version element, the value defaults to 2008-10-17.

Well, there you have it! We’ve reviewed some of the common errors along with resolutions that you may encounter when using IAM.

Looking for more details and tips to help you troubleshoot other errors with IAM? Check out my new introductory course around IAM, Identity and Access Management (IAM) Concepts.

And if you want to learn more about IAM in Azure, check out free-for-the-month-of-October course IAM for Azure. It's one of the two dozen free cloud courses available with A Cloud Guru's free tier.

There's more where that came from! A Cloud Guru offers learning paths, quizzes, certification prep, and more.