IAM Managed Policy DescribeInstances Auditor

Threat/Impact Level: HIGH | Exploitability/Downtime Risk: HIGH | Time to Fix: 5–15 mins

TL;DR

• What broke: An explicit Deny in an SCP, permission boundary, or inline policy is overriding the AdministratorAccess managed policy. In AWS IAM, explicit Deny always wins — AdministratorAccess is not a trump card.
• How to fix it: Locate the conflicting explicit Deny using aws iam simulate-principal-policy and either remove it, scope it correctly with conditions, or adjust the permission boundary to allow ec2:DescribeInstances.
• Fast path: Use our Client-Side Sandbox above to auto-refactor this — paste your policy JSON and let it pinpoint the conflicting statement without sending your ARNs to a third-party server.

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

// Or via CLI:
An error occurred (AccessDenied) when calling the DescribeInstances operation:
User: arn:aws:iam::123456789012:user/dev-user is not authorized to perform:
ec2:DescribeInstances because no identity-based policy allows the ec2:DescribeInstances action

How to Fix It

Step 0: Diagnose First

Run the policy simulator before touching anything:

aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:user/dev-user \
  --action-names ec2:DescribeInstances \
  --resource-arns "*"

The output will show DENY with MatchedStatements identifying the exact policy and statement ID causing the block. Read this output before proceeding.

Basic Fix: Remove or Correct the Explicit Deny

If the denial is in an inline policy or managed policy attached directly to the user:

{
  "Version": "2012-10-17",
  "Statement": [
-   {
-     "Sid": "DenyEC2",
-     "Effect": "Deny",
-     "Action": "ec2:*",
-     "Resource": "*"
-   }
+   {
+     "Sid": "DenyDestructiveEC2Only",
+     "Effect": "Deny",
+     "Action": [
+       "ec2:TerminateInstances",
+       "ec2:DeleteVolume",
+       "ec2:DeleteSnapshot"
+     ],
+     "Resource": "*"
+   }
  ]
}

Fix: SCP at AWS Organizations Level

If simulate-principal-policy points to an SCP, you must fix it in AWS Organizations → Policies, not in IAM:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RestrictEC2Actions",
      "Effect": "Deny",
-     "Action": "ec2:*",
+     "Action": [
+       "ec2:TerminateInstances",
+       "ec2:ModifyInstanceAttribute"
+     ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["us-east-1", "us-west-2"]
        }
      }
    }
  ]
}

Fix: Permission Boundary

If a permission boundary is set on the user/role and doesn't explicitly allow ec2:DescribeInstances, the action is denied even if AdministratorAccess allows it:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowedServices",
      "Effect": "Allow",
      "Action": [
        "s3:*",
-       "ec2:RunInstances"
+       "ec2:RunInstances",
+       "ec2:DescribeInstances",
+       "ec2:DescribeInstanceStatus",
+       "ec2:DescribeTags"
      ],
      "Resource": "*"
    }
  ]
}

Permission boundaries are whitelists, not blacklists. If ec2:DescribeInstances is not explicitly listed in the boundary, it's denied regardless of what AdministratorAccess says.

Enterprise Best Practice: Least-Privilege with Condition Keys

Don't grant blanket EC2 read. Scope describe permissions with resource tags and region conditions:

{
  "Version": "2012-10-17",
  "Statement": [
-   {
-     "Effect": "Allow",
-     "Action": "ec2:*",
-     "Resource": "*"
-   }
+   {
+     "Sid": "EC2ReadScopedByRegionAndTag",
+     "Effect": "Allow",
+     "Action": [
+       "ec2:DescribeInstances",
+       "ec2:DescribeInstanceStatus",
+       "ec2:DescribeTags",
+       "ec2:DescribeVolumes"
+     ],
+     "Resource": "*",
+     "Condition": {
+       "StringEquals": {
+         "aws:RequestedRegion": "us-east-1",
+         "aws:ResourceTag/Environment": "production"
+       }
+     }
+   }
  ]
}

💡 Tired of pasting proprietary infrastructure configs into public LLMs? Generic AI interfaces log your company's ARNs, connection strings, and private keys. StackEngine enforces client-side zero-trust boundaries—the sandbox above executes 100% locally in your browser. Drop your broken manifest above to redact secrets locally and synthesize deterministic patch drafts with your own API key.

(For CI/CD pipeline automation, install via npm i -g stackengine).

checkov -f iam_policy.json --check CKV_AWS_40,CKV_AWS_274
# CKV_AWS_274: Ensure IAM policy does not have statements with admin permissions
# CKV_AWS_40: Ensure IAM policies are attached only to groups or roles

# deny_wildcard_ec2_deny.rego
package terraform.iam

deny[msg] {
  stmt := input.resource.aws_iam_policy.policy.statement[_]
  stmt.effect == "Deny"
  stmt.actions[_] == "ec2:*"
  msg := "Blanket ec2:* Deny detected. Scope to specific destructive actions only."
}

aws configservice put-config-rule --config-rule '{
  "ConfigRuleName": "iam-no-wildcard-ec2-deny",
  "Source": {
    "Owner": "AWS",
    "SourceIdentifier": "IAM_POLICY_NO_STATEMENTS_WITH_ADMIN_ACCESS"
  }
}'

{
  "Sid": "RequirePermissionBoundary",
  "Effect": "Deny",
  "Action": ["iam:CreateRole", "iam:PutRolePolicy"],
  "Resource": "*",
  "Condition": {
    "StringNotLike": {
      "iam:PermissionsBoundary": "arn:aws:iam::*:policy/StandardDevBoundary"
    }
  }
}