Which set up would achieve these goals?
Upload the AWS CloudFormation template to Amazon S3. Give users in the QA department permission to assume the manager’s role and add a policy that restricts the permissions to the template and the resources it creates. Train users to launch the template from the CloudFormation console.
Create an AWS Service Catalog product from the environment template. Add a launch constraint to the product with the existing role. Give users in the QA department permission to use AWS Service Catalog APIs only. Train users to launch the template from the AWS Service Catalog console.
Upload the AWS CloudFormation template to Amazon S3. Give users in the QA department permission to use CloudFormation and S3 APIs, with conditions that restrict the permissions to the template and the resources it creates. Train users to launch the template from the CloudFormation console.
Create an AWS Elastic Beanstalk application from the environment template. Give users in the QA department permission to use Elastic Beanstalk permissions only. Train users to launch Elastic Beanstalk environments with the Elastic Beanstalk CLI, passing the existing role to the environment as a service role.
Explanations:
This option allows users to assume the manager’s role, which could lead to unintended access. While it restricts permissions to the template, the assumption of a more privileged role is not ideal for maintaining least privilege. Additionally, it requires training users to use the CloudFormation console, which may not be efficient for launching multiple environments quickly.
Using AWS Service Catalog allows for the creation of a product that encapsulates the CloudFormation template. Adding a launch constraint with the existing role ensures that only the necessary permissions are granted. Users can launch environments without needing to know the details of the CloudFormation template, promoting ease of use and security.
While this option provides permissions to use CloudFormation and S3 APIs, it does not effectively restrict access to only the necessary resources as it allows users to modify or view other CloudFormation stacks and S3 objects. This setup still requires training on the CloudFormation console, which may not streamline the process for users needing to launch environments quickly.
AWS Elastic Beanstalk is not suitable for this scenario as it requires a different configuration and may not align with the existing application architecture. Granting Elastic Beanstalk permissions does not directly facilitate the launch of the existing CloudFormation template, and it complicates the workflow for QA users who may not be familiar with Elastic Beanstalk.
I figure that the answer is:
Create an AWS Service Catalog product from the environment template. Add a launch constraint to the product with the existing role. Give users in the QA department permission to use AWS Service Catalog APIs only. Train users to launch the template from the AWS Service Catalog console.