Automated AWS Organization Creation

ACM.152 Automating the creation of an AWS Organization, Organizational Unit, Account, and Delegated Administrator

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

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

In my last post, I pondered an alternate approach for an implementation of AWS IAM Identity Center, for the reasons I explained.

Now that I’ve reviewed how AWS implements SCIM and determined that I don’t want to use AWS IAM Identity Center at the moment, I’m back to the new account I created and setting up my Organization and AWS IAM.

I already explained how I created a new AWS account here with secure default settings:

I’m going to try out Okta without SCIM and with AWS IAM. Before I do that I’m going to do a few other things I showed how to create in the past but in an automated fashion instead of manually. I’m not using AWS Control Tower for the reasons mentioned in the above post.

• Create an organization.
• Create a governance OU.
• Create a governance account in the OU.
• Make that governance account a delegated administrator for AWS Organizations.

Manually creating an organization in the AWS console

I could create the organization manually. That’s simple.

Log into your AWS account. Search for organizations.

Click on Create an Organization.

That’s it.

Automated creation of an organization

I want to automate the above. What are my options?

Well, if I look at AWS Organizations in CloudFormation these are the resources I can create:

I can’t create the Organization with CloudFormation but that would probably be overkill because you create an organization one time and don’t need to modify it after that point.

Let’s see what we can do with the AWS CLI.

You can find the full list of AWS Organizations CLI commands here:

You can also get all the commands for AWS Organizations by typing:

aws organizations help

Scroll down for the list of commands:

We can create an organization via the AWS CLI using the create-organization command.

The question is, how are you going to run that command in a new account when all you have is the AWS root user?

AWS best practice is that you NEVER create an AWS access key id or secret access key for programmatic actions for the root account. If we don’t do that how would we run the above command?

Well if you recall in a prior post I showed you how to use CloudShell (and the risks associated with that). Can we use CloudShell with the root account? Well, the CloudShell icon is there, so click on it.

Yes, we have CloudShell and can access it. The AWS CLI is pre-installed via the root user in an AWS account:

So although you’re never supposed to use long-lived credentials, an attacker that gains access to your browser when logged into AWS as root to use the AWS CLI in your account. You have been warned. Avoid logging in as root and lock away the key as discussed in the post where I created my new account above.

But since it’s here we could use it to create our organization. There’s nothing in our account right now so not a lot of risk. As long as we do it quickly and an attacker doesn’t have a chance to get in and create a backdoor user or access while we are logged in, we should be ok. I already set up MFA on the root user in the above post where I created the new account.

So let’s run the command to create an organization and see what happens:

aws organizations create-organization

View the output:

The value that starts with “o-” is your organization ID. we’ll need that for some of the other commands.

Navigate back to the Organizations dashboard.

Take note of three things on this screen.

1. The Organization ID you saw when we created the organization is in the left menu.
2. A “Root” node was created in your organizational hierarchy. Your root node has an ID that starts with “r-”.
3. The account where you ran the command to create the organization is now the management account.

I mentioned before when we create an organizational service control policy that it does not apply to the management account.

Therefore, whatever guardrails and restrictions we try to apply across the organization can be bypassed in the root account. This is good, if you make a mistake that is locking everyone out of your account. This is bad if someone can get in and take actions in your management account. Your policies have no effect. That is why it’s best to create a new account and work from there. Lock away those root credentials and MFA keys!

Recall that I previously wrote about the concept of root of trust which you will want to establish in your organization.

We’ll be attempting to do that over the next few posts.

Create a new Organizational Unit programmatically

We have different options for creating organizational units. We could use CloudFormation or the AWS CLI. If we use CloudFormation we would have to create a template, check it out from source control and get it into AWS CloudShell and run it from there. Then in order to manage that CloudFormation stack we would have to log back into the root account.

For this reasons I’m just going to create the first governance organizational unit from the command line. Using the command line reference above I can see that I can create an organizational unit with this command:

The required parameters include the parent ID and a name:

Remember how I told you to take note of the root ID above for your organization? That is the parent OU and you’ll need to pass that value in as the parent-id along with whatever name you want for your new OU.

Besides looking in the console, you can also get the root id with the following command:

aws organizations list-roots | grep "Id"

Run your command with the appropriate value:

aws organizations create-organizational-unit --parent-id r-xxxxx 
       --name Governance

Navigate back to the organizational dashboard.

You can see the new OU in the AWS organizations hierarchy.

Notice the value that starts with “ou-” under our new Governance organizational unit. That is the Organizational Unit Id. We are going to need that value below.

Create a new Account programmatically

Next let’s create the Governance account. Once again we can see here that it’s pretty simple to do so with the AWS CLI.

Run the command. Replace [email protected] with an email alias for your new account, the same way I explained you should create an alias for your root AWS account in the post above.

aws organizations create-account --email x@x.com --account-name Governance

Return to the organizations dashboard. Do you see a problem?

