Fixing 5 Common AWS IAM Errors

Identity and access management (IAM) is a foundation service for any cloud provider to provide security in the cloud. It allows to manage access to services, resources, and applications. It is a core service but at times it does not perform the way it is supposed to be and while using it we may encounter bugs/errors. 

In today’s topic we will look at the top five common AWS IAM errors , what caused them? How to fix?

Related: Comparing IAM Services in AWS, Azure & Google Cloud

Five common AWS IAM errors

1. AccessDeniedException – I can’t assume a role

Purpose of IAM role is delegation of AWS resources across different AWS accounts in your ownership. Like you want to share one account with users in different accounts and to make this possible it is required to establish a relationship of trust between the trusting account and your other AWS trusted accounts. Let’s take a case of cross account access where you want users in development account access to resources in production account. If permissions are not set correctly the below error will be encountered.

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 AccessDeined error: one the user in the development account doesn’t have permission to call sts:AssumeRole or second trust relationship in the production account is not configured correctly.

How to fix?

Verify the IAM policy attached to user in development account grants right to sts:AssumeRole action for the role in production account or you must explicitly grant permission using policy as under:

{

“Version”: “2012-10-17”,

“Statement”: [{

   “Effect”: “Allow”,

   “Action”: [“sts:AssumeRole”],

   “Resource”: “arn:aws:iam::user:role/role”

 }]

}

Next step is to verify the development account from which AssumeRole is called is setup in production account as trusted entity for role the user is trying to assume. 

{

 “Version”: “2023-03-25”,

 “Statement”: [

   {

     “Effect”: “Allow”,

     “Principal”: {

       “AWS”: “arn:aws:iam::user:user-name”

     },

     “Action”: “sts:AssumeRole”,

     “Condition”: {}

   }

 ]

}

On successful assumption of role API returns a set of temporary security credentials to be used to access production accounts with permissions specified in file. 

2. AccessDeniedException – I can’t call an AWS API Operation

While providing access to resources in an AWS account the principle of least privileges shall apply. Least privileges grant only the minimum level of access required to perform a necessary task. Let’s take an example to explain it further , a user is trying to call the list bucket operation on an Amazon S3 bucket using CLI and encounters the below error.

Error

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

Cause 

The AccessDeined error occurred because the user attempting to perform this action has not been explicitly granted access to a list of bucket contents. 

How to fix?

Attach an inline policy like below

{

   “Version”: “2012-10-17”,

   “Statement”: [

       {

           “Sid”: “VisualEditor0”,

           “Effect”: “Allow”,

           “Action”: [

               “s3:ListAllMyBuckets”,

               “s3:ListBucket”,

               “s3:HeadBucket”

           ],

           “Resource”: “*”

       }

   ]

}

To have an additional layer of security instead of using wild characters we can assign name objects in the resource element to mention which object or objects policy covers. In below statement we have used allow access to a specific bucket using the resource – 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/*”

       }

   ]

}

3. UnauthorizedOperation – I am not authorized to Perform an Operation

This error comes when you are not authorized to perform certain operations. For example, you want to list EC2 instances in an account using describe-instance action. 

Error

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

Cause

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

How to fix?

Attach an inline policy as below

{

   “Version”: “2012-10-17”,

   “Statement”: [

       {

           “Sid”: “VisualEditor0”,

           “Effect”: “Allow”,

           “Action”: [

               “ec2:DescribeInstances”

           ],

           “Resource”: “*”

       }

   ]

}

4. DescribeInstances

It can’t be defined with an ARN as some services do not allow to specify actions for individual resources and require the use of wildcards in resource elements. 

One service is Not authorized to Perform an Action on Another Service – while managing AWS resources we often need to grant one AWS service access to another service to perform tasks. For example, you want to query a DynamoDB table from Lambda function. But the Lambda code snippet to query the USERS table gives below error

Query

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

The error is happened because the Lambda execution role does not have permission to query USERS DynamoDB table 

How to fix?

Modify the Lambda execution role by attaching inline policy as below

{

   “Version”: “2012-10-17”,

   “Statement”: [

       {

           “Sid”: “VisualEditor0”,

           “Effect”: “Allow”,

           “Action”: “dynamodb:Query”,

           “Resource”: “arn:aws:dynamodb:region:account:table/USERS”

       }

   ]

}

5. The policy must contain a valid version string

When creating or modifying a policy an error might be encountered which states policy should have valid Version string. This version policy element specifies language syntax rules which should be used for policy processing. For example using the current date for the version policy element; which is limited to few select values could cause error. 

{

   “Version”: “2012-10-17”,

   “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 selected values 

How to fix?

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

2012-10-17 – Current version of policy language

2008-10-17 – Older version of policy language which does not support new features 

If Version element is not included; default is 2008-10-17 

Leave a Comment

Select your currency
INR Indian rupee