Using an AWS CLI Profile with MFA

ACM.28 Testing our KMS Administrator Permissions with the AWS CLI

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

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

🔒 Related Stories: IAM | Secure Code | AWS Security

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

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

In the last post we deployed a KMS key policy with CloudFormation. Now we want to create a CLI profile to use the roles that can interact with our KSM key as allowed by our key policy.

You may have used a role profile with MFA before. I certainly have, but I use MFA a bit differently than the way I used it in this project from the way I used MFA with role profiles in the past.

When I started using MFA to test some code I developed, I hit a number of road blocks and spent a fair amount of time troubleshooting issues below due to error messages that did not tell me exactly what the problem was.

The ultimate source of the primary error message started in another post. I thought I had resolved the problem by fixing some syntax errors in a CloudFormation template, but that was only a partial resolution:

Strange edits to a KMS Key Policy

This all started when I wanted to test use of my KMS key for encryption and I noticed that one of my ARNs in my key policy was edited to some strange value. I still don’t know what caused that. I didn’t deploy that value, but whatever the cause, I redeployed the template for the key policy and it was fine again.

I had already decided that at some point I was going to remove extraneous users I temporarily added in the above post and use the key administrator to deploy keys as was my original plan away. If you recall I was allowing the user I initially ran the script with to be a key administrator, and the root user:

After removing those two users from my key policy I had all kinds of problems deploying my key and adding a key alias as detailed in this post:

One key point in the above trial and error troubleshooting was that I could not enforce MFA in my key policy since I am using a role. The only reason that worked in my prior post was (I think) because I included the root user, which can pass the MFA indicator in a request as I explained in earlier posts. The role cannot.

I finally got all my policies working and deploying successfully, but part of the way I resolved the problems was by fixing the AWS CLI configuration when I wanted to enforce MFA In the policy to assume the role that was allowed to take actions on the key.

KMS Administrator User

In order to enforce MFA I have to have a user with an MFA device assigned. I created a KMS Administrator User via CloudFormation scripts in the iam directory of the GitHub repository. I added a policy to the user that allows it to execute the sts:AssumeRole to assume my KMS Administrator role but only when an MFA condition is met. To create that user in your own environment you can run the related deploy.sh script.

Assign a Virtual MFA device to your KMS admin user

Assign a virtual MFA device to your new user. I explained why I’m using a virtual MFA device in this post:

KMS Administrator Role Trust Policy

We earlier defined that KMS Administrator Role Trust Policy (AssumeRolePolicyDocument) in our CloudFormation template. We create a parameter to pass in the ARN of the identity that is allowed to assume that role. I’m presuming the users that will assume this role will be in created in the same account as the role in the template below and using an ImportValue to get the output from the CloudFormation stack that created the user.

You can deploy the updated KMS role in your environment by running the script in the KMS role folder:

Configure the AWS CLI profiles for our KMS User and Role

Instead of one AWS CLI profile, I ultimately had to create two to get this working. I’m not sure if you absolutely require two but this way I got better error messages and it worked.

Run the following command to configure a profile for your KMS User in your CLI configuration:

aws configure --profile kmsuser

Set your key id and secret key, region, and output. I added the ARN for my MFA device to this profile as well. You can get the ARN for an MFA device assigned to a user by navigating to IAM in the AWS profile. Then click on Security Credentials. You can find the ARN for the assigned MFA device where shown below.

When you run the aws configure command it updates a two files in your home directory. For some configuration items you need to manually edit one of the file. One of the things you have to add manually is the MFA ARN.

To edit the AWS config file that gets updated when you run AWS configure, type this command (on Linux):

vi ~/.aws/config

The above command presumes you are familiar with vi. You can edit that file with some other editor if you’re not. Note that you will not see that directory because it’s hidden and starts with a dot (.) if you type this command from your home directory:

ls

But you will if you type this command:

ls -al

So depending on your editor and whether or not it allows you to navigate to hidden files you may or may not be able to see it or open it.

More about command line configuration here:

After editing the config file to add the KMS User MFA device ARN, I added another profile named kms. I added the role ARN, MFA device ARN, and I used the kmsuser for the source_profile. Here’s my final configuration:

Replace the xx’s with the correct values for your resources and environment.

[profile kmsuser]
region = xxxxxxxxxxx
output = json
mfa_serial=arn:aws:iam::xxxxxxxxx:mfa/KmsAdmin

[profile kms]
role_arn=arn:aws:iam::xxxxxxx:role/KmsAdministrator
source_profile = kmsuser
mfa_serial=arn:aws:iam::xxxxxxxx:mfa/KmsAdmin

I highly recommend always copying and pasting ARNs rather than trying to type them because tricky typos that are hard to spot can take a long time to troubleshoot. For example, when I started writing this code the user name for the key admin was KmsKeyAdmin. I later changed it to KmsAdmin and forgot to update my profile. I’ve also spent hours not noticing that I didn’t have TWO colons (::) after iam in the above ARN. The error messages in such cases are not helpful. If you get errors double check every value in your configuration carefully for typos or missed changes.

Testing the kms profile

If you recall in our last post we were trying to deploy a KMS key. The script to deploy that key is the deploy_key_trigger.sh in the kms folder in the KMS directory. You can now to try to run the script with your AWS CLI kms profile.

The script requires three arguments:

Pass in the the following arguments on the command line:

• Encrypt Role ARN
• Decrypt Role ARN
• Role profile (kms)

You can find the ARNs in the outputs of the CloudFormation stacks we ran in earlier posts to create these roles.

./deploy_key_trigger.sh arn:aws:iam::xxxxxxxxxxxx:role/BatchRoleDeployBatchJobCredentials arn:aws:iam::xxxxxxxxxxxx:role/BatchJobTriggerRole kms

If your AWS CLI profile is set up correctly and you’ve deployed the prerequisites in prior posts, then that should work.

You’ll be asked to enter an MFA code prior to executing the above script.

Also note that I wrote about using MFA with an external ID here which we could add later if we deem it necessary.

Set up your IAM admin user and MFA

If you want to run all the test scripts in the the root directory of the GitHub repository (test.sh) you’ll need to follow the same steps as above to deploy the IAM admin user, assign virtual MFA, and configure the CLI.

There is one difference, however. Instead of having the IAM admin assume an IAM administrator role, we’re going to allow that user to assume the role for the batch job we are creating to deploy the BatchJobAdmin credentials. More on that in upcoming blog posts.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2022

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