We created the new account but did not specify an organizational unit, so the account is at the same level as the management account. We could apply policies to the Governance account directly but any policies applied to the Governance OU would not apply to the governance account.

Move an account into an OU

To fix that problem we could delete and re-create the account. Alternatively we can move the account into the Governance OU. Now here’s where you would have a mess when using Control Tower. If you move the account to a new OU then things get a little wonky and you have to run some processes to clean things up in Control Tower. Since we are not using Control Tower here we can move the account without any issues.

Let’s use the move-account command. We’ll need the ID for the governance OU and the root ID.

Run the command to move the account into the governance ou:

aws organizations move-account --account-id xxxxxxxxxxxx
  --source-parent-id r-xxxxx --destination-parent-id ou-xxxxx-xxxxxx

Return to the Organization dashboard.

Click the down arrow next to your Governance OU.

Now you can see that the Governance account is in the Governance OU. You can apply policies to the Governance OU and those policies would apply to the Governance account.

Programmatically Create a Delegated Organization Administrator

Now as you recall, last time I tried creating a delegated administrator, I ended up simply manually creating one for my AWS Organization.

Let’s try to do that programmatically now. Check the list of commands for AWS organizations. There’s one called register-delegated-administrator.

At this point it looks like we need a service principal, which as you may recall from the last post was an IAM role:

What is interesting about this command is that it does not seem to have the option to create a restrictive policy the way we did here in the AWS Organizations settings:

Is that command serving our intended purpose? It’s not clear.

Well, if you recall, in the post before that one I had to reverse engineer how to create a delegated administrator policy for governance from the information in CloudTrail.

That’s because the only example AWS provides is for a backup administrator and that’s not what I was trying to create:

Perhaps we can use the above command to automate the deployment of the backup administrator policy for our deleted governance administrator policy.

aws organizations put-resource-policy --content  [policy]

Recall that I formulated this policy in the prior post and applied it manually to my organization via the settings option in the console:

{
 "Version": "2012-10-17",
 "Statement": [
  {
   "Sid": "ViewAWSOrganizationsResources",
   "Effect": "Allow",
   "Principal": {
    "AWS": "arn:aws:iam::XXXXXXXXXXXX:root"
   },
   "Action": [
    "organizations:DescribeOrganization",
    "organizations:DescribeOrganizationalUnit",
    "organizations:DescribeAccount",
    "organizations:DescribePolicy",
    "organizations:DescribeEffectivePolicy",
    "organizations:ListRoots",
    "organizations:ListOrganizationalUnitsForParent",
    "organizations:ListParents",
    "organizations:ListChildren",
    "organizations:ListAccounts",
    "organizations:ListAccountsForParent",
    "organizations:ListPolicies",
    "organizations:ListPoliciesForTarget",
    "organizations:ListTargetsForPolicy",
    "organizations:ListTagsForResource"
   ],
   "Resource": "*"
  },
  {
   "Sid": "DelegatingAllActionsForServiceControlPolicies",
   "Effect": "Allow",
   "Principal": {
    "AWS": "arn:aws:iam::XXXXXXXXXXXX:root"
   },
   "Action": [
    "organizations:CreatePolicy",
    "organizations:UpdatePolicy",
    "organizations:DeletePolicy",
    "organizations:AttachPolicy",
    "organizations:DetachPolicy",
    "organizations:EnablePolicyType",
    "organizations:DisablePolicyType"
   ],
   "Resource": "arn:aws:organizations::*:policy/*/service_control_policy/*"
  }
 ]
}

Let’s try using that policy, but replace the xxxxxxxxxxxx values above with your new governance account.

Now it’s at this point where I cannot get the above command to run in AWS CloudShell. I’ve been trying for a while. I don’t know if it’s CloudShell, a problem with the AWS documentation, or something else.

I’m copying the command exactly as it is written in the documentation and copied the policy that worked in my other account and changed the account numbers. I tried a number of variations and have spent too much time on this already so I’ll have to try again later or just manually add the policy the way I did in my previous blog post. I can still check the policy into source control even though I had to apply it manually.

Update: AWS appears to have created a way to deploy this using CloudFormation since I wrote this. I’ll show you how to deploy your organizational resources using CloudFormation in upcoming posts and will add that to my GitHub repository associated with this blog.

Add MFA to the Root User in your new account

There’s a lot of other things we can do to further protect new accounts by default as they get created, but for now, add MFA to the root user of your new governance account. You need to logout of the account you’re in or go to a separate incognito window. Login with the root email for your new account but click the forgot password link. Login and reset the password and add MFA to the root user.

Back to Okta

What next? I was looking at Okta. Now that I have this new account structure perhaps I can look at Okta a bit more and see if it makes sense to use it and how it maps to AWS constructs like the organization, accounts, OUs, users, roles, and groups. I want to create my governance user in the governance account and figure out how IAM administration will work if I use the external IdP.

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