The new key policy will not allow you to update the key policy in the future
This error message incorrectly states you will not have permission to update the Key Policy and restricts ability to leverage segregation of duties
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⚙️ Check out my series on Automating Cybersecurity Metrics | Code.
🔒 Related Stories: Bugs | AWS Security | Secure Code | CloudFormation
💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I’m using a template I have used many times before. The only difference in this case is that I’m using a profile to perform a cross-account deployment. I want to deploy a key and make another user the administrator of the key.
I get this error:
![](https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*9j_e797uTpvjdE2Me_bAjQ.png)
Let’s review the permissions:
- The KMS Admins role is deployed in a sandbox account.
- Members of the KMS Admins group can assume the role.
- The role has the necessary permissions.
![](https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*lcnG3yRD89cNegSL4tZEFw.png)
- The Sandbox admin is a member of the KMS Admins group.
- The Sandbox admin user is in the trust policy for the KMS Admins group role:
![](https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*7ZMEe_dO5xYGLO403wh5HA.png)
- The Key is not an OrgRoot key so these permissions apply:
![](https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*CGR5D9O6SAWYQKLiiN-GYA.png)
- The above permissions give the KMSAdminsRole permission to run the required command: PutKeyPolicy
![](https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*vVE_C_yrIcJEc9wL2BsvEw.png)
- I’m running this template with the credentials of the SandBox admin role.
- There is no deny statement in the key policy for the PutKeyPolicy command.
What I realized is that the Sandbox administrator role cannot assume the KMS key policy, but I don’t want that role to be able to assume the role that can modify the key policy!
The logic behind this error message is faulty and it needs to be removed. It causes more problems than the one it is trying to solve. If you want to leave in this policy you need to check that the user deploying the key has permissions by way of an alternate role.
However, I think this check should be removed. It limits the ability to create zero trust policies and segregation of duties.
I found this post on the topic:
One safety check confirms that the principal in the key policy has the required permissions to make the CreateKey API and PutKeyPolicy API.
This check is faulty logic for the following reasons:
- You might want to allow someone to ADMINISTER a key who does not have permission to CREATE a key. But that person is allowed to administer a policy on an existing key.
- Also, as shown above, the one creating the key is not always the one deploying the template but may still have permissions. Now I have to go through the rigamarole of setting up yet another profile for my KMS admin role to deploy the key when I’m already using credentials that have permission to administer the key.
AWS might want to reword this:
When you create an AWS KMS key using AWS CloudFormation, choose the same IAM user or role that’s the key administrator principal for the AWS KMS key.
to this:
Use the same principal for the key administrator in the policy that you use to execute the CloudFormation stack that creates the key.
That is clearer and it was not entirely clear in the documentation the last time I read it. Perhaps it was buried in there but should be more blatant. But as I said, I think this error check is faulty and actually reduces security.
Also be clear on who actually has permissions to access and manage the key when you assign “root” as the administrator of the key. The above post does not clearly define this and people may misunderstand what happens when you make “root” in an account the administrator of a key. Every single place you write about that should define what that actually means.
I wrote about it in my blog series where I opted not to use the root ARN.
Follow for updates.
Teri Radichel | © 2nd Sight Lab 2023
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
![](https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*4oxP4LXk8l8c3mpRvO7ejg.png)