# Ensure custom IAM policies do not allow role assumption on wildcard resources

- Source: https://support.icompaas.com/support/solutions/articles/a_1793292211625303-ensure-custom-iam-policies-do-not-allow-role-assumption-on-wildcard-resources
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [AWS_Checks_v5.39.1](https://support.icompaas.com/support/solutions/c_1793285913477877) › [AWS Checks](https://support.icompaas.com/support/solutions/folders/f_1793287194371224)
- Last updated: 2026-10-29
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

**Description**

Ensure that no customer managed IAM policy contains an Allow statement that grants sts:AssumeRole, sts:\* or \* on a resource with a wildcard, such as "Resource": "\*" or arn:aws:iam::<ACCOUNT\_ID>:role/\*. Role assumption permissions should be limited to the specific role ARNs that each identity needs.

**Rationale**

Broad sts:AssumeRole permissions let a user or role obtain temporary credentials for any role whose trust policy allows it, including roles in other accounts. This can be used for privilege escalation and lateral movement, and puts the confidentiality and integrity of data and of the account configuration at risk. Limiting the Resource element to exact role ARNs, requiring MFA (and an external ID for third parties), using permissions boundaries and SCPs, and regularly removing unused role-assumption rights apply least privilege.

**Impact**

-   Prevents identities from assuming roles they do not need
    
-   Reduces the risk of privilege escalation and cross-account lateral movement
    
-   Users, applications or roles that assume roles not listed in the updated policy will receive access denied errors
    
-   Updating a policy affects every user, group and role it is attached to
    

**Default Value**

No customer managed policies exist by default. Permissive role assumption exists only if a custom policy with such a statement was created.

**Pre-Requisites**

-   IAM permissions: iam:ListPolicies, iam:GetPolicyVersion, iam:ListPolicyVersions, iam:CreatePolicyVersion, iam:DeletePolicyVersion and iam:SetDefaultPolicyVersion
    
-   A list of the exact role ARNs that each identity using the policy needs to assume
    

**Remediation**

**Test Plan**

**Console:**

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Open the IAM console and select **Policies** in the left menu.
    
3.  Filter the list by type **Customer managed** and open each policy that is attached to at least one identity.
    
4.  On the **Permissions** tab, view the policy JSON.
    
5.  Check for any statement with "Effect": "Allow" whose Action includes sts:AssumeRole, sts:\* or \* and whose Resource contains a \*.
    
6.  If such a statement exists, follow the implementation steps.
    

**CLI:**

List the customer managed policies that are attached to at least one identity:

aws iam list-policies --scope Local --only-attached --query "Policies\[\].\[PolicyName,Arn,DefaultVersionId\]" --output table

Show the document of a policy:

aws iam get-policy-version --policy-arn <POLICY\_ARN> --version-id <VERSION\_ID> --query "PolicyVersion.Document"

A policy fails if any Allow statement has sts:AssumeRole, sts:\* or \* in Action and a Resource value that contains \*. Unattached customer managed policies are not evaluated.

**Implementation Steps**

**Console:**

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Open the IAM console and select **Policies** in the left menu.
    
3.  Select the customer managed policy found in the Test Plan and choose **Edit**.
    
4.  Open the **JSON** editor and find each Allow statement that grants sts:AssumeRole, sts:\* or \* on a wildcard resource.
    
5.  Replace the Resource value with the specific role ARNs, for example arn:aws:iam::<ACCOUNT\_ID>:role/<ROLE\_NAME>. If the statement uses \* as the action, move sts:AssumeRole into a separate statement scoped to these roles.
    
6.  Choose **Next**, then **Save changes** to create the new default version.
    
7.  Repeat for each affected policy.
    

**CLI:**

Save the corrected policy document as policy.json, including all other statements the policy still needs:

{"Version":"2012-10-17","Statement":\[{"Effect":"Allow","Action":"sts:AssumeRole","Resource":\["arn:aws:iam::<ACCOUNT\_ID>:role/<ROLE\_NAME>"\]}\]}

Create a new default version of the policy. A policy can have at most 5 versions, so delete an old non-default version first if needed:

aws iam create-policy-version --policy-arn <POLICY\_ARN> --policy-document file://policy.json --set-as-default

**Backout Plan**

Before making changes, note the current default version of the policy:

aws iam list-policy-versions --policy-arn <POLICY\_ARN> --query "Versions\[\].\[VersionId,IsDefaultVersion,CreateDate\]" --output table

To roll back:

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Open the IAM console, select **Policies** and open the policy.
    
3.  Select the **Policy versions** tab.
    
4.  Select the previous version and choose **Set as default**.
    

**CLI:**

aws iam set-default-policy-version --policy-arn <POLICY\_ARN> --version-id <PREVIOUS\_VERSION\_ID>

Note: rolling back allows the identities using the policy to assume any role again.

**Reference**

-   [https://docs.aws.amazon.com/IAM/latest/UserGuide/id\_roles\_use\_permissions-to-switch.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_permissions-to-switch.html)
    
-   [https://docs.aws.amazon.com/STS/latest/APIReference/API\_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)
    
-   [https://docs.aws.amazon.com/IAM/latest/UserGuide/access\_policies\_managed-versioning.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-versioning.html)
    
-   [https://docs.aws.amazon.com/cli/latest/reference/iam/create-policy-version.html](https://docs.aws.amazon.com/cli/latest/reference/iam/create-policy-version.html)

## Related compliance guidance

- [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them.
- [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.