Summary

The article discusses a misleading AWS KMS key policy error that hinders the implementation of zero trust policies and segregation of duties by incorrectly suggesting that future updates to the key policy will not be permitted.

Abstract

The author of the article encounters an error when attempting to deploy a KMS key with a cross-account deployment template, which incorrectly implies that future updates to the key policy will be restricted. This error occurs despite the deployer having the necessary permissions to administer the key policy. The article explains that the safety check within AWS that triggers this error is based on faulty logic, as it assumes the principal creating the key should also be the one with permissions to manage it. The author argues that this check should be removed to allow for more flexible and secure key administration practices, such as zero trust policies and segregation of duties. The current error message leads to unnecessary workarounds and does not align with best practices for key management and security.

Opinions

The author believes the AWS error message regarding key policy updates is incorrect and causes unnecessary complications.
It is the author's opinion that the AWS safety check that triggers the error is flawed because it does not account for scenarios where different principals have distinct permissions for creating and administering keys.
The author suggests that AWS should reword the error message to clarify that the principal deploying the CloudFormation stack should match the key administrator principal in the policy.
The author advocates for the removal of the current safety check to enhance security through zero trust policies and segregation of duties.
The author emphasizes the importance of clearly defining administrative permissions when "root" is designated as the key administrator to avoid misunderstandings.

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:

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.

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:

The Key is not an OrgRoot key so these permissions apply:

The above permissions give the KMSAdminsRole permission to run the required command: PutKeyPolicy

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:

Resolve the "The new key policy will not allow you to update the key policy in the future" error

undefined

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.

Automating Cybersecurity Metrics (ACM)

A series of blog posts on cybersecurity metrics and security automation

medium.com

Follow for updates.

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