A role in account A can be assumed by principals in an account the company does not own. The trust policy's Principal lists that foreign account. Security thought a NACL was the cause. Where is the mistake?
Select an answer to reveal the explanation.
Short Explanation
Who may assume a role is written on the role, in the trust policy. You left a foreign account on that list. A NACL cannot grant AssumeRole, so you take the foreign principal off the trust policy.
Full Explanation
A role trust policy is the resource policy that decides who may call AssumeRole. A Principal set to a foreign account allows that account's identities to assume the role if their own policies also allow it. That is the mistake, and it is visible on the role. A NACL does not grant IAM trust. Alarm dimensions and lifecycle rules do not assume roles. Access Analyzer will also flag this trust as external access, which is a useful confirmation and not a different root cause. Caveat: an external id condition is appropriate when a known partner must assume the role; a blanket account principal with no condition is what to remove here. Operational check: the trust policy should list only your account or your identity provider, and a new Access Analyzer scan should clear the external assume-role finding. Open the role and read the trust relationship. The Principal element should be your account, your organization, or your identity provider. A foreign account id there is the bug. Access Analyzer will flag the role as externally assumable, which confirms the trust policy and does not point at a NACL. Remove the foreign principal, and if a partner must remain, require an external id. A new assume-role from that account should then fail.