Before joining AWS, I was an APN Partner for a managed services company. The bad news, the company decided not to pursue AWS Professional services anymore and the good news, my joint blog post went live the same week that I started at AWS. There’s always a positive side to things and I have no regrets because they gave me the freedom to learn and grow.

AWS Landing Zone was a hot topic within the tech community. But I didn’t even know it existed until a partner we were working with came across it in BETA. It probably took me a month to get familiar with it, mine you this in 2018 right before re:invent.

AWS Landing Zone has grown into a great product that most people use now called AWS Control Tower.

Official AWS APN Blog Post

https://aws.amazon.com/blogs/apn/automating-security-governance-and-monitoring-in-aws-landing-zone-to-save-time-effort-and-cost/

(credit also goes to Jim Huang from AWS)

Back then we had to develop our own customizations for AWS Landing Zone and integrate them into the deployment. Here’s a SHORT list of customizations that were integrated during the deployment. Most of these are done auto-magically now.

Before I get into the list of customization, one really stands out to me. How do you set the account alias during account deployment? Sounds like it should be simple right? During account deployment using AWS Service Catalog and pass that to the newly created account and use CLI to set the Account Alias.

It turns out that there wasn’t an CLI command to set the alias unless you used BOTO, but you had to output the Account name from the AWS CloudFormation stack, then grab that and pass it to the next stack. After about a month of trying to figure out the code, I got a break. AWS hooked me up with a CloudFormation guru in Dublin. This guy was AWSome and it took him a week to figure out the AWS CloudFormation template, add like, 5 lines of code and some output. Then during deployment we were able to set the account alias. Now most of you are wondering, why do you need this set? Why is this a big deal? Because the Account Alias was used for ADFS integration, budgeting, and tagging the environment.

If you read my article about “How I accidentally met Andy Jassy @ re:invent 2018” it covers some of the things I talked about.

https://www.linkedin.com/pulse/how-i-accidentally-met-andy-jassy-reinvent-2018-jon-myer%2F/

  • Automated account alias: When a new account is created using the account vending machine (AVM), the account alias doesn’t exist. It has to be entered manually after logging into the newly-created account. Without the account alias, some of the customized implementation features aren’t possible.

Integrated the account alias into the original AWS Landing Zone code. When a new account is created now, it takes the name during deployment and updates the account alias.

  • AD FS integration: Using AWS CloudFormation, we took the customer’s AD FS metadata and integrates it into AWS Landing Zone. When the CloudFormation template is deployed, the identify provider is created along with the updated metadata and AD FS roles.
    The roles are later used for Active Directory security groups after the customer updated its AD FS claims relay to support a new account.
  • IAM 90-day access/secret key rotation enforcement: The customization used an AWS Lambda function that runs once a day to check the access/secret key age of all local users. If the key age reaches 76 days, an email is generated to the existing notification topic and sent out as an alert.
    An email is sent each day until a new access/secret key is created or the old one is removed. If the age of the access/secret key reaches 91 days without rotation, it is disabled.
    Built in an access/secret key whitelisting or exception group to support a service or specific account that can’t reset or change the access/secret key.
  • MFA for local accounts through automation: Using a Lambda function, this customization monitors AWS CloudTrail Events for any newly-created local user account. If a new account is created, it’s automatically added to a group that enforces multi-factor authentication (MFA) before the account can access resources. This function also runs every six hours to check if a user was removed from the MFA group. If so, the function moves the local user account back into the MFA group.
    Built in an MFA whitelisting or exception group to support services or specific accounts that cannot handle MFA.

Check out the APN Blog post for more information.

Leave a Comment