IAM roles whose trust policy lets any principal assume them

Why a wildcard principal is dangerous on a role

A role’s trust policy is a resource-based policy that says who may call sts:AssumeRole on it. Normally the Principal element names an account, a role ARN or an AWS service. Setting it to * means every principal.

The IAM reference is blunt about this. It strongly recommends against a wildcard in the Principal element of a resource-based policy with an Allow effect unless you intend public or anonymous access, and says this is especially true for role trust policies, because they allow other principals to become a principal in your account.

Reading a role’s trust policy

aws iam list-roles --query 'Roles[].RoleName' --output text

aws iam get-role --role-name my-role \
  --query 'Role.AssumeRolePolicyDocument'

Look for "Principal": "*" or "Principal": {"AWS": "*"} in any statement with "Effect": "Allow", then check whether a Condition block narrows it.

What must be recorded before this fires

ZopNight reads each role’s trust policy during discovery and records whether any Allow statement without a Condition block uses a wildcard principal: "*", {"AWS": "*"}, or a list that contains "*". The rule fires only when that record is present and true. It does not read tags, so a tag cannot trigger or suppress it.

Cases this check does not judge

If discovery could not read a role, no record exists and the rule raises nothing. A trust policy that cannot be parsed is recorded as having no wildcard.

Any statement with a Condition block is skipped, whatever the condition says, so a wildcard narrowed by aws:PrincipalOrgID or sts:ExternalId is not flagged, and neither is one with a weak condition. Deny statements and NotPrincipal are not evaluated. Review conditioned wildcards yourself; a specific principal is still the safer design.

No cost impact, maximum blast radius

This finding saves nothing. Its severity is critical because the role’s permissions, whatever they are, may be reachable by identities outside your organization. Combined with a broad permission policy (see IAM Role With AdministratorAccess Policy), it is effectively an open door.

Narrowing the trust policy

1. Identify who legitimately assumes the role, using CloudTrail AssumeRole events or the role’s last-used information from get-role.
2. Rewrite the trust policy to name those principals: specific account IDs, role ARNs or a service principal such as ec2.amazonaws.com.
3. Where a wide audience is truly needed, add a condition such as aws:PrincipalOrgID so only your organization can assume it.
4. Apply the new document:

aws iam update-assume-role-policy --role-name my-role \
  --policy-document file://trust-policy.json