Deploy a Cross Account Role that Requires MFA Using CloudFormation

ACM.210 Using default organizations role deploy a trust policy allowing users in one account to assume a role in another

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

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

🔒 Related Stories: Cloud Governance | IAM | AWS Security

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

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

In the last post I looked at some issues with KMS policies. But that was kind of a rabbit hole. On to something more useful.

Prior to that, I created some functions to assume cross account roles.

Create a cross account role with MFA for cross-account deployments

In this post I’m going to create a cross account role that can deploy resources in a target account, but that requires MFA, unlike the default AWS Organizations policy.

Deploy from an account other than the root account

We’re also going to deploy from an account other than the AWS root management account, since that account is not governed by SCPs. I am going to use the SandBoxAdmin user SandBox account to deploy resources into another account.

Except …the Initial CrossAccount Role using the default Org admin role

But in order to deploy our new role, we have to start somewhere. When you deploy a new organization and an account in that organization, what you have to work with in terms of automation is the default AWS Organizations role in each new account.

We will use the OrgRoot user we created in the management account to assume the organization role in two accounts and create an AWS CLI profile for each account using a common organizations role profile function (added in this post).

Deploy SandBox Admin, Group, Role in Sandbox Account

Then we we will use the AWS CLI profile for our SandBox account to deploy a RemoteAdmin group that has permission to assume a cross account role in the target account. We will add the SandboxAdmin user to the group. This allows the SandboxAdmin user to assume the cross account role.

Then we will get a list of users in the RemoteAdmin group using the Sandbox AWS CLI profile. We can pass that into our existing Group Role CloudFormation template the same way we did for users in the same account as the deployed role. Then we will use the second CLI profile to deploy a role in the target account.

Recall that our generic group role template deploys a role that requires MFA. After we create the cross account role, we will deploy an AWS CLI profile for the cross account role that requires MFA and test it.

How a trust policy to assume a cross-account role works

What do we need in place to allow someone to assume a cross account role? The trust policy needs to allow the principle in a remote account to assume a role. I’m going to be very specific about which principals I allow to assume the role.

What does our assume role policy look like currently in our CloudFormation template?

Remember we are looking up users in a group in the current account, obtaining a list of users, and allowing them to assume the role in the trust policy.

A cross account role works essentially the same way, except that we need to look up the users in a role in one account, and then assign those users to the role in the other account. Here are the changes I made to make that work.

Creating a Remote Admin Group to use the cross account role in the SandBox account

For this test I’m going to create a RemoteAdmin group in the Sandbox account we’ve been using for our testing. I’m going to add the SandboxAdmin to the RemoteAdmin group in that account. Simple enough. We just did that for our KMS admin group.

The code to create the group remains almost the same. The only difference is that we need to add the option to pass in a role ARN for a remote account to use in the group policy.

[NOTE: I updated the policy for the group in the next post to allow users of the group to assume the role in the remote account. This involved an optional account parameter passed into the policy template.]

Add the Remote Admin Group Policy to the Remote Admin Role

I’m going to need to add a policy for the Remote Admin Group Role. This policy is very broad and would like to restrict it further but for now it looks like this. The RemoteAdmin Group should not have permission to modify their own role in this case but you’ll need to test that. I haven’t actually tested it yet.

Add the SandBox Admin to the Remote Admin Group

I’m going to use the same function call to add the RemoteAdmin Group and add a user.

Note: this code is not all in my GitHub repo

In this case, I’m testing the code from a separate code base as I explained in another post as I don’t want all the code to become part of the framework. I will add some of it in later posts.

Role Switching Functions

I created a function that switches roles within the my framework. It does this by:

• Switching to the directory that has the code I want to run
• Sources it
• Sets the appropriate role profile that has necessary permissions
• Once the role profile is set I can execute the functions in that directory

In other words, if I want to create a KMS key, I can change to the KMS directory, source the code, and assume the KMS role. Then I can deploy KMS keys with the assumed role.

In this case, I want to create a group so change to the IAM Group folder, source the group functions, and set the appropriate profile. Then I can I call my the IAM functions.

This code below changes to the IAM Group folder, sets the profile to SandBoxAdmin which on my EC2 instance has the neccessary permissions to run the code I want to execute in the Sandbox account.

Create the RemoteAdmin group

Now I can call my group creation code in the usual way, calling the deploy_group and add_users_to_group functions.

Verify the group exists:

And that the SandboxAdmin user is a member of the Group:

Function to create an AWS CLI profile for roles we need to assume

We need two different roles for what I’m about to do:

Account A has the users assuming the role.

Account B has the role the users will assume.

• A role in account A has permission to query the users.
• One role in account B has permission to deploy the cross-account role.

Two different accounts, so two different roles.

For each role I want to create a role profile in my AWS CLI configuration to assume the role using a role profile.

Recall that I created a function to create a role profile for the AWS CLI for our organizational role. A role profile is used to assume a role.

I’m using the aws set configure functionality described in this post:

In a reusable function:

You can find the whole function and explanation in this post:

That function has undergone some changes to make it more flexible and to include MFA:

I can call this function to configure the AWS CLI with whatever roles I need.

I think I initially tested the last function in CloudShell, which has temporary credentials in environment variables, if I recall correctly. Now I’m run scripts on an EC2 instance.

I noticed this time around while testing I did need to check the existing profile for the region.

A function to deploy a cross-account role

I created a common function in organization_functions.sh file to deploy the role. Remember the AWS Organizations cross account role does not require MFA:

A function to get the default organization admin role name

I created a function to retrieve the organizations admin role name for an account since we need it in a couple of places now. Recall that we are not using the default AWS role name when we deploy our accounts. Since we control the name or role we can create a function to retrieve it using the same logic. Perhaps I should change the code that sets the role name to use this same function so we don’t end up with a mismatch later.

Cache the OrgPrefix value retrieved from Parameter Store

I added a local variable to store the OrgPrefix and only retrieve it again if not set to save us a few hits on AWS Parameter Store.

Test the role profile that leverages the default org admin role

I tested out creating an AWS IAM account org admin role profile like this (in the same directory as the organization_functions.sh file:

That worked.

If you want to very first check the aws config file and you’ll see the new profile at the end:

cat ~/.aws/config

Then check the aws credentials file and you’ll see that the temporary credentials are set:

Run the aws iam list-roles command with the new profile:

It works!

Create remote and target account role profiles for the two roles

I explained above that we need two role profiles to assume the default Organization role in two accounts: account A (the account containing the users that assume the cross account role) and account B (the account that contains the cross-account role).

Now that we know that function to assume the default Organization cross-account role works, I can use it in my deployment script for the cross account role in account B.

I added the Organization directory to the role switching function:

I use my function to create two organization role profiles for the two accounts where I want to deploy resources.

Refreshing credentials when assumed role session times out

Eventually the session that provided the temporary credentials for the assumed role will time out. When the session times out, the OrgRoot user can run the command to create the CLI profiles again to refresh the credentials.

Function to create a cross-account group role

Next I copy and paste the function that creates a group role and modify it to create a cross account group role. As noted the roles are essentially the same with the exception of the trust policy, which allows users in an external account to assume the role.

The code only needs a few adjustments.

1. I pass in the two profiles.
2. I use the first profile to get the list of users in the group in account A
3. I use the second profile to create the role in the account B, passing in the users in the remote account that are allowed to assume the role.

To call this function I need to switch over to the IAM Role directory and call the function with the OrgRoot user.

It is at this point where I get frustrated with two things.

1. Why must a CloudFormation stack start with a letter but an S3 bucket and other resources can start with a number? This makes no sense.
2. It’s too much to track which profiles should get IAM capabilities. That’s what SCPs, Permission Boundaries, and IAM roles should be doing, not CloudFormation.

I created a hokey work around for #1 and put an ‘a’ in front of any stacks that start with a number.

I gave all stacks IAM capabilities. Will probably delete some of these comments later.

OK now I can run the deploy script I created and test that it correctly deploys my cross account role and policy in the target account using the two role profiles.

And it does. We can list the role and take a look at the details, such as the trust policy, to make sure they are correct.

aws iam list-roles --profile [org admin profile]| grep Remote -A20 -B20

Create a role profile to use the new role

Next I repeat the steps above to create a new role profile to use the role in the target account.

Recall that I added my SandBox user to the RemoteAdmin group and members of that group have permission to assume the role.

I have a profile named SandBox configured for the AWS CLI for my SandboxAdmin user which I can use to create the nw role profile. The profile has a mfa_serial configured so the profile can use MFA when required.

I’m not assuming an organization role so I’ll use the shared function directly.

This role requires MFA so I have to get the MFA serial number to pass to the function. My user has more than one MFA device so I need to list and select the MFA device to use.

The following command will list the MFA devices for a user:

aws iam list-mfa-devices --user-name $remoteAdminUser \
 --profile $profile --query MFADevices[*].SerialNumber --output text

I’ll ask the user to copy and past in whichever device they want to use. I could make this nicer but everything takes so long. Have to get other things done.

OK run that and we get the following.

What’s the problem?

The user ARN is correct. I can verify that with the following command.

I already listed and reviewed the remote role. Recall that the trust policy requires MFA.

Take a look at the command we are using to assume the role.

Check the documentation for assume-role:

We need to pass in a serial number and a token (MFA code from an authenticator app):

Using the following command line options:

We only want to pass these values if an MFA serial number is provided.

Here’s the updated code:

Now when you run the deployment script, first you enter or copy your MFA serial number, then you’ll be asked for a token.

And it works! You can check that the role exists by running the following command:

aws configure list --profile RemoteAdminGroup

You can also look in the config file to see that the profile has been added to the end:

cat ~/.aws/config

Now I have a profile to run commands in the remote account and the role requires MFA.

I mentioned in a prior post that we might want to create a safer AWS Organizations role.

This post shows you how to create an administrative role in an account in your organization that requires MFA. You can replace the existing AWS organizations roles with roles that require MFA for additional security. I will eventually add that for all new accounts but for now I have to move on to a couple of other things that are costing me money unnecessarily.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2023

The best way to support this blog is to sign up for the email list and clap for stories you like. That also helps me determine what stories people like and what to write about more often. Other ways to follow and support are listed below. Thank you!

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
Author: Cybersecurity for Executives in the Age of Cloud
Presentations: Presentations by Teri Radichel
Recognition: SANS Difference Makers Award, AWS Security Hero, IANS Faculty
Certifications: SANS
Education: BA Business, Master of Software Engineering, Master of Infosec
Company: Cloud Penetration Tests, Assessments, Training ~ 2nd Sight Lab

Like this story? Use the options below to help me write more!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
❤️ Clap
❤️ Referrals
❤️ Medium: Teri Radichel
❤️ Email List: Teri Radichel
❤️ Twitter: @teriradichel
❤️ Mastodon: @[email protected]
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab
❤️ Buy a Book: Teri Radichel on Amazon
❤️ Request a penetration test, assessment, or training
 via LinkedIn: Teri Radichel 
❤️ Schedule a consulting call with me through IANS Research

My Cybersecurity Book: Cybersecurity for Executives in the Age of Cloud