Post Syndicated from Louay Shaat original https://aws.amazon.com/blogs/security/how-to-delegate-management-of-identity-in-aws-single-sign-on/
In this blog post, I show how you can use AWS Single Sign-On (AWS SSO) to delegate administration of user identities. Delegation is the process of providing your teams permissions to manage accounts and identities associated with their teams. You can achieve this by using the existing integration that AWS SSO has with AWS Organizations, and by using tags and conditions in AWS Identity and Access Management (IAM).
AWS SSO makes it easy to centrally manage access to multiple Amazon Web Services (AWS) accounts and business applications, and to provide users with single sign-on access to all their assigned accounts and applications from one place.
AWS SSO uses permission sets—a collection of administrator-defined policies—to determine a user’s effective permissions to access a given AWS account. Permission sets can contain either AWS managed policies or custom policies that are stored in AWS SSO. Policies are documents that act as containers for one or more permission statements. These statements represent individual access controls (allow or deny) for various tasks, which determine what tasks users can or cannot perform within the AWS account. Permission sets are provisioned as IAM roles in your organizational accounts, and are managed centrally using AWS SSO.
AWS SSO is tightly integrated with AWS Organizations, and runs in your AWS Organizations management account. This integration enables AWS SSO to retrieve and manage permission sets across your AWS Organizations configuration.
As you continue to build more of your workloads on AWS, managing access to AWS accounts and services becomes more time consuming for team members that manage identities. With a centralized identity approach that uses AWS SSO, there’s an increased need to delegate control of permission sets and accounts to domain and application owners. Although this is a valid use case, access to the management account in Organizations should be tightly guarded as a security best practice. As an administrator in the management account of an organization, you can control how teams and users access your AWS accounts and applications.
This post shows how you can build comprehensive delegation models in AWS SSO to securely and effectively delegate control of identities to various teams.
Solution overview
Suppose you’ve implemented AWS SSO in Organizations to manage identity across your entire AWS environment. Your organization is growing and the number of accounts and teams that need access to your AWS environment is also growing. You have a small Identity team that is constantly adding, updating, or deleting users or groups and permission sets to enable your teams to gain access to their required services and accounts.
Note: You can learn how to enable AWS SSO from the Introducing AWS Single Sign-On blog post.
As the number of teams grows, you want to start using a delegation model to enable account and application owners to manage access to their resources, in order to reduce the heavy lifting that is done by teams that manage identities.
Figure 1 shows a simple organizational structure that your organization implemented.
Figure 1: AWS SSO with AWS Organizations
In this scenario, you’ve already built a collection of organizational-approved permission sets that are used across your organization. You have a tagging strategy for permission sets, and you’ve implemented two tags across all your permission sets:
- Environment: The values for this tag are Production or Development. You only apply Production permission sets to Production accounts.
- OU: This tag identifies the organizational unit (OU) that the permission set belongs to.
A value of All can be assigned to either tag to identify organization-wide use of the permission set.
You identified three models of delegation that you want to enable based on the setup just described, and your Identity team has identified three use cases that they want to implement:
- A simple delegation model for a team to manage all permission sets for a set of accounts.
- A delegation model for support teams to apply read-only permission sets to all accounts.
- A delegation model based on AWS Organizations, where a team can manage only the permission sets intended for a specific OU.
The AWS SSO delegation model enables three key conditions for restricting user access:
- Permission sets.
- Accounts
- Tags that use the condition aws:ResourceTag, to ensure that tags are present on your permission sets as part of your delegation model.
In the rest of this blog post, I show you how AWS SSO administrators can use these conditions to implement the use cases highlighted here to build a delegation model.
See Delegating permission set administration and Actions, resources, and condition keys for AWS SSO for more information.
Important: The use cases that follow are examples that can be adopted by your organization. The permission sets in these use cases show only what is needed to delegate the components discussed. You need to add additional policies to give users and groups access to AWS SSO.
Some examples:
Identify your permission set and AWS SSO instance IDs
You can use either the AWS Command Line Interface (AWS CLI) v2 or the AWS Management Console to identify your permission set and AWS SSO instance IDs.
Use the AWS CLI
To use the AWS CLI to identify the Amazon resource names (ARNs) of the AWS SSO instance and permission set, make sure you have AWS CLI v2 installed.
To list the AWS SSO instance ID ARN
Run the following command:
To list the permission set ARN
Run the following command:
Use the console
You can also use the console to identify your permission sets and AWS SSO instance IDs.
To list the AWS SSO Instance ID ARN
- Navigate to the AWS SSO in your Region. Choose the Dashboard and then choose Choose your identity source.
- Copy the AWS SSO ARN ID.
Figure 2: AWS SSO ID ARN
To list the permission set ARN
- Navigate to the AWS SSO Service in your Region. Choose AWS Accounts and then Permission Sets.
- Select the permission set you want to use.
- Copy the ARN of the permission set.
Figure 3: Permission set ARN
Use case 1: Accounts-based delegation model
In this use case, you create a single policy to allow administrators to assign any permission set to a specific set of accounts.
First, you need to create a custom permission set to use with the following example policy.
The example policy is as follows.
This policy specifies that delegated admins are allowed to provision any permission set to the three accounts listed in the policy.
Note: To apply this permission set to your environment, replace the account numbers following Resource with your account numbers.
Use case 2: Permission-based delegation model
In this use case, you create a single policy to allow administrators to assign a specific permission set to any account. The policy is as follows.
This policy specifies that delegated admins are allowed to provision only the specific permission set listed in the policy to any account.
Note:
- In the example above, arn:aws:sso:::instance/ssoins-1111111111 is the ARN for the AWS SSO instance. To get your AWS SSO instance ID ARN, refer to Identify your permission set and AWS SSO Instance IDs.
- In the example above arn:aws:sso:::permissionSet/ssoins-1111111111/ps-112233abcdef123 is the ARN for the AWS SSO permission set. To get your AWS SSO permission set ARN, refer to Identify your permission set and AWS SSO Instance IDs.
- In the example above, arn:aws:sso:::account/* allows delegation of all accounts.
Use case 3: OU-based delegation model
In this use case, the Identity team wants to delegate the management of the Development permission sets (identified by the tag key Environment) to the Test OU (identified by the tag key OU). You use the Environment and OU tags on permission sets to restrict access to only the permission sets that contain both tags.
To build this permission set for delegation, you need to create two policies in the same permission set:
- A policy that filters the permission sets based on both tags—Environment and OU.
- A policy that filters the accounts belonging to the Development OU.
The policies are as follows.
In the delegated policy, the user or group is only allowed to provision permission sets that have both tags, OU and Environment, set to “Development” and only to accounts in the Development OU.
Note: In the example above arn:aws:sso:::instance/ssoins-11112222233333 is the ARN for the AWS SSO Instance ID. To get your AWS SSO Instance ID, refer to Identify your permission set and AWS SSO Instance IDs.
Create a delegated admin profile in AWS SSO
Now that you know what’s required to delegate permissions, you can create a delegated profile and deploy that to your users and groups.
To create a delegated AWS SSO profile
- In the AWS SSO console, sign in to your management account and browse to the Region where AWS SSO is provisioned.
- Navigate to AWS Accounts and choose Permission sets, and then choose Create permission set.
Figure 4: AWS SSO permission sets menu
- Choose Create a custom permission set.
Figure 5: Create a new permission set
- Give a name to your permission set based on your naming standards and select a session duration from your organizational policies.
- For Relay state, enter the following URL:
where <region> is the AWS Region in which you deployed AWS SSO.
The relay state will automatically redirect the user to the Accounts section in the AWS SSO console, for simplicity.
Figure 6: Custom permission set
- Choose Create new permission set. Here is where you can decide the level of delegation required for your application or domain administrators.
Figure 7: Assign users
See some of the examples in the earlier sections of this post for the permission set.
- If you’re using AWS SSO with AWS Directory Service for Microsoft Active Directory, you’ll need to provide access to AWS Directory Service in order for your administrator to assign permission sets to users and groups.
To provide this access, navigate to the AWS Accounts screen in the AWS SSO console, and select your management account. Assign the required users or groups, and select the permission set that you created earlier. Then choose Finish.
- To test this delegation, sign in to AWS SSO. You’ll see the newly created permission set.
Figure 8: AWS SSO sign-on page
- Next to developer-delegated-admin, choose Management console. This should automatically redirect you to AWS SSO in the AWS Accounts submenu.
If you try to provision access by assigning or creating new permission sets to accounts or permission sets you are not explicitly allowed, according to the policies you specified earlier, you will receive the following error.
Figure 9: Error based on lack of permissions
Otherwise, the provisioning will be successful.
Summary
You’ve seen that by using conditions and tags on permission sets, application and account owners can use delegation models to manage the deployment of permission sets across the accounts they manage, providing them and their teams with secure access to AWS accounts and services.
Additionally, because AWS SSO supports attribute-based access control (ABAC), you can create a more dynamic delegation model based on attributes from your identity provider, to match the tags on the permission set.
If you have feedback about this blog post, submit comments in the Comments section below. If you have questions about this post, start a new thread on the AWS Single Sign-On forum.
Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.