This interesting policy question on re:Post about how you can prevent principals outside of an AWS organization from assuming a role in your organization. The asker originally requests an SCP to do this, but SCPs cannot apply to principals outside the organization so cannot fulfil this scenario.
The top voted answer proposes an IAM role resource policy (aka. trust policy) rather than an SCP:
{
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringNotEquals": {
"aws:PrincipalOrgId": "${aws:ResourceOrgId}"
},
"BoolIfExists": {
"aws:PrincipalIsAWSService": "false"
}
}
}
This resource policies denies all principals the ability to assume the role it is attached to if the principal's organization ID is not the same as the resource's organization ID, and only if the principal is not an AWS service principal.
I don't think the aws:PrincipalIsAWSService
is strictly required, but if the role is going to be used by an AWS service, then it should be included; an AWS service does not have a aws:PrincipalOrgId
as per the docs, so will always trigger the StringNotEquals
condition:
This key is included in the request context only if the principal is a member of an organization
But why?
While this is a valid approach, I'm not sure it's worth the effort - the only way this policy has an impact is if you've explicitly granted sts:AssumeRole
to principals outside of your organization in the first place; if you're doing that, you should be only granting the action for the specific roles (via the Resources
property of the relevant policy) that should be allowed.