What does that even mean?
What I am talking about here is the automation of the following:
- AWS Linked Account Creation (the creation of secondary accounts under a single master account)
- Account Initialization and Configuration
- Continuous Compliance
It is commonplace for organizations to manage their AWS assets/resources across a wide range of different AWS accounts. This is nothing new, and we’ve seen some of our customers scale this into the hundreds. This has some pretty obvious implications from an operational, security, and accounting standpoint.
AWS Linked Account Creation
First there is the creation of the linked account itself, which can be a time consuming and arduous (if at least only one-time) process. Even if you have a rigid process for this, it is inevitable that some human error will introduce some drift or inconsistency at some point in time. It’s not a matter of if, just a matter of when. There is also the tracking of the root account credentials and everything that goes along with that. Looks like another process that is ripe for some sweet, sweet automation. Until very recently there was no API available for this, but AWS released a beta API to create linked accounts around a year ago that has recently gone to general availability. So score one for automation!
Account Initialization and Configuration
Now you’ve got your shiny new linked account. but for every account you manage you have to ensure that all of your base settings and resources are properly set up (e.g. AWS CloudTrail, AWS Config, IAM password policies, SAML Federation with your central AD, on and on). Not only set up, but set up in a consistent way so that you don’t have drift between accounts. Ok, so you could put together a nice CloudFormation template (CFT), Manage it in Terraform, or possibly just a homegrown set of scripts (bash+AWSCL, python, ruby, etc.). Those are all a great start, but you still need to be able to audit those resources to ensure they are what they are supposed to be. Also, you need to support the ability to push changes to those resources.
A few examples…
- IT AD Admin: The ADFS servers are updating their XML metadata doc, so we need you to go update the ADFS SAML Federation for our 37 linked accounts.
- IT Security Admin: We need to actively manage our set of IAM Roles that map to ADFS groups and their respective permissions on a regular and ongoing basis. How are we going to quickly and consistently do that across our 37 linked accounts?
- IT Security Admin: Hey, our email address for AWS CloudTrail notifications (SNS subscription) needs to be updated to use a new email address. I need you to get that updated on all of our 37 linked accounts ASAP!
And on and on it goes. Suffice it to say, there is a never-ending need to be able to make modifications across one, several, or all of your linked AWS accounts. You need an approach for handling what would normally be an unwieldy and tedious bit of guaranteed work.
The more human intervention required to manage these things. the more likely we are to see inconsistencies, errors, and misses. And we’ve seen enough cautionary tales on failed security practices in the news in the past few years that I don’t need to stress the importance of getting this stuff right. Every time. All the time.
Continuous Compliance
Once you have these things configured you really need a way to continually audit those resources and settings on an ongoing basis and ideally be able to automatically respond to drift events. This one is a bit trickier than the others because, while you can use tools like CloudFormation or Terraform to set up your initial settings and configurations. the resources they create can be modified afterwards outside of the tool they were created/configured with in the first place. Tools like AWS CloudTrail and AWS Config provide valuable tracking information for helping audit resources but alone don’t solve this puzzle. Especially if you are talking about managing this across a few dozen accounts. Something more robust must be employed to collect that data and do something intelligent with it.
How do I escape this sort of multi-account management nightmare you are describing?!!
I’ll be going into a deeper dive into this in my next blog, but here is a high-level overview of the architecture and accompanying tools and technologies you can put in place to pull it off.
AWS Linked Account Creation
With the somewhat recent release of the organizations API this has become a reality. As per the CreateAccount API documentation. you will need to ensure that AWS Organizations is enabled in the master account. But fear not! You probably already are. Specifically if you are already running multiple accounts under a master account, then you most certainly are. I won’t bore you with details, and AWS already has a very nice article detailing the process required to use organizations and the API to automate account creation. Pretty spiffy!
Account Initialization and Configuration
Once you have created the linked account using the CreateAccount API the next step is to apply any and all org-specific initialization and configuration to the new account to get it all ready for action. This step and the Continuous Compliance step can also be managed by the same tool if that is how you decide to architect it.
The key is that this is where we initialize the account with its base configuration. Whether you do that with custom scripting/code, CloudFormation, Terraform, or some amalgamation of those and/or other tools/services is not of paramount importance. What is important, is having a way to track those resource and their state. Make sure you keep that in mind when architecting a solution. One nice thing about CloudFormation is that the state tracking is built right into the service itself. You can easily list all resources within a CloudFormation stack and you can include stack Outputs to track any custom data you may generate or derive during the CFT stack launch.
You could do something similar with Terraform through the use of their state files, but it (non-enterprise Terraform) lacks the same API queryability that CloudFormation has built in. Also, it is less transparent to the casual onlooker in the AWS console where resources are originating from. Of course, once you query the resources you will still require a method for determining and tracking the state of those resources. But now we’re getting ahead of ourselves.
Continuous Compliance
This is going to require a service that will allow you to: – Track the state of resources we care about – Audit the state of those resources automatically on an ongoing basis – Report on any configuration drift – Optionally automatically remediate drift.
Using the AWS CloudTrail and AWS Config services gives us the ability to track changes real-time and tie those changes to a specific user/role. But what about services that are not yet supported by AWS Config? In that case you may want to (as we have done) build a suite of services to handle these tasks. Resources and configurations are registered with a service that tracks their known-desired state. Another service is responsible for querying the current state of those items and raising a flag if there is drift. Potentially another service could report on those flagged out-of-compliance resources/settings. Optionally you could deploy a service that remediates drift in your desired configuration state on all out-of-compliance resources, or possibly just a subset.
At 2nd Watch we’ve actually architected and built out our own Managed Cloud specific implementation of Automated Account Creation and Continuous Compliance. If you would rather focus your energy on your business’s core competencies and not on building foundation cloud management tooling, why not come on board and let us empower you to deliver your product and drive shareholder value in the most secure, stable, and cost-effective way possible? We’ve got the tools and the people to make it happen! Contact us to learn more.
–Ryan Kennedy, Principal Cloud Automation Architect
