Organizational Root User for Initial Setup on AWS

ACM.157 Creating an initial user to manage our AWS Organizations and new AWS accounts

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

⚙️ Part of my series on Automating Cybersecurity Metrics. The Code.

🔒 Related Stories: AWS Organizations | IAM | Cloud Governance

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

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

In the last post, we looked at how we might limit risks associated with the default AWS Organizations role in new AWS accounts.

Considerations for running initial scripts in a new AWS account

In this post, I’m going to set up a new user to run our initial user in the Management Account to run initial scripts in a new account so we don’t have to login as root.

Now you might thing it’s a really simple thing to deploy the initial user but I thought about it a lot. Does it really matter or should we just deploy our initial scripts with the root user? Should we use the existing user creation scripts I created in prior posts? Should I just deploy the first user manually? Should I use CloudShell or not (a topic I already wrote about in a prior post).

The scenario is that we have a brand new AWS account and we don’t want to add long-lived credentials for the root user. I could easily manually create a new first user. But I decided it would be good to automate the creation of the initial user to have a consistent deployment process and steps that others can follow, if they want. Also, we may decide to make changes to this user or add alternate users down the line. I can easily follow my own directions to redeploy the account in the event of disaster recovery.

Here’s the process I came up with.

OrgRoot user (organizational administrative account)

This OrgRoot user serves the following purposes:

1. Run the initial organizational scripts that deploy the Governance OU, accounts, and permissions with boundaries that prevent those users from changing their own permissions or making changes in the management account.
2. Use an emergency backdoor should other permissions or accounts have issues, or in the event of a misconfiguration.
3. We can make this user an administrator and test access to the default AWS Organizations role I wrote about in the last post.

Automate Deployment of the OrgRoot User

Now, I have some code created in earlier posts to create users with CloudFormation. We could use that code to create the OrgRoot user, but we’d have to modify it.

The OrgRoot user is not going to be in a group or have to assume a role once logged in. The OrgRoot user will simply have the AWS Administrator policy attached to it via a ManagedPolicyArn. We can also attack a Permissions Boundary to limit what the user can do, even though the admin policy is associated with the user.

Because this code is not going to work the same way I’m going to create a new template. There is another reason why I want to separate out this code as well.

Breaking the DRY Principle

I’m going to break out this code into a separate folder and manage it separately from the other IAM code. It will become clear why I’m doing this later. I’m going to call my new folder OrgRoot to match the user name we are creating in the management account and it indicate that these are resources created in the organization’s root or management account.

I may have a bit of duplicative code which I told you that you should avoid for the most part when I wrote about the DRY principle.

The point where you would want to break this rule is when you have some very sensitive code that you want to change as little as possible to avoid inadvertent errors or introduction of security problems. Because this root code is so critical to the security of our entire AWS account, I’m going to put it in a separate directory. Changes to code that deploys resources to our management account should be few and far between.

Create User Template

I made a few modifications to the user template to match the above design objectives and hardcoded things that should never change for this particular user.

I need to get the ARN for the AWS Managed Administrator policy I want to attach. Let’s navigate to IAM, find that policy, and get the ARN.

You can find the ARN when you click on the policy:

Here’s my User.yaml template for the OrgRoot user at this point:

Deploy the Template

I’m going to use a simple CloudFormation deploy command to deploy this template via CloudShell for reasons explained in a prior post. This is a step I will take once and then once the user is deployed, I will login as that new user and work via that user going forward. I’m going to run very few commands initially in this root account so the risk should be minimal. Then I will lock away these credentials and only use them if and when needed.

Log into your AWS Management Account as the root user (we haven’t deployed a single thing to our AWS account yet and we have to start somewhere). Switch to the region where you want to maintain your organizational resources. Although AWS IAM is a global service, meaning a user is not deployed into any particular region, the CloudFormation stacks that result from this deployment will be in a particular region. You’ll probably want them all in one place. You can lock down which regions can be used for deployment with an SCP.

The first thing I need to do is get the CloudFormation template into CloudShell. I’ve tried creating a new file with vi and copying and pasting it into AWS CloudShell but that fails miserably from a Mac, so I’m just going to upload the file instead. I was able to easily copy and paste my code from GitHub to my local laptop and then I can upload that file using the file upload functionality at the top right of CloudShell:

Select the file:

Type ls to verify your file exists:

Now run the following command to deploy the OrgRoot user:

aws cloudformation deploy --template-file User.yaml --stack-name ROOT-USER-OrgRoot  --capabilities CAPABILITY_NAMED_IAM 

Once that completes you should have a successful CloudFormation stack:

You should also see the user in IAM.

Add MFA to the user as we did in prior posts.

Head over to Secrets Manager and get the password, same as we did for other users we created via CloudFormation in earlier posts:

Logout as the root user in the management account.

Login as the new OrgRoot user. Change the password.

Remember to sign in as an IAM User, not the root user, using your management account number or alias:

Once you change the password you can delete the OrgRoot secret as it is no longer relevant or needed. You may opt to store the OrgRoot password in Secrets Manager but as discussed in prior posts, you need to make sure that no one but the appropriate users can obtain that secret.

Now that we have a root user we can test logging in with the AWS Organizations default role in our new governance account, which we’ll do in the next post.

We’ll revisit our permission boundary later after we take a look at how Okta integration with IAM works.

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