Background
We're using IAM Identity Center, previously called AWS SSO, to manage the permissions and user mapping centrally. The permissionset is a function provided by AWS IAM Identity Center. This function will provision the role inside the organization so that the user can easily assume the role via other SSO services.
However, we found there is no way to control the permissionsets and organization unit mapping. This means the admin can accidentally assign the wrong permissionsets to users. We treat it as a security risk for us.
Below is a diagram of organization unit and permissionsets mapping:
- Administrators will accidentally assign the wrong permission for the wrong users.
- Nothing to validate and check if the permissionsets are suitable for the account. In a big company, it will be difficult to maintain so many permissionsets.
Why SCP Does Not Work.
The very first thing that came into my mind for organization restriction is SCP(Service Control Policies). But why this will not work?
The reason is as follows:
- The permissionset assignment happened in the Management account, not in the child OU itself.
- The SCP restricts only the account action in the OU level, but all the actions happened in one account. Actions cannot be split to different levels.
Restrict via Permission Boundary
This is a permission boundary to restrict user not act outside his own OU. Actually, each permissionset means a role inside different accounts. Then it makes sense to create permission boundary for the permissionset.
An inline policy appended to the permissionset:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"ForAnyValue:StringNotLike": {
"aws:PrincipalOrgPaths": ["<organization-id>/<ou-id>/"]
}
}
}
]
}
Quick Explanation:
- Deny all actions when met the condition.
- If "aws:PricipalOrgPaths" does not equal the one we defined, then action rejected.
- This actually has the same meaning of "allow only" when the organization is what we defined.
Top comments (0)