Skip to content
By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post
About re:Post

How do I troubleshoot explicit deny error messages when I request API calls with IAM roles or users?

8 minute read
0

I want to troubleshoot an explicit deny error message when I make an API call with an AWS Identity and Access Management (IAM) role or user.

Short description

For an IAM role or user to make a successful API call, the entity must meet the following conditions:

  • The role or user has the correct permissions to request an API call.
  • No statement in policies that apply to the request context denies the permission.

If your IAM entity doesn't meet these conditions, then the API call fails and returns an access denied error similar to the following:

  • "IAM user or role that has the issue: arn:aws:iam::444455556666:role/ExampleRole"
  • "Error: An error occurred (AccessDenied) when calling the RunInstances operation: User: arn:aws:iam::444455556666:user/ExampleUser is not authorized to perform: ec2:RunInstances on resource: arn:aws:ec2:us-east-1:444455556666:volume/* with an explicit deny"

Note: The troubleshooting steps in this article deal specifically with explicit deny errors and not implicit deny errors. For more information on implicit deny errors, see The difference between explicit and implicit denies.

Resolution

Explicit deny errors occur because of issues in one or more of the following policy types:

  • Identity-based policies
  • Resource-based policies
  • Permissions boundary
  • Service control policies
  • Resource control policies
  • Session policies

Identity-based policies

The identity-based policy controls the allowed or denied action of an entity. Use these troubleshooting steps to identify issues with identity-based policies.

Note: It's a best practice to use Deny with StringNotLike in conditions to prevent accidental lockout.

  1. Check that no deny statement exists in your identity-based policy. This example contains a deny statement:

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "iam:DeleteRole",
            "Resource": "*"
        }
    ]
}

  2. Check if Multi-Factor Authentication (MFA) is enforced on your policy. If your IAM entity authenticates without MFA and an MFA enforcement policy applies to it, the permission is denied. See this example of MFA enforcement:

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyAllExceptListedIfNoMFA",
            "Effect": "Deny",
            "NotAction": [
                "iam:CreateVirtualMFADevice",
                "iam:EnableMFADevice",
                "iam:GetUser",
                "iam:ListMFADevices",
                "iam:ListVirtualMFADevices",
                "iam:ResyncMFADevice",
                "sts:GetSessionToken"
            ],
            "Resource": "*",
            "Condition": {
                "BoolIfExists": {
                    "aws:MultiFactorAuthPresent": "false"
                }
            }
        }
    ]
}

    This policy explicitly denies all API calls, except the ones that are mentioned in the NotAction policy element if the IAM entity is not authenticated with MFA..

  3. Make sure that your policy meets all of the required conditions. If your policy has multiple condition operators or multiple keys, AWS evaluates the conditions with AND logic. Each condition context key must be used in separate statements to get the same AND logic. This is an example of a common issue that causes the API call to fail:

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowRunInstancesWithRestrictions",
            "Effect": "Deny",
            "Action": [
                "ec2:CreateVolume",
                "ec2:RunInstances"
            ],
            "Resource": [
                "arn:aws:ec2:*:*:volume/*",
                "arn:aws:ec2:*:*:instance/*"
            ],
            "Condition": {
                "ForAllValues:StringNotLike": {
                    "aws:TagKeys": "Production"
                },
                "StringEquals": {
                    "ec2:InstanceType": "t2.micro"
                }
            }
        }
    ]
}

    To avoid an explicit deny access error for these API calls, make sure that you fulfill the condition.
    Note: The aws:TagKeys condition is case sensitive.

Resource-based policies

The resource-based policy allows or denies access to a resource. Unlike IAM identity-based policies which are unified, services design resource-based policies. The following troubleshooting steps use Amazon Simple Storage Service (Amazon S3) resource-based policies and a VPC endpoint policy as examples.

S3 bucket policy evaluation

Amazon S3 Bucket policy evaluation works as follows:

  • To access a bucket in the same account, an IAM entity needs permissions in the IAM identity-based policy OR bucket policy.
  • To access a bucket in a different account, an IAM entity needs permissions in the bucket policy AND the IAM identity-based policy to gain access.

Note: This assumes that the bucket ACL is set as default.

  1. Check for deny statements in the resource-based policy. This example shows a deny statement in the bucket policy:

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Principal": {
                "AWS": "arn:aws:iam::444455556666:role/Role"
            },
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::example-bucket"
        }
    ]
}

  2. Check that the ARNs in your policy are correct.

  3. The bucket policy denies access if the aws:userid of the current user does not equal what you define in the policy. See this example:

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::example-bucket",
                "arn:aws:s3:::example-bucket/*"
            ],
            "Condition": {
                "StringNotLike": {
                    "aws:userid": [
                        "AROAEXAMPLEID:*",
                        "AIDAEXAMPLEID",
                        "444455556666"
                    ]
                }
            }
        }
    ]
}

VPC Endpoint

A VPC endpoint policy is an IAM resource policy that is attached to an endpoint. This policy doesn't override or replace the IAM user policies or service-specific policies, such as S3 bucket policies.

There are two ways to control access to your Amazon S3 data when you use an interface endpoint to connect to Amazon S3:

  • You can control the AWS principals (AWS accounts, IAM users, and IAM roles) that can use the VPC endpoint to access the endpoint service
  • You can control the VPCs or VPC endpoints that have access to your buckets with Amazon S3 bucket policies

This example below is an Amazon S3 bucket policy. The policy restricts access to a specific bucket, called example-bucket, from the VPC endpoint with the ID vpce-1a2b3c4d. The policy denies all access to the bucket if you don't use the specified endpoint. The aws:SourceVpce condition specifies the endpoint.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AccessSpecificVPCEOnly",
            "Principal": "*",
            "Action": "s3:*",
            "Effect": "Deny",
            "Resource": [
                "arn:aws:s3:::example-bucket",
                "arn:aws:s3:::example-bucket/*"
            ],
            "Condition": {
                "StringNotEqualsIfExists": {
                    "aws:SourceVpce": "vpce-1a2b3c4d"
                }
            }
        }
    ]
}

Always check that the VPC endpoint doesn't explicitly deny access to the resource.

Permissions boundary

The permissions boundary is a managed policy that sets the maximum permissions that an identity-based policy can grant to an IAM entity. This managed policy can restrict permissions to entities, which might result in explicit deny error messages.

This example shows an action that the IAM policy allows but the permissions boundary explicitly denies. See the permissions boundary below:

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

The user has the following permissions:

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

Although the user has the RunInstances permission, they receive an explicit deny message when they request it. To resolve this error, make sure that your permissions boundary and IAM policy both explicitly allow this action.

Service control policies

A service control policy (SCP) allows you to manage permissions in your organization. The following example shows a deny statement in the SCP. In this example, the SCP is attached to a member account or to a particular Organization Unit (OU). It explicitly denies access to the RunInstances action:

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

To resolve explicit deny errors, detach the service control policies (SCPs) from the account. Or, add a condition to the deny statement to exclude some use case.

For example, the SCP in this example doesn't deny ec2:RunInstances if the IAM principal uses the role ExampleCloudOps:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "ec2:RunInstances",
            "Resource": "*",
            "Condition": {
                "ArnNotLike": {
                    "aws:PrincipalARN": "arn:aws:iam::444455556666:role/ExampleCloudOps"
                }
            }
        }
    ]
}

Resource control policies

Resource control policies (RCPs) allow you to centrally control the maximum available permissions for resources in your organization. RCPs are supported on the following resource types:

  • Amazon S3
  • AWS Security Token Service
  • AWS Key Management Service
  • Amazon SQS
  •  AWS Secrets Manager
  •  Amazon Elastic Container Registry
  • Amazon OpenSearch Serverless

In this example, you attach the RCP to an Organization Unit (OU) or a member account. It explicitly denies DeleteObject action on all S3 buckets:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:DeleteObject",
            "Resource": "*"
        }
    ]
}

To resolve explicit deny errors, detach the Resource control policies (RCPs) from the account. Or, add a condition to the deny statement to exclude some use case.

For example, the RCP in this example doesn't deny ec2:RunInstances if the IAM principal uses the role ExampleCloudOps:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "ec2:RunInstances",
            "Resource": "*",
            "Condition": {
                "ArnNotLike": {
                    "aws:PrincipalARN": "arn:aws:iam::444455556666:role/ExampleCloudOps"
                }
            }
        }
    ]
}

Session policies

Session policies are advanced policies that you pass as a parameter when you programmatically create a temporary session for a role or user. You can create a role session, and pass session policies with the AssumeRole, AssumeRoleWithSAML, or AssumeRoleWithWebIdentity API operations.

For example this policy generates the explicit deny error when the user tries to make a RunInstances API call. Always check for deny statements in the session policy:

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

Related information

How to use service control policies to set permission guardrails across accounts in your AWS Organization

Permissions boundaries for IAM entities

How to restrict Amazon S3 bucket access to a specific IAM role

AWSSupport-TroubleshootIAMAccessDeniedEvents

Topics
Security, Identity, & Compliance
Tags
AWS Identity and Access Management
Language
English
AWS OFFICIALUpdated 6 months ago
No comments

Relevant content