avatarTeri Radichel

Summary

Teri Radichel discusses a workaround for an AWS KMS issue where the service overwrites Key Policy Roles with incorrect values, causing access problems and potential lockout from key administration.

Abstract

The article addresses a critical issue encountered with AWS KMS (Key Management Service) where AWS inadvertently overwrites Key Policy Roles with incorrect values. This can lead to CloudFormation templates and stacks being out of sync, and administrators may be locked out of managing the keys. The problem is exacerbated by an unhelpful error message, "Access to KMS is Not Allowed," which does not accurately reflect the issue. Radichel's solution involves using an arbitrary output parameter, such as a timestamp, to force CloudFormation to update the key policy. However, this is not an ideal fix, as it may lead to unnecessary costs due to additional executions. The article suggests that AWS should not alter customer Key Policies without warning or disabling the keys until the issue is resolved. Radichel also promotes her series on automating cybersecurity metrics and invites readers to follow her for updates on cybersecurity topics.

Opinions

  • AWS's overwriting of Key Policy Roles with incorrect values is problematic and can lead to significant issues, including lockout from key administration.
  • The error message provided by AWS, "Access to KMS is Not Allowed," is misleading and does not help in diagnosing the actual problem with Key Policy Roles.
  • The workaround of changing an arbitrary output parameter to force an update is a makeshift solution and may result in unnecessary costs.
  • AWS should reconsider its approach to modifying customer Key Policies, possibly by disabling keys until they can be fixed or by providing a warning to customers.
  • AWS typically does not interfere with customer data, so the current practice of changing Key Policies is inconsistent with usual protocols.
  • The article encourages readers to engage with Radichel's broader work on cybersecurity automation and to follow her for ongoing insights and updates in the field.

Access to KMS is Not Allowed: Workaround

Overcoming the problem when AWS overwrites your KMS Role with a nonsense value

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

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

🔒 Related Stories: AWS Security | Application Security | CloudFormation

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

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

I’ve been working on this automation series and written about a number of issues with KMS that I hope AWS will fix. One is the fact that they overwrite your Key Policy Roles with a nonsense value if you delete or change a role.

This is a huge problem for multiple reasons:

  • CloudFormation doesn’t recognize that your template and stack are out of date and won’t update to the correct role.
  • You might be completely locked out of administering the key if the administrator role gets deleted.
  • You can an unhelpful error: “Access to KMS is Not Allowed” when trying to perform CloudFormation updates on any stacks that use that Key. That is not accurate because the IAM policy does allow access to KMS. The problem is that the key policy doesn’t have that role in it anymore. Since you see no other errors in your stack then it’s not immediately clear what the problem is.

In order to fix this problem with a number of coordinated templates I deploy together for my latest blog series, I figured out that if I change an arbitrary output parameter created solely to force an update then I can get key to redeploy even though nothing else has changed. The key policy references another CloudFormation stack output and so the template itself doesn’t change even when the other output changes.

I created a parameter to pass in a timestamp:

I output the timestamp to force CloudFormation to update:

Since AWS CloudFormation isn’t handling spaces correctly at the moment I stripped the spaces out of my timestamp and put quotes around it.

This is not a good solution because I’m potentially paying for more executions than I really need. AWS should really not be changing Key Policies on customers. Perhaps they can be disabled until updated and fixed or warn the customer somehow but don’t change customer policies. AWS typically doesn’t touch customer data so this is very strange.

If you want to read more about automated KMS creation and KMS policies check out this blog post series and the related code on GitHub.

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
Access To Kms
Is Not Allowed
Kms
Key Policy
Cloudformation
Recommended from ReadMedium