Permissions Boundaries and IAM Identity Center Permissions Sets

Question

I am currently using a combination of policies and permission boundaries to create powerful yet succinct combinations of permissions for my user roles. We are migrating to SSO and using Identity Center Permission Sets to manage our roles soon, and I have run into a quirk that doesn't make sense to me.

Permission Sets seem to require that any customer managed policies, including permission boundaries, are defined in the target account, **not** in the Identity Center management account. This goes against the centrally-managed nature of Identity Center and opens us to the complexity of having to create Managed Policies in every single child account and the risk of those policies being modified by bad actors.

Is there a way to centrally manage policies, including permission boundaries, for a permission set?

Accepted Answer

The roles created in each account via AWS ID Center will be immutable within the target account console (With the nomenclature SSO*) so you won't be able to attach AWS managed or customer policies at the account level so you'll have centralized role policy assignment. For AWS Customer Managed Policies within AWS ID Center, there won't be a validation that the policy exists in the target account but when a permission set is assigned to an account that assignment will fail since you need to ensure that the custom policy exists in the target account. For AWS Managed Policies, these are ARN's assigned to the permission sets. As stated by Gary, you'll need to have an IaC process in place to centrally distribute policies to various account. For the customer managed policies you may require different levels of access between non-prod and prod so in your design you'll need to make sure you have a way of separating the two if required.

To address the risks of bad actors making changes to AWS customer managed policies, you'll need to review your design to identity which types of roles/users can make updates to these customer managed policies. Normally if you have an IaC CI/CD process in place that role will need to have permissions to make changes to accounts so that's one vector. The second vector will be administrative accounts that can make changes to IAM policies or if you have guardrails in place that only certain roles can make changes within customer's organization.

To address the risks of bad actors making changes to AWS customer managed policies, you'll need to review your design to identity which types of roles/users can make updates to these customer managed policies.  Normally if you have an IaC CI/CD process in place that role will need to have permissions to make changes to accounts so that's one vector.  The second vector will be administrative accounts that can make changes to IAM policies or if you have guardrails in place that only certain roles can make changes within customer's organization.

Answer

This is always the case. Even with identity centre. Said permissions is always controlled in the target account.

In identity centre when you create a permission set, all it does under the hood is it creates a role in the target account along with the permissions/policy on the role. It trusts the management account for role assumption. 
The management account is a central point of authentication and management of permissions in sub accounts.  The permissions for users in sub accounts are still created in the actual target accounts.

After logging into ident centre and you select an account, you assume a role in the account of choice and therefore all the permissions come from IAM still.

A way to keep it consistent could be is to use some IaC such as terraform or cloud formation.

Permissions Boundaries and IAM Identity Center Permissions Sets

Relevant content