CloudFormation Key Template Fails: ‘Status’

Very strange results with different types of CLI profiles

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

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

🔒 Related Stories: Bugs | AWS Security | Secure Code

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

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

Using an EC2 instance profile I was able to run the following command:

The command works properly but fails with the following error.

Resource handler returned message:

The new key policy will not allow you to update the key policy in the future. Service: Kms, Status Code: 400

The key policy uses a specific role for the administrative principal.

I created a user with an associated virtual MFA device.

I created a profile for the AWS CLI using the the role_arn set to the key administrator role.

I ran aws configure and set the credentials to the roles for the user.

When I run the command above using the role profile I get:

That’s not exactly helpful.

To verify my profile works correctly I ran a command to check the identity.

aws sts get-caller-identity --profile kms

The results show an assumed role:

arn:aws:sts::xxxxxxxx:assumed-role/KmsKeyAdministrator/botocore-session-xxxxxxx

The assumed role matches the role in my KMS policy.

Initially I got an error about not having a source profile. I didn’t want to use the default source profile because that profile uses EC2 instance credentials not my user’s credentials. So I set the source profile to the profile itself.

Clearly that doesn’t work. What if I create a separate profile for the user credentials and the role? I created two separate profiles.

my ~/.aws/config now looks like this:

[profile kmsuser]
region = us-west-2
output = json
mfa_serial=arn:aws:iam::xxxxxxxxxxxxx:mfa/KmsKeyAdmin

[profile kms]
role_arn=arn:aws:iam::xxxxxxxxxxx:role/KmsKeyAdministrator
source_profile = kmsuser

In my .aws/credentials file I changed the profile name with the user credentials to kmsuser to match the profile with the mfa serial number in the config file above.

Then I got this error instead:

An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::xxxxxxxxx:user/KmsKeyAdmin is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::xxxxxxx:role/KmsKeyAdministrator

That’s odd. I just checked the trust profile of my role and this user has permissions to assume this role in the trust profile when using MFA.

However…let’s check the user IAM permissions again.

I had set the user permissions to the same permissions as the KMS key admin but did not give the user sts:AssumeRole permission. That’s not right. I need to remove the KMS admin profile and give the user permission to assume the KMS Admin role.

Weird, even after adding an IAM Policy with sts:AssumeRole for the specific role with MFA required, the user cannot assume the role.

I added the MFA serial number to the cli profile with the role in addition to the one with user credentials like this:

[profile kmsuser]
region = us-west-2
output = json
mfa_serial=arn:aws:iam::xxxxxxxxxxxxx:mfa/KmsKeyAdmin

[profile kms]
role_arn=arn:aws:iam::xxxxxxxxxxx:role/KmsKeyAdministrator
source_profile = kmsuser
mfa_serial=arn:aws:iam::xxxxxxxxxxxxx:mfa/KmsKeyAdmin

Now we’re getting somewhere. I got a different permission error and an indication that the user did actually assume the role successfully.

However, when I added the missing permission for TemplateGetSummary, I was back to the unhelpful ‘Status’ result.

What I noticed was that the CloudFormation template is actually deploying. The status is stuck at ‘Review in Progress’. Maybe my role is missing permissions to check the status of the deployment.

Let’s see what we can find in CloudTrail.

I don’t find any useful failed requests to help me resolve this.

What action might that be?

Once again I decide it’s easier to grant cloudforamtion:* because it’s too difficult to try to figure out which of the permissions my policy actually requires (for now).

After doing so I get an error for CreateKey even though my user clearly has permissions to Create a Key. However, since I’m using a role for this, perhaps the MFA condition is breaking the update now, even though MFA is applied to the CLI profile. Back to CloudTrail.

Sure enough, MFA is not in the CloudTrail record in the key specified in the condition:

Although someone tried to tell me MFA is present here, it’s not. Sure, I can backtrack to the user that initially assumed the policy to see if they used MFA but that doesn’t make my MFA authenticated condition work, because my condition looks at that key to determine if the request will be allowed or not.

Let’s validate this theory by removing the MFA condition from the admin role policy. Well, that must not be it. Getting the same error:

Resource handler returned message: “Access denied for operation ‘CreateKey’.”

Well, my administrator clearly has this permission in its IAM policy and the CloudTrail logs indicate that role is taking the specified action.

So I add the admin policy like any good developer would do, and there we go. The user now can run the CreateKey action, but it fails again on the “you are creating a policy that won’t let you update this in the future” even though the KMS admin is the one making the request.

Oh. Wait a minute. Hold up.

I had my region for my user configured incorrectly to the wrong region other than the one I’m looking at in the console. But wait. How is it even possible that my stacks are showing up in the region I’m in when my user is configured to deploy things in a different region? Nothing is hard coded to an alternate region in my templates.

Well I remove the admin policy and re-run the script and it doesn’t solve the problem anyway.

Finally I look at the policy in the UI. I notice a couple of warnings so I check and my policy is restricted to keys in the current account

So I add aliases as well. But that still doesn’t fix the problem, because the error messages say “CreateKey” is not allowed.

So I start to think about these resources and how can a CreateKey action take an action on a key that doesn’t exist yet. So I add a new statement for any Create action (Create*) and remove the resources. And it works.

But I still my error that says I cannot create the policy because I wont’ be able to update it — even though the role I’m creating the key policy with is the role in the policy.

Back to MFA. I’m requiring MFA. I want to use KMS in my key policy and require MFA, but now I’ve made a role the KMS key administrator. Roles don’t pass MFA but I have a user that assumed the role. Although I can get that to work in the CLI profile, it may be causing issues with my key policy. Let’s remove it.

YES. That was the other problem. Removing MFA allowed me to successfully deploy the key and policy.

Now I just have to resolve an issue with the key alias I’m trying to assign.

Resource handler returned message: “Model validation failed (#/AliasName: failed validation constraint for keyword [pattern])” (InvalidRequest)

That really unclear message means I am trying to assign a key alias that is not in the right format. Where can I find the correct format for a key alias since the error message is not every useful and doensn’t tel me?

The documentation isn’t very helpful (am I just not seeing it? maybe it’s there somewhere) but I can see from the example code that lowercase and dashes work.

Nope. Same error.

Insanity is setting in. I found this error message and fix for a different service — an AWS canary. It says the name has to be less than 21 characters so I changed my alias to 20 characters.

Ah yes, the requirements would be in the CloudFormation documentation obviously. The length is up to 256 so that wasn’t it:

Strange I don’t see anything wrong with my alias…

Found this page that tells me to do what I just did. This error message really should be more precise and it’s used all over the place.

Finally, I think I see it. I had scrolled pass the big “Note” box which is kind of a distraction and missed the very first line. Adding alias/ now. Can you not just tell me that my alias needs to start with “alias” in the error message and why anyway? Just add it for me.

Finally. Sheesh.

I wish that the error messages were a lot better so I didn’t have to dig around in documentation so much. It would save the world a lot of time if you could just write simple error messages that explain to people exactly what the problem is when possible.

This is what trial and error troubleshooting looks like when error messages aren’t exactly clear or precise as to how to resolve the problem that caused the error.

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