Review Note: This section is an early draft and undergoing reviewing and editing.
In this step either Security or Cloud Administrators will onboard a limited set of responsible analysts who will have access to the workload environments. We will introduce IAM Permission Boundaries on the workload organizational units to constrain the set of IAM permissions that can be granted. This will enable the access necessary to manage operational events in the workload account.
This step should take about 30 minutes to complete.
In this step you’ll use AWS CloudFormation StackSets to distribute an IAM permissions boundary policy to the test and production OUs. This boundary policy will help ensure that workload admin teams using workload AWS accounts can’t modify your foundation cloud resources.
Since the permissions boundaries are placed at the OU level, this step only needs to be done once. It will automatically be applied to any accounts placed into these OUs in the future.
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 test 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-prod-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 test OU IDs, open a new browser tab and access AWS Control Tower
. Select Organizational units
, and select each of the following test OUs to obtain its OU ID:
workloads_prod
workloads_test
Specify regions
, select your home AWS region.Next
.Submit
.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 workload administrators will work in the workload specific 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-workload-admin-team-<workload_id>
.Description
. For example, Day-to-day permission used by admins in their workload test and prod 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 workload admin teams to the new workload AWS accounts, you’ll reference this permission set.
Create a new group in AWS SSO for each of the builder teams and associate those groups with an initial set of permissions and their respective team development AWS accounts.
management
account.Management console
associated with the AWSAdministratorAccess
role.AWS SSO
.Groups
in AWS SSO.Create group
.example
with your organization’s identifier:example-<workload_id>-admin
<workload identifier> Admin Team
Create
.Next, enable each team development group to access the associated team development AWS account.
AWS accounts
in AWS SSO.<workload>-test
<workload>-prod
Assign users
.Groups
.example-<workload>-admin
group you created in step 1.Next: Permission sets
.example-<workload>-admin-team
.Finish
.This assumes you’ve already created users in AWS SSO for team members who will administer the workload, or alternatively you’ve migrated to a federated access model. If this is not the case, you can create new users by following the process documented earlier in this guide.
Groups
in AWS SSO.example-<workload>-admin
.Add users
.Add users
.The foundation team members will now have access to the workload-specific AWS accounts.