I Tried Protecting Accounts I Don't Want Delegated Administrators of IAM Identity Center to Touch Using SCPs
This page has been translated by machine translation. View original
Introduction
Are you using IAM Identity Center delegated administrators?
It is a feature that allows you to delegate only Identity Center management to a separate member account in order to restrict access to the management account.
I had set up a configuration where Identity Center operations were delegated to a delegated administrator, but there were cases where I wanted to deny access from Identity Center to only certain accounts.
The delegated administrator can basically assign Permission Sets to all accounts other than the management account.
So I tried using SCPs to prevent the delegated administrator from creating access rights to accounts that I didn't want them to touch.
Assumed Configuration
Let me first organize the accounts involved.
| Name | Role |
|---|---|
| Management Account | The AWS Organizations management account. The Identity Center instance is also here. Referred to as the management account hereafter |
| Delegated Account | The account to register as the Identity Center delegated administrator. Isolated in a dedicated OU |
| Protected Account | Accounts that the delegatee should not be able to touch |
| Member Account | Regular accounts where the delegatee is free to assign Permission Sets |
Protected accounts are defined as accounts not managed by Identity Center. (No account assignment creation is allowed)
Other prerequisites:
- Identity Center uses an organization instance
- The delegated account is isolated in a dedicated OU (referred to here as
IdcOU), and an SCP is attached to the OU - The Identity Center identity source is the Identity Center directory. Users and groups are managed directly within Identity Center
Here is a diagram of the structure.
The principal ARN of the user varies in format depending on the method. The exclusion conditions in the SCP are written with this format in mind.
| Method | Principal ARN |
|---|---|
| IAM user + switch role | arn:aws:iam::<account>:role/<management role name> |
| Identity Center user | arn:aws:iam::<account>:role/aws-reserved/sso.amazonaws.com/<region>/AWSReservedSSO_<PS name>_<hash> |
Whether the region portion is included in the AWSReservedSSO_ role ARN depends on the region of the identity source.
There are already detailed articles on this topic, so please refer to those.
SCP to Dedicate the Delegated Account to Identity Center
First, we restrict the delegated account so that it cannot be used for anything other than managing Identity Center.
This is an allowlist-type SCP that combines Deny and NotAction.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyAllOutsideIdentityCenter",
"Effect": "Deny",
"NotAction": [
"sso:*",
"sso-directory:*",
"identitystore:*",
"identitystore-auth:*",
"identity-sync:*",
"sso-oauth:*",
"organizations:Describe*",
"organizations:List*",
"iam:Get*",
"iam:List*",
"sts:GetCallerIdentity",
"access-analyzer:ValidatePolicy",
"signin:CreateTrustedIdentityPropagationApplicationForConsole",
"signin:ListTrustedIdentityPropagationApplicationsForConsole",
"ds:Describe*"
],
"Resource": "*",
"Condition": {
"ArnNotLike": {
"aws:PrincipalArn": [
"arn:aws:iam::*:role/ops-*"
]
}
}
}
]
}
This denies any actions not listed in NotAction, while the Condition excludes the operations-side roles.
Since these two are evaluated with AND, the behavior is: "deny if a principal that does not match the exclusion condition calls an action not in the allowlist."
Since I haven't exhaustively covered every screen of the Identity Center console, there may be missing actions depending on the features you use.
SCP to Deny Assignments to Protected Accounts
Now for the main topic. We delegate Identity Center management to the delegatee, but we prevent them from creating assignments to protected accounts.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyAssignmentToProtectedAccounts",
"Effect": "Deny",
"Action": [
"sso:CreateAccountAssignment",
"sso:DeleteAccountAssignment",
"sso:ProvisionPermissionSet"
],
"Resource": [
"arn:aws:sso:::account/111122223333",
"arn:aws:sso:::account/444455556666"
],
"Condition": {
"ArnNotLike": {
"aws:PrincipalArn": [
"arn:aws:iam::*:role/ops-*"
]
}
}
}
]
}
In Resource, specify the protected accounts in the format arn:aws:sso:::account/<account-id>.
Since the management account already cannot be assigned to by the delegated administrator, it does not need to be specified here and will be denied regardless.
The assumption is that there are no existing assignments to the protected accounts.
Even so, sso:ProvisionPermissionSet is also denied to prevent re-provisioning from Permission Set edits in case any assignments remain.
Restricting via the Permission Set Policy Is Not Enough
Another approach would be to implement the same restriction using inline policies on Permission Sets.
This would involve writing "do not assign to this account" inside the Permission Sets given to the delegated administrator.
However, this approach does not work.
Since the delegated administrator has sso:*, they can use sso:PutInlinePolicyToPermissionSet to edit their own Permission Set and remove the restriction.
The AWS Security Blog also mentions that granting the ability to edit all Permission Sets means the delegated administrator can also edit their own Permission Sets.
By using an SCP to directly specify and deny resource ARNs, the delegated administrator cannot modify the SCP itself, so it cannot be tampered with.
Let's Verify
Once the policy is written, let's actually test it.
First, create the SCP in the management account and attach it to the OU where the delegated account is isolated.
aws organizations create-policy \
--name DenyAssignmentToProtectedAccounts \
--type SERVICE_CONTROL_POLICY \
--content file://scp-protected-accounts.json \
--profile management
aws organizations attach-policy \
--policy-id p-xxxxxxxx \
--target-id ou-xxxx-xxxxxxxx \
--profile management
Next, create a verification IAM role in the delegated account.
Choose a name that does not match the exclusion condition. Here we use VerifyRole.
aws iam create-role \
--role-name VerifyRole \
--assume-role-policy-document file://trust-policy.json \
--profile delegated-admin
aws iam attach-role-policy \
--role-name VerifyRole \
--policy-arn arn:aws:iam::aws:policy/AdministratorAccess \
--profile delegated-admin
Attaching AdministratorAccess is intentional.
By granting full IAM permissions, when access is denied, we can isolate the cause as being the SCP.
Since SCPs cannot be overridden even with AdministratorAccess, this approach is valid.
Before testing the assignment, retrieve the Identity Center instance ARN from the management account.
Specify the region where Identity Center is enabled.
> aws sso-admin list-instances --region ap-northeast-1 --profile management
{
"Instances": [
{
"InstanceArn": "arn:aws:sso:::instance/ssoins-xxxxxxxxxxxxxxxx",
"IdentityStoreId": "d-xxxxxxxxxx",
"OwnerAccountId": "999988887777",
"Status": "ACTIVE"
}
]
}
Next, assume the VerifyRole created in the delegated account.
aws sts assume-role \
--role-arn arn:aws:iam::777788889999:role/VerifyRole \
--role-session-name verify \
--profile delegated-admin
After exporting the returned temporary credentials as environment variables, call the assignment to the protected account.
Set --region to match the region where Identity Center is enabled.
export AWS_ACCESS_KEY_ID=<AccessKeyId>
export AWS_SECRET_ACCESS_KEY=<SecretAccessKey>
export AWS_SESSION_TOKEN=<SessionToken>
> aws sso-admin create-account-assignment \
--instance-arn arn:aws:sso:::instance/ssoins-xxxxxxxxxxxxxxxx \
--target-id 444455556666 \
--target-type AWS_ACCOUNT \
--permission-set-arn arn:aws:sso:::permissionSet/ssoins-xxxxxxxxxxxxxxxx/ps-xxxxxxxxxxxxxxxx \
--principal-id xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \
--principal-type USER \
--region ap-northeast-1
An error occurred (AccessDeniedException) when calling the CreateAccountAssignment operation:
User: arn:aws:sts::777788889999:assumed-role/VerifyRole/verify is not authorized to perform:
sso:CreateAccountAssignment on resource: arn:aws:sso:::account/444455556666
with an explicit deny in a service control policy:
arn:aws:organizations::999988887777:policy/o-xxxxxxxxxx/service_control_policy/p-xxxxxxxx
It was denied as intended.
Summary
With a two-layer configuration consisting of an SCP that restricts the delegated account exclusively to Identity Center, and an SCP that denies assignments to protected accounts, we were able to narrow the scope of what the delegatee can do.
By placing the restriction in the SCP rather than in Permission Set inline policies, the configuration cannot be bypassed by the delegated administrator.
However, this configuration is built on the premise that "there are zero assignments to the protected accounts."
If group assignments remain in a protected account, the delegated administrator can still gain access simply by adding users to that group.
The following article is helpful for restricting group member additions.
Please use this as a reference when AWS accounts arise that you want to exclude from Identity Center access.
That's all from Suzuki Jun.
References
- Delegated administration - AWS IAM Identity Center
- Delegate permission set administration - AWS IAM Identity Center
- Service control policies (SCPs) - AWS Organizations
- AWS global condition context keys - AWS Identity and Access Management
- AWS managed policies for AWS IAM Identity Center
- Delegating permission set management and account assignment in AWS IAM Identity Center | AWS Security Blog
- AWS SSO の管理委任機能を利用した際に委任先アカウントでできない事を整理してみた
- Identity Center でメンバー追加可能なグループを特定のグループに絞りたい
- AWS IAM Identity Center の特定の許可セットに対応するロールだけを SCP の Deny 対象から除外するときの ARN 指定方法
