The content below is taken from the original ( Automating IAM Roles For Cross-Account Access Series Overview), to continue reading please visit the site. Remember to respect the Author & Copyright.
The AWS Partner Network Blog has recently published a series describing a method to automate the creation of an IAM role for cross-account access, and how to collect the information needed for a partner to assume the role after creation. This post gives readers an overview of the series, summarizing each of the individual posts with links back to the original content for further reading.
As a reminder, cross-account IAM roles allow customers to grant access to resources within their account to a partner or other third parties while enabling the customers to maintain their security posture. Cross-account roles allow the customer to delegate access without the need to distribute key material, and without the burden on the third party to safely handle key material after receipt.
The blog series kicked off with a post that explained how to create a custom launch stack URL for AWS CloudFormation. The URL will take users directly to the CloudFormation Create Stack wizard, with values for the Amazon S3 template location, stack name, and default parameters already populated. The launch stack URL eliminates the need to exchange template files with the customer, and ensures that the customer is using the proper template with the correct values.
The second post describes how to use an AWS Lambda function to populate a AWS CloudFormation template with uniquely generated values. The series example uses an External ID, an ID that is unique for each end user. This value needs to be set within the CloudFormation template. When triggered, the Lambda function pulls down the default template, inserts a generated unique External ID into the template, and uploads the customized template to an S3 bucket. Once the template upload is complete, the end user is presented with a custom launch stack URL containing the unique template Amazon S3 location. Finally, we demonstrated how to use the Launch Stack icon to make the URL more visible to users.
The third post details how to reliably return the Amazon Resource Name (ARN) of the cross-account role created by AWS CloudFormation to a third party. As a reminder, the third party must use the ARN, as well as the ExternalID, when assuming the role in the end user’s account. The post demonstrates a CloudFormation custom resource designed to send the ARN back to the third-party account, which consumes the ARN and stores it for later use.
The final post of the series brings the details of the previous three blog posts together into one cohesive solution. It shows how to implement the automation of cross-account role creation for customer onboarding using the techniques described in each post in a completed workflow. The workflow creates a smoother onboarding experience for the customer while creating a secure way for the third party account to create resources within the customer account.
We hope that the blog series can help you and your company improve your customer on-boarding experience. You can avoid the sharing of sensitive keys and the error-prone approach of requiring your customers to cut and paste information in their account and your on-boarding portal.
About the Author
Erin McGill is a Solutions Architect in the AWS Partner Program with a focus on DevOps and automation tooling.