Deploying an AWS Account Using a Deployment Container

ACM.413 Migrating my code from my POC to my container that requires MFA to run a deployment job

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Check out my series on Automating Cybersecurity Metrics | Code.

🔒 Related Stories: AWS Organizations | IAM | Deploying a Static Website

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In the last post, I looked at what happens when you delete a resource behind an AWS CloudFormation stack and AWS Drift Detection.

I had to fix some issues with my Organizational Units before proceeding with this post. I originally showed you how I deployed Organizational Units for an organization in parallel here:

I can do something similar to deploy accounts. First, I need to get an AWS account to deploy using my deployment container so I need to migrate over my proof of concept (POC) code.

Existing script to deploy an account

I already have a template to deploy an account because I deployed my root-org account with it.

deploy/rootadminrole/organizations_account_org.sh

I’ll copy that over to my root-orgadmin folder and use that as a basis for creating my new files to deploy accounts in my organization practically simultaneously (within the limits of the AWS quota — 5 accounts at a time):

Files for creating accounts with the root-orgadmin user

First I can extract the parts of the above file that create a single account and put it in this file:

deploy/root-orgadmin/organizations_account.sh

Note that when you specify an OU ID for CloudFormation, behind the scenes it appears to create the account first at the root and then moves it to the correct OU. That’s a problem for a service control policy that prevents deploying accounts at the root. I don’t even think my SCP was enforced last time I tried it. But I can prevent passing the root OU into the function that creates accounts:

I’ll need to make sure my deploy_account functions works with the new OU id lookup function I created a few posts back.

Now I can test to make sure I can deploy a single account. I want to deploy my IAM account in my orgadmin-governance OU.

I can use the gen_code functionality I wrote about earlier to create a deployment file for my iam account.

I skip creation of the functions and template file since I already have those.

The code assumes I’m calling the deploy function directly and is just a starting point, but all my header and footer and basic variables get added for me at this point.

I can simplify this file to call the account creation script. Maybe I’ll adjust gen_code to handle that for me at some point, but here’s my file:

Next I can add my file to deploy all the accounts.

organizations_account_all.sh

For my initial test I deploy one account.

I add my script to the list of choices that a user can deploy when testing locally (and I haven’t fully explained this script yet but I will at some point):

Now I can test deploying the account directly with the IAM account deployment job.

When I run my script I realize that I need to add permissions for the root-orgadmin user to access the SSM parameters in the management account with the organization information.

Here are the actions for SSM:

I update the role policy which is easy to find due to my naming convention:

awsdeploy/resources/iam/rolepolicy/root-orgadminrolepolicy.yaml

I don’t intend to add secret information to SSM Parameter store or use it for the most part in this account so I grant full read access. I had to fix the SID above as they can’t have spaces, and if you add them you get a generic syntax error:

There is no way to add a resource policy to SSM parameters so that should be all that is needed.

I run my local test script and select the root-admin user.

That displays the resources the root-admin user can deploy.

I select the policy I want to update.

The root-orgadmin cannot update their own credentials because its own policy does not allow it.

That user also wouldn’t be able to provide the root-admin MFA, so only the rootadmin can update the policy.

After making that change I attempt to run my IAM account creation script again and it works.

Now I can test creating an all-accounts script to deploy multiple accounts simultaneously.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2023

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab