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 LabNeed Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for PresentationFollow 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






