An AWS Organizations Admin in a Non-Management Account

ACM.405 Setting up a user and roles to manage an AWS Organization from outside the management account with a cross-account role

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

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

🔒 Related Stories: AWS Organizations | AWS Security | Secure Code

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

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

In the last post, I tested assuming a cross account role with MFA in the new orgadmin account I created.

In this post, I am going to deploy a root-orgadmin user and a root-orgadminrole in the account I created called root-orgadmin (now called root-org.)

Because of AWS account closure issues again when I wanted to rename the AWS Organizations role in that account (which you can’t do) and the fact that I don’t want to change my naming convention again, I had to rename my orgadmin account to just “org” to get around the email issue in this post.

So anyway, got it working with an alternate account name: root-org.

I changed the role name to not use the organization name so I can name my role folder generically and check it into my public GitHub repository.

I also decided that I would like to keep it consistent with the environment admin role. So in other words:

• In the root environment the organizations cross-account role is the rootadminrole.
• In the prod environment the organizations cross-account role is the prodadminrole.
• In the nonprod environment the organizations cross-account role is the nonprodadminrole.

If you were to add other environments where you wanted a segregated administration role you can use the scripts and templates I’m about to show you to follow the same naming convention.

The role is output in the account cloudformation stack:

Moving over user_functions.sh from the POC codebase

I can reuse our method of creating a user above. I copy over my user_functions.sh file which already has a deploy_user function:

Deployment script

I add that to my deployment script:

With a few tweaks to my local test script that runs the container that requires MFA to execute a job, I was able to deploy the orgadmin user in the root-org account.

Tweaks to the local test script

I realized I had an issue I’ll need to sort out later when I went to execute the above script.

Due to my MFA enforcement in my SCP I created, the role I’m using to emulate a role profile on an EC2 instance assuming a role also has to use MFA to assume a role.

I’ll need to tweak my policy later to account for this so EC2 instances can obtain job credentials from Secrets Manager, or make some other adjustment such as passing in an MFA code for the EC2 instance role and for the container role. We’ll deal with that later.

I had to add some code to get the proper account number for the mfa_serial of the account that is simulating the EC2 role.

Once I did that the user script ran fine and I got a new root-orgadmin user in the root-orgadmin account.

That script I just described and showed an early version of in a prior post is a bit ugly at the moment. I’ll provide it after I clean it up a bit more.

What the orgadmin user needs to be able to do

Here’s what I want the orgadmin user to be able to do:

• Manage its own MFA device, password, and developer access key and secret key.
• Read-only access to Parameter Store in the management account to get the parameters used to create new accounts.
• Use a cross-account role in the management account to perform organizations functions such as creating accounts, organizational units, and delegating administration to other accounts.

I’ll write about and add this in a separate post:

• Assume cross account roles in the accounts this user creates and configure them.
• Access Secrets Manager in the root-org account to get credentials to assume job roles.

I may need to add more later but we’ll start with that.

IAM policy for the root-orgroot user in the root-org account

Here’s my policy for the root-org user in the root-org account.

Note that unlike the service control policy where I had to perform all kinds of tricks to apply a policy to a policy because I couldn’t reference the name before the policy existed. In my example below, I know what I am going to name the role in advance and I can create the policy before the role exists.

Note: I had to add a few things to this policy upon further testing.

Listing Users and MFA devices is no longer possible with a user-specific policy:

I allow these without MFA:

However now MFA is enforced by an SCP for all but non-MFA allowed actions as explained here:

I also had to add some virtual MFA actions and not to the actions restricted to a user because those actions do not include a user resource as I explained in a prior post in more detail. (I think they should.) But I can limit the user to only creating and acting on an MFA device that matches its own username.

A role in the management account for AWS Organizations actions

Even when I set up my org-root account as a delegated administrator, it didn’t have the permission I need to create new accounts and organizations. It appears those actions still must be taken in the root account but we can do so with a cross-account role.

Unfortunately, our Service Control Policy that enforces MFA will not apply since to role assumption in the Management Account.

That’s ok because we can enforce MFA in the trust policy and the user’s IAM Policy above. I explained all those things in prior posts.

Here’s the code to create the root-orgadminrole with a trust policy, and an IAM role policy in the management account that can be assumed by the root-orgadmin user in the root-org account.

resources/iam/role/role.yaml

The role template is the generic role template from the proof of concept code with a few modifications to align with new conventions.

resources/iam/role/role_functions.yaml

The generic role deployment function gets a few tweaks to add the environment and align the parameters with the new deploy_stack function, and rearranged variable validation.

deploy/rootadminrole/iam_role_orgadminrole.sh

I look up the user’s account number to add the user to the trust policy. This seems much simpler than what I was doing with cross-account roles. Maybe this will work for other things as well.

Role Policy

Next I add the role policy. I start with the rootadminrolepolicy and make some modifications. The root-orgadmin can do almost anything in AWS organizations with a few exceptions. I’m not sure if I will leave it this way but for now the orgadmin can also create roles in the root account with the required IAM permission boundary.

This role also needs to be able to deploy CloudFormation stacks that are prefixed with “root-orgadminrole-”. I wrote about that here:

While writing this code, thank goodness for my own error message documentation on Medium for all the things I forget like what causes this nonsensical error message about legacy parsing.

Hopefully that and other similar CloudFormation Error Message and Troubleshooting posts are helping other people save time as well.

Anyway here’s the policy:

resources/iam/rolepolicy/root-orgadminrolepolicy.yaml

Here’s the function in the functions file:

resources/iam/rolepolicy/rolepolicy_functions.sh

Here’s the deployment script:

deploy/rootadminrole/iam_rolepolicy_orgadminrole.sh

There’s one more thing I want to add for this user and that is credentials to assume cross account organization roles outside the management account. I’ll add that after I test out creating OUs and Accounts with this new user and the associated role and policies.

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