Assume the Organizations Role in the Sandbox Account

ACM.206 Using the role created by AWS Organizations to update an account in an organization

Part of my series on Automating Cybersecurity Metrics, IAM, and AWS Organizations. The Code.

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

I posted a couple of posts out of order. I’m adjusting the numbers but for people following along this was the last post where I deployed a Sandbox Administrator in a Sandbox account. In order to do that, we are going to assume the AWS Organizations role create when the account was deployed.

I used CloudShell initially to run some scripts in my AWS management account to get started. I wrote about why I’m trying to move away from CloudShell here:

Remember I mentioned I want to “quickly” migrate some data so I can close down another account. Well I’m not that quick because too busy to work on this full time but my scripts should help anyone trying to be more quick in the future.

The first thing I need to do is to be able to assume a role and run scripts in my new Sandbox account so I can deploy resources. I wrote about the Sandbox account I created here.

The Sandbox user will be an administrator in the sandbox account for now. I want the sandbox user to be able to create and use EC2 instance so I can use that instead of CloudShell.

Okta or AWS IAM?

For this first cut I’m going to simply create an AWS IAM user. There are a few things I haven’t finished setting up or testing in Okta. I’ll get back to that later and show you how to do some of the same things I’m doing with Okta with my AWS IAM user.

Assuming the AWS Organizations cross-account role

I showed you how you can use the AWS Organizations role that comes by default with AWS Organizations here.

There are some roles that are created as Service Linked roles when you create an AWS Organizations account.

I explained the risk of service-linked roles here — they are not governed by your Service Control Policies:

However, if you take a look at the cross account role created by AWS organizations for accessing another account, it is not a service-linked role, thankfully.

If you created an organization without changing the role name it will be “OrganizationAccountAccessRole” as shown below.

If you have been following with my scripts, the role name will be the organization [prefix] you selected followed by “-[name of account]”.

Let’s write some code to assume that role.

First I’m going to make a Sandbox directory in my Org folder and navigate into that folder. [Note that I moved the functions to assume the role to /Functions/shared_functions.sh in the GitHub repository eventually.]

Next I create and edit a deploy.sh file:

vi deploy.sh

First I can retrieve the Sandbox account number from the outputs of the account I created. Click on the stack name in the CloudFormation list of stacks.

Looks like I could give the key a better name in my account template. But we can use the Export name below.

Add the script to retrieve the export value as we’ve done before using the common function. I’m going to output the account number to make sure my code works.

Execute the file and you should see the Sandbox account number as output.

Next use the command I showed you in the above post to assume the AWS Organizations role in that account.

Note that we changed the default role name so we’ll need to adjust the code accordingly and pass in the SandBox account number

We formulated our role name by using the value of a secret we named OrgPrefix, a dash, and the name of the account.

We can get a secret using the following AWS CLI command:

We can filter the secret output to get only the value:

We’ll use text output to remove the quotes from the value:

--output text

I’ll the the code up to that point and output the role ARN to make sure it looks correct.

Seems to work. Now try to assume the role.

Error. OrgRoot user does not have permission to assume that role in that account.

An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::xxxxxxxx:user/OrgRoot is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::xxxxxxxx:role/Sandbox-xxxxx

Recall that our Sandbox account is under our Root account and OU. The Governance OU blocks the root user but the other OUs do not. So we can login using the root user and take a look at the role in the Sandbox account. We don’t want to have to do that in a production account — but since we have a Sandbox outside of our governance SCP we can do that here — without changing our SCP or putting production resources at risk.

If you don’t remember the root email for new accounts you can take a look at the code we wrote to formulate that or click on the account in AWS Organizations and look at the email. Then follow the steps to change the password.

Login with the root email and click the link to reset the password.

Now at this point I had to go through all manner of hijinks to get the password reset. Ultimately I had to completely clear my browser. Somehow AWS also got me to remove the MFA from a completely different AWS account with the same domain before the password reset worked. Not sure what is going on there or if I typed something wrong. In any case, I got it reset and logged in.

We also need to add an MFA device while we’re in here.

Then we can take a look at the roles that exist in IAM.

When I login, I do see that there’s a role with that initially looked correct to me. I’m going to copy the role to make sure the ARN is generated correctly.

I also took a look at the trust relationship and it allows the root user of the AWS Organizations management account. The OrgRoot user is an administrator and this account was able to assume the organization role in my prior post above. I’m going to copy the trust policy of the role just to verify the account numbers are correct when I get back into the management account.

Role:

Trust policy:

Alright let’s log back into our management account.

Navigate to the OrgRoot user and as you can see this user has the default AWS administrator role. I can see that the account number matches what I saw in the trust policy.

Aha. I eventually noticed that my mixed up brain function occurred again. I have the prefix and account name reversed. You can see that the role is Sandbox-[prefix] when I formulated it but the actual name is [prefix]-Sandbox. That’s why having a Sandbox for testing is helpful (and so is copy-paste whenever possible).

So now I’ll fix that and try again.

And it works!

Now this is one way to assume a role. After role assumption, the credentials exist in environment variables and you can run commands via those credentials. But I’ll show you some other methods that worked better for me using role profiles in the next post. Some complications occurred because my code is expecting a profile when running CLI commands. I could use the “default” profile but then my resources wouldn’t be named correctly. I’ll show you how I fixed that.

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