I work at a consulting company where there are numerous developers and consultants that require a sandbox environment in AWS. Developers may be working in isolation or they may be collaborating with other developers on a shared project.
At present, everyone shares a single AWS account and it becomes challenging to govern. We routinely have to prune resources no longer in use when our monthly bill becomes out of control. This requires an admin to look through the resources in numerous regions and reach out to developers to figure out who owns a resource.
To help manage and govern our AWS usage, I'm going to use AWS Control Tower to allow admins and developers to provision isolated accounts at the developer or project scope and to provide a set of guardrails to enforce AWS best practices.
In the first part of this series, I'm going to walkthrough the process of configuring a Landing Zone in AWS Control Tower. Further articles will dive deeper into the specific configuration for my team.
AWS Control Tower Initial Setup
At my company we already have an existing AWS account that's acting as a shared space for all developers. I'm going to use this account as the AWS Control Tower landing zone. A landing zone is a is a well-architected, multi-account AWS environment that's based on security and compliance best practices. This is the enterprise-wide container that holds all of your organizational units (OUs), accounts, users, and other resources that you want to be subject to compliance regulation.
To start configuring AWS Control Tower:
- Log in with a IAM user that has AdministrativeAccess in the account
- Navigate to the AWS Control Tower console https://console.aws.amazon.com/controltower/home/dashboard?region=us-east-1
-
At the console, if AWS Control Tower has not been configured, the following screen will be shown, click Set up landing zone to begin
-
At the Set up landing zone screen, the following information is required:
- Master account: This is the email address used to set up your master account. This account will be used as the master account for the landing zone and will be the consolidated billing account (each member account managed by AWS Control Tower will have bills consolidated under the master account).
- Log archive account: This is the email address used to create the AWS account that contains a log archive of all API activities and resource configurations from the master account and all member accounts managed by Control Tower. This email address must be unique. I had to work with my company's system administrator to create an email alias for this account.
- Audit account: This is the email address used to create the AWS account that strictly used by security and compliance teams. These teams will have read/write access to all accounts managed by Control Tower. This email address also has to be unique.
-
Creating the landing zone takes about 60 minutes or less. The status can be monitored from the Control Tower console
-
When complete, the Control Tower dashboard will indicate success and provide a summary of the items that were configured.
At this point, there is a base-level landing zone configured and ready to be used. In the next section, I'll walk through the items that were configured by Control Tower.
What was created
A Landing Zone in AWS Control Tower creates items in other AWS services such as AWS Organizations, AWS Single Sign On, CloudTrail, Config and others.
AWS Organizations
Control Tower creates an organization in AWS Organizations to create and centrally manage multiple AWS accounts. Accounts in AWS Organization can be organized into groups and policy-based controls can be attached to those accounts.
Within Control Tower, Organizations help centrally manage billing. The bills for the member accounts will be billed under the Control Tower master account as a single bill with detailed views for each member account.
Organizations also helps control access, compliance and security across the member accounts. Access, compliance and security policies can be mapped to groups of AWS accounts called Organizational Units to efficiently manage the policies at scale.
Other AWS resources can also be shared across accounts in an Organization. One example, is sharing a VPC across all accounts in an Organization. This allows the networking team to centrally manage network policies, gateways, and VPN/Direct Connect connections.
Organizational Units
While AWS Organizations provide the capabilities to organize AWS accounts into Organizational Units (OUs), Control Tower provides the blueprint on what the pre-configured OUs should be and the policies attached to those OUs.
In addition to the Root OU, which contains the master account, Control Tower configures these additional OUs:
- Core: Contains the Audit and Log Archive shared AWS accounts that were created when Control Tower was configured
- Custom: Contains the member accounts for users to perform their workloads
Guardrails are applied at the OU scope for all accounts that are a member of that OU.
Shared Accounts
Control Tower creates three shared AWS accounts in the Landing Zone.
- Master Account: This is the account where the AWS Control Tower Landing Zone was first configured. All billing will be consolidated to this account for all accounts within the Landing Zone. OUs and Guardrails are configured in the Master account and the Account Factory uses the Master account to provision member accounts
- Log Archive Account: This account maintains a log of all of API activities and resource configurations. This account has CloudTrail, CloudWatch Logs and S3 buckets for storing the logs files.
- Audit Account: Restricted account for audit and compliance teams. Those teams will have read/write access to all member accounts in the Landing Zone. Only programmatic access from the audit account to other member accounts is allowed.
Guardrails
Guardrails are high-level rules for providing governance across all accounts in the Landing Zone. Guardrails can be expressed in simple language to convey their goal clearly. Guardrails can be mandatory, strongly recommended, and elective. Mandatory guardrails cannot be disabled.
Guardrails are attached to OUs within the Organization and not specific accounts.
Guardrails can either be preventive or detective. An example of a preventative guardrail is Disallow policy changes to log archive. This prevents any IAM policy changes in the log archive shared account. Any attempt to perform a prevented action is denied and logged in CloudTrail. The resource is also logged in AWS Config.
A detective guardrail detects an event and logs the event in CloudTrail. An admin can view resources that are out-of-specification with the guardrail. For example, the Enable encryption for EBS volumes attached to EC2 instances detects if an unencrypted Amazon EBS volume is attached to an EC2 instance in your landing zone.
Guardrails are implemented with Service Control Policies (SCPs)in AWS Organizations for Preventative guardrails and AWS Config rules and Lambda functions for Detective guardrails.
At this time, Guardrails are provided by AWS and controlled via Control Tower versions. Admins of a Landing Zone cannot create their own Guardrails and apply them to OUs. Later in this article, I'll show how to create custom Service Control Policies and apply them to OUs within Control Tower.
Account Factory
There are three methods to creating a member account within AWS Control Tower:
- Account Factory console (AWS Service Catalog)
- Enroll Account (AWS Control Tower)
- Lamdba with IAM roles in Landing Zone Master Account
The recommended approach is through the Account Factory console. Users will the appropriate permissions can launch a new member account within the Landing Zone maintained by AWS Control Tower. The new member account will assigned to an OU and will inherit the enabled guardrails of that OU.
When launching a new account from the Account Factory console, end users won't know they are working within Control Tower. They will simply use the console to create and terminate an AWS account.
AWS Single Sign-On (SSO)
An AWS Single Sign-On directory is created in the Master account when creating a new Landing Zone with Control Tower. AWS Single Sign-On allows cloud administrators and end users to manage access to multiple AWS accounts.
Within AWS SSO, Control Tower configures multiple user groups that have various permissions to perform operations within the Landing Zone. The following user groups are created:
| Group name | Description |
|---|---|
| AWSAccountFactory | Read-only access to account factory in AWS Service Catalog for end users |
| AWSAuditAccountAdmins | Admin rights to cross-account audit account |
| AWSControlTowerAdmins | Admin rights to AWS Control Tower core and provisioned accounts |
| AWSLogArchiveAdmins | Admin rights to log archive account |
| AWSLogArchiveViewers | Read-only access to log archive account |
| AWSSecurityAuditors | Read-only access to all accounts for security audits |
| AWSSecurityAuditPowerUsers | Power user access to all accounts for security audits |
| AWSServiceCatalogAdmins | Admin rights to account factory in AWS Service Catalog |
AWS SSO also defines a list of Permission Sets to define permissions that a User/Group have within an AWS Account. Permission Sets are created with an IAM Policy that defines the Allow and Deny permissions to be given to a user/group.
The following Permission Sets are created by default:
| Permission set | Description |
|---|---|
| AWSReadOnlyAccess | This policy grants permissions to view resources and basic metadata across all AWS services |
| AWSServiceCatalogAdminFullAccess | Provides full access to AWS Service Catalog admin capabilities |
| AWSServiceCatalogEndUserAccess | Provides access to the AWS Service Catalog end user console |
| AWSPowerUserAccess | Provides full access to AWS services and resources, but does not allow management of Users and groups |
| AWSAdministratorAccess | Provides full access to AWS services and resources |
| AWSOrganizationsFullAccess | Provides full access to AWS Organizations |
Control Tower admins can create additional permission sets within the Landing Zone to meet their needs.
Conclusion
This article gave a high-level overview of AWS Control Tower and a walkthrough on configuring a Landing Zone using it. In the next article of this series, I'll discuss how I configured the Landing Zone for our group of consultants and developers.
Top comments (0)