In this step your Security and Cloud Administrators will provision resources to control the access to team development AWS accounts.
This step should take about 20 minutes to complete.
Automated provisioning of resources: Ideally, you would use automation to deploy policies and other configurations to your AWS accounts. Customizations for AWS Control Tower is an AWS solution that uses AWS services including AWS CodePipeline and AWS Control Tower Lifecycle Events to help you more efficiently manage these types of resources as code and via pipelines. Both the SCPs and IAM permissions boundary policy resources addressed below are candidates for using this automation solution.
Using AWS Organizations, create several Service Control Policies (SCPs) that will initially be applied to the workloads_dev
OU. Combined, these SCPs will disallow any user from creating and modifying foundation VPC networking resources in standard team development AWS accounts.
Since you’ll likely want your Cloud Foundation team members to be able to develop and test changes to foundation VPC resources in their team development AWS accounts, it’s recommended that you don’t want to apply the SCPs to the infrastructure_dev
OU.
Service Control Policies (SCPs): If you’d like to learn more about SCPs, see Managing AWS Organizations policies.
Review the sample team development access controls: See Controlling Builder Team Access for a detailed explanation of the requirements and sample implementation of how you can provide freedom to your builder teams in their team development AWS accounts, but inhibit them from adversely impacting the security of your overall AWS environment.
Service Control Policies (SCPs) and AWS Control Tower: You need to be very careful when using customer-managed SCPs with AWS Control Tower so that your SCPs do not conflict with the new AWS account baselining processes carried out by AWS Control Tower Account Factory. See Controlling Builder Team Access for further details and an example of how to avoid such potential conflicts.
Either open in a separate browser tab or download to your desktop the following sample SCPs:
master
account.Management console
associated with the AWSAdministratorAccess
role.AWS Organizations
.Policies
.Service control policies
Create policy
.example-infra-scp-vpc-core
example-infra-scp-vpc-boundaries
workloads_dev
OUOrganize accounts
.workloads_dev
OU.Service control policies
.Attach
link next to the SCPs
example-infra-scp-vpc-core
example-infra-scp-vpc-boundaries
In this step you’ll use AWS CloudFormation StackSets to distribute an IAM permissions boundary policy to the development OUs. This boundary policy will help ensure that builder teams using team development AWS accounts can’t modify your foundation cloud resources.
In a later section, when you create several team development AWS accounts, you will associate the AWS accounts with the development OUs. Any AWS account that is added to the development OUs will automatically be configured with the IAM permissions boundary policy resource. Similarly, when an AWS account is removed from the OUs, the IAM permissions boundary policy resource will be automatically removed from the AWS account.
First, enable the AWS CloudFormation service to automatically configure permissions required to use the CloudFormation StackSets feature to deploy stacks to AWS accounts in your AWS organization.
AWS CloudFormation
.StackSets
.Enable trusted access
.This is a one time operation: If you’d like more background, see Enabling Trusted Access with AWS Organizations.
Next, download the sample AWS CloudFormation template example-infra-team-dev-boundary.yml
to your desktop.
Create a StackSet to deploy the permissions boundary policy to all AWS accounts associated with the development OUs.
Create StackSet
.Upload a template file
.Choose file
to select the downloaded template file from your desktop.Next
.StackSet name
. For example, example-infra-team-dev-boundary
.It’s useful to prefix your custom cloud resources that live in a larger name space with your organization identifier and a qualifier such as infra
to represent foundation resources. The important consideration is to be consistent with naming of foundation cloud resources so that you can apply IAM policies that will inhibit unauthorized modification of those resources.
Parameters
:Parameter | Guidance |
---|---|
pOrg |
Replace example with your organization identifier or stock ticker if that applies. This value is used as a prefix in the name of IAM managed policy that is created by the template. |
Leave the other parameters at their default settings.
Next
.Permissions
set to Service managed permissions
.Next
.Deployment targets
, select Deploy to organizational units (OUs)
.If you didn’t make a copy of the development OU IDs, open a new browser tab and access AWS Control Tower
. Select Organizational units
, and select each of the following development OUs to obtain its OU ID:
infrastructure_dev
workloads_dev
Specify regions
, select your home AWS region.Next
.Submit
.Since you have not yet created the team development AWS accounts, this CloudFormation StackSet won’t create CloudFormation stacks in the team development AWS accounts until those AWS accounts are created in a subsequent section.
Proceed to the next step.
Next, you’ll create a custom permission set in AWS SSO to represent the initial iteration of an AWS IAM policy under which builder team members will work in their team development AWS accounts.
example-infra-team-dev-saml.json
to your desktop.example
with a reference to your own organization’s identifier.AWS accounts
in AWS SSO.Permission sets
.Create permission set
.Create a custom permission set
.Name
. For example example-infra-team-dev
.Description
. For example, Day-to-day permission used by builders in their team development AWS accounts.
.Session duration
to the desired value.Create a custom permissions policy
.Replace example
with your own identifier: Before you select Create
, in the permissions policy, ensure that you replace all occurrences of example
with your own organization’s identifier. Otherwise, the permission set will not work as expected.
Create
.Later, when you onboard the builder teams to their team development AWS accounts, you’ll reference this permission set.