AWS Cloud Operations & Migrations Blog
Simplifying Self Service with AWS Service Catalog Principal Name Sharing
Many of our customers use AWS Service Catalog for governance of their infrastructure as code (IaC) templates and self-service provisioning for a variety of use cases, from customizing multi-account environments to launching data science and development workloads. The self-service use case becomes very appealing when customer need to scale across an organization with tens to thousands of team members. Users benefit from pre-configured solutions that are easy to launch. At the same time, administrative teams benefit from end user access management and solution governance at scale.
In order to enable this self-service capability across their organization, a central cloud team can build a repeatable solution into an AWS Service Catalog product based on well-architected and security best practices. Solutions that are constantly being used either by multiple users or within other solutions are often good candidates for product creation (Ex. Amazon VPCs, Amazon WorkSpaces, databases and more). After this, the products can be organized into a logical collection of products known as a AWS Service Catalog portfolio to be distributed across multiple accounts.
With the recent launch of principal name sharing, sharing self-service products at scale has become even simpler for organizations. Previously, administrators would have to take steps in each account to grant access to AWS Service Catalog portfolios for their users and teams. When operating with thousands or even a few accounts, this can be challenging. But now, with principal name sharing, administrators can associate an IAM role, group, or user to a portfolio right at the time of share.
Figure 1. Share a Service Catalog portfolio to accounts and Organizational Units
Share a AWS Service Catalog portfolio to accounts and Organizational Units
In this blog post, we will share the end-to-end process to distribute AWS Service Catalog products at scale within your organization: Creating a AWS Service Catalog portfolio with CDK, assigning users and teams, and sharing it out in a multi-account environment. Let’s get started!
Solution Overview
AWS Service Catalog supports two personas: An addministrator and an end user. As an AWS Service Catalog administrator, we will create a portfolio named the DevTools Portfolio. In the real world, developers (end users) may have access to a variety of products in this portfolio, including CI/CD pipelines, pre-configured databases, and development tools like AWS Cloud9. For this blog post, we will create a single AWS Service Catalog product to deploy an S3 bucket with a name of ‘S3Product’ appended to random characters.
We will share the DevTools portfolio to two organizational units (OUs), Workloads and Sandbox, meaning all accounts under these OUs will receive the portfolio. Each of these accounts is expected to contain an IAM role named ‘Development’. With Principal Name Sharing, an administrator can now associate principal names with the portfolio. Principal names are names for IAM groups, roles and users. An administrator can choose to share the portfolio to an entire AWS Organization, specific OUs, or the AWS Organization member accounts. When sharing takes place, the principal names will be shared along with the portfolio to the recipient accounts. In this case, we will associate the IAM role name, Development, to the DevTools portfolio. If the associated principal name of ‘Development’ matches with an existing role name in each account, developers will be able to access and launch products from the DevTools portfolio in both the Sandbox and Workloads OUs.
Figure 2. Administrator builds out the Service Catalog DevTools portfolio and enables principal name sharing
Figure 3. Developers are able to launch the Amazon S3 product from the AWS Service Catalog portfolio
Prerequisites
• AWS Control Tower – refer to the Control Tower Workshop to setup a multi-account environment
• AWS CLI
• Node.js
• AWS CDK Toolkit
• Python
Solution Walk Through:
Create Organizational Units and Accounts
Using AWS Control Tower, we created a multi-account structure with an ‘Infrastructure’ OU, ‘Sandbox’ OU and ‘Workloads’ OU. This aligns with our multi-account strategy guidance. Developers will use the ‘Sandbox’ OU for testing and experiments while the ‘Workloads’ OU hosts the organization’s applications.
Step 1: Create an OU called ‘Infrastructure’ OU
Step 2: Create a ‘Shared Services’ account using AWS Control Tower’s Account Factory under the Infrastructure OU. This becomes the delegated admin account to host the AWS Service Catalog portfolio
Step 3: Create a ‘Sandbox’ OU and a ‘Workloads’ OU with a few accounts.
Step 4: Note: Add the ‘Development’ IAM role with appropriate permissions to each account under the Sandbox and Workloads OUs.
Figure 4. Account Architecture with Infrastructure, Sandbox and Workloads OU
Build AWS Service Catalog Portfolio and Product with CDK
Step 1: Configure the AWS CLI with the Delegated Admin account access key ID and secret access key. You can refer https://docs.aws.amazon.com/cli/latest/userguide/getting-started-quickstart.html for detailed instructions
Step 2: Create an empty directory on your system. Use same name for the folder
Step 3: Create new Python CDK project
Step 4: pip install -r requirements.txt
Step 5: Copy the cdk_sc_sample_stack.py file content from the GitHub repository.
Open cdk_sc_sample/cdk_sc_sample folder and replace cdk_sc_sample_stack.py file contents with the copied code.
This code sample creates an AWS Service Catalog portfolio with a single AWS Service Catalog product for Amazon S3.
Step 6: If you are deploying AWS CDK app for the first time in your environment (Account/Region), you need to bootstrap to install all resources the toolkit would need. Read more on bootstrapping with CDK here.
The output will look like:
Step 7: Deploy the application
It takes a few minutes to create the resources.
Step 8: Navigate to AWS Service Catalog Console . You will see below DevTools portfolio with a product called ‘S3CDKStack’
Figure 5. DevTools portfolio with an AWS Service Catalog product called ‘S3CDKStack’
Associate the Principal Name with the AWS Service Catalog portfolio
Step 1: Navigate to the AWS Service Catalog Console. Select the portfolio DevTools, click on the Access tab and then the Grant Access button.
Figure 6. Click on the “Access” tab and then the “Grant Access” button.
Step 2: Choose the radio button “Principal Name”, select Type as role, specify the name as ‘Development’ as shown below and then click on “Grant Access” button
Figure 7. Specify a Principal Name of type role as ‘Development’
Share Portfolio with Organizational Unit
Step 1: We will select the ‘Shared Services’ account under the ‘Infrastructure’ Organizational Unit to be the delegated administrator account for AWS Service Catalog. Execute the following command from management account.
Step 2: In the ‘Shared Services’ account, navigate to AWS Service Catalog Console. Open the portfolio DevTools, click on the Share tab
Figure 8. Click on the “Share” tab to share the portfolio.
Step 3: First, choose the radio button Organization Node and select AWS Organization. When you do this, you should see the list of available Organizational Units from your multi-account environment.
From here, we can select the appropriate organizational units to share the portfolio with. In this case, we will share the DevTools portfolio to both the ‘Sandbox’ OU and the ‘Workloads’ OU. Check the check box “Principal sharing”.
Figure 9. Select the appropriate OU you will share the portfolio to.
Figure 10. Check the check box “Principal Sharing”
This completes the share of the AWS Service Catalog portfolios with principal name sharing from the administrative perspective.
Launch AWS Service Catalog Product – Developer (End User)
When developers login into the Sandbox and Workloads OU, they can assume the ‘Development’ IAM role to launch the S3CDKStack product.
Figure 11. The developer will be able to view a “Launch product” button if they have permissions to assume the “Development” IAM role.
Further Notes
If an admin, in the ‘Shared Services’ account, removes the principal name ‘Development’ from the portfolio ‘DevTools’, AWS Service Catalog applies those changes and automatically disassociates the ‘Development’ IAM role from the portfolio ‘DevTools’ in both the ‘Sandbox’ OU and ‘Workload’ OU. The users with the ‘Development’ IAM role will then no longer be able to access the ‘DevTools’ portfolio and its products. However, the AWS Service Catalog portfolio will remain shared to the member accounts till the administrator also decides to delete the organization share.
Conclusion
We showed here how you can simplify your operation and scale across a multi-account environment using Principal Name Sharing to distribute your cloud patterns. This will enable your central administrative teams to ensure your end users are not just being more efficient and productive, but are also following your organization’s security and governance best practices.
About the authors: