AWS Org Admin Account

ACM.393 Mirror the AWS organizations management account but using an account to which service control policies (SCPs) will apply

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

⚙️ 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 changed my SSM Parameter implementation for the root account to use my common SSM Parameter code. I also add the capability to pass in a parameter list.

Now, although I want to set up a production and non-production infrastructure at this point I have no repository accounts or repositories. Someone has to deploy them.

I could deploy them using the rootadmin in the root account service control policies don’t apply to that user because it is in the root account. What if I have to update those resources later? I must use the role in the root account the way I’ve designed my CloudFormation naming convention and permission structure where the first prefix on a stack name is [rolename-] and only the role that created the stack can modify it.

I was initially going to try to deploy the initially non-root user in the IAM account but then it’s complicated because I don’t want the IAM administrative role to be able to modify this all-powerful user or its policies. If I try to do that from the IAM account I’m going to have to create complex policies that will likely be error prone.

What if I just put the non-root user with nearly root privileges in its own account above every other account. This user uses code that’s not in a repository since there isn’t one yet in this organization anyway to do the initial deployment so it doesn’t need to be associated with a repository. In addition, this user should not be used after the initial deployment except in case of emergency.

I don’t really need an OU for a single account, unless I need to get past the 5 SCP limit per account or OU. I don’t think so. This is going to be a pretty powerful user only subject to the rules that apply to everyone in the organization (like which regions are allowed.)

So I’m going to create a single account for the orgadmin that requires MFA for all actions and can be used for the initial organization deployment and in case of emergency after that. This user’s development credentials can be disabled while not in use.

I can also deploy the root OUs that apply to all principals in the organization with the root user. I’m not going to deploy the prod (production) and nonprod (non-production) OUs here just adding to show where the orgadmin account shows up in the hierarchy.

Rename existing resources

I renamed my existing OUs and accounts, though AWS Organizations seems to have some kind of bug because the renaming wasn’t working consistently.

A note on Bash as a choice of language

Along the way, I spent way too long troubleshooting an error. I changed my validation function around and I used the same argument name for two different functions and one was overwriting the other. Bash is not a secure language with proper scoping but I’m starting with it because it’s the fastest way to demonstrate concepts. The private variables from one function should not be able to overwrite another in a language with secure scoping.

Beware of Keys to the Kingdom

Essentially I want to get out of the root account and start deploying things from an account that has the same permissions as rootadmin but to which Service Control Policies apply. Recall that they do not apply to the root account.

After going around in circles on this, but I’m going to keep it simple and deploy an orgadmin account, organizational unit, user, and role that has the keys to the kingdom. This account and user can assume admin roles in any account and do almost anything, except change other people’s credentials and manage domain names. This account will be used to set up the initial organization, test things out, and then get locked down under normal circumstances.

What we don’t want is for these credentials to be on some developer’s machine and that developer deploys some software that gets onto their machine and gains access to these credentials. That means we’re going to use our container in this account with the credentials stored in Secrets Manager — not save credentials on a developer workspace or EC2 instance.

OK let’s do it.

Create the orgadmin resources with the rootadmin user

I moved over all my Organizations code and made the changes described in this post.

Account — orgadmin

I create the orgadmin account using code written earlier in the series and modified as above including the account CloudFormation template:

resources/organizations/account/account.yaml

and the account functions:

resources/organizations/account/account_fucntions.sh

A noted in an earlier post I removed the dynamic references in the template.

I’ll retrieve any parameters I need as demonstrated in the last post and pass them into the template.

I added the environment name to my common stack deployment function. I’ll need to go back and add that to the resources I’ve deployed so far in this new directory structure:

I append the enviroment to the resource name like so:

This will help me with future policy conditions.

I changed and added functions to retrieve the organizational parameters. this presumes you are operating in the root account. I might have to adjust this later.

Here’s my deployment script:

Shared stack deploy changes in /deploy/shared/functions.sh

Account functions changes in /resources/organizations/account/account_functions.sh

Account template:

Successfully deployed after a few fits and starts:

Now that we have an account we can create a new user here that has administrative privileges but operates outside the root account, delegate certain permissions, and apply SCPs.

Update: I later renamed this account root-org, a name I was considering giving it in the first place, because I had issues deleting an account again as outlined at the end of this post:

I later renamed the role in this account to be generic rather than account specific as I don’t want the organization name in my directory strcuture. That’s explained in a later post. It’s also less accounts to manage when I simply have the rootadminrole, a prodadminrole, and a nonprodadminrole. I explain and deploy all that in later posts.

I later added some additional outputs to make it easy to find the email address and the default cross-account Organizations role for the Account:

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