Line 74 is wrong about aws-kms-developer-guide HOT 5 CLOSED

Thanks. I'll look for words that more clearly express some of the principles. But aside from docs, I want to make sure that your policies are working as you've designed them.

The default key policy allows the account to use IAM policies to control access to the key, but it does not, by itself, allow any IAM user/role in the account to use the key in cryptographic operations (or to manage the key).

The following sentence is true. The user doesn't have to be specified in a key policy. They can get permission from a grant. Also, if (and only if) the key policy allows it, they can get permission from an IAM policy.

" ... with the default KMS policy in place, an IAM user (via a role or a local AWS user) does not need to be explicitly added as a CMK Key-user (and therefore inside the Key policy) to be given access to the CMK, if such is done through the IAM policy."

However, the default key policy doesn't allow any user to use the key in cryptographic operations. If you don't explicitly add a user to the key policy (as the console helps you to do) or give them permission a grant, and you don't attach/embed an IAM policy that delegates those permissions to the user, the user doesn't have permission to use the key.

Also, IAM policies alone can't give a user permission to use the key. The key policy must allow the account to use IAM policies. If it doesn't the IAM policies are not effective.

Are you seeing anything different in your testing?

from aws-kms-developer-guide.

Continued from the conversation in one of the PRs: #31

I really appreciate your raising the issue. AWS KMS permissions are complex because we try to make them very flexible, but it's easy to misunderstand, so I always check my answers against the code and only after checking with the engineering team.

In this case, I can confirm that the key policy is essential for controlling access to a key. Line 74 ("IAM policies by themselves are not sufficient to allow access to a CMK.") is accurate. Your example works only because the key policy gives the account permission to use IAM policies to control access to the key.

Here's the response to your issue from the KMS engineering team. Note that a grant can also control access to the CMK. I'll update the docs to include that information.

Key policies and grants control access to the CMK, full stop. If a key policy or a grant gives permission to any principal, then that principal may delegate its permissions to children beneath it. This is what happens when a key policy gives permission to the root account, thereby allowing the root account to use IAM policies to pass on permission to its IAM principals. The key policy has not lost control of the key in any way since the permissions are still rooted in it.

Many customers have key policies that do not have the default statement giving kms:* access to the root account. In the key policy, they list IAM principals that they want to have access. (This is popular because it makes it really easy to audit who has access to the key with a single GetKeyPolicy call and without having to dig through all of the IAM policies in an account. Such policies are not the default in KMS because they require more care to manage.

The console default policy indeed seems to employ both the strategy of giving access to the root account and giving access to individual IAM principals. It allows administrators to set up all the permissions they need for a key without leaving the KMS console, and it leaves in the safety/ease-of-use of having the default root statement. The console has had this behavior since the launch of KMS and it cannot be undone without breaking customers.

The documentation will not and does not diverge from describing this behavior. If you want to use a different policy template that better fits your use case, use the non-GUI policy editor or the API to put your own policy in place.

from aws-kms-developer-guide.

Thanks for your feedback.

Altering the default key policy is actually totally optional.

Regarding the point of listing IAM principals in the Key Policy (and changing the default statement giving kms:* access of the root account), it is a bit surprising, because the documentation itself mentions to be very careful with this: when defining a certain ARN (ex. an IAM user or role) and replacing root with it, it can render the CMK key useless if that role/user is removed/not used in the future.

Also, the general recommended behavior and consensus regarding control access in AWS, is to actually do so through IAM policies and Roles, not through modifying the specific resource/key policies of a certain AWS service (unless absolutely necessary). Just imagine if you have 100 federated users who need access to 20 different CKMs, what kind of management nightmare it would be to do so for BOTH KeyPolicies as well as through IAM policies and roles. And we have not even talked about KMS-generated DataKeys yet.

I think the main point of confusion is the fact that with the GUI-generated-Default KMS policy, and if its left unmodified, does allow to manage access to the CMK purely through IAM policies. This fact is not very clear or explicit in the documentation. Again, altering the default key policy is optional, not a necessity to use a CMK.

The other point, which is also related to the previous point, is that with the default KMS policy in place, an IAM user (via a role or a local AWS user) does not need to be explicitly added as a CMK Key-user (and therefore inside the Key policy) to be given access to the CMK, if such is done through the IAM policy. I think the point of adding Key-users and Key-admins in the CMK is to give maximum flexibility to customers, however, they are not mandatory, especially if the root-account default policy is left untouched (for the reasons outlined already).

I will leave the decision for you to make (or leave things as is) the above more clear in the documentation.

Thank you!

from aws-kms-developer-guide.

I did more testing.

First of all, this statement is not actually accurate or true: "Many customers have key policies that do not have the default statement giving kms:* access to the root account."

In fact, my testing shows that if we try to replace the default policy, to something like the below, it will NOT work:

{
"Id": "key-consolepolicy-3",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:user/TestUser"
},
"Action": "kms:",
"Resource": ""
}
]
}

and throws the following error (even if I am using the root-account user to do so):
PutKeyPolicy request failed
MalformedPolicyDocumentException - The new key policy will not allow you to update the key policy in the future.

That said, the following is possible:
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {"AWS": [
"arn:aws:iam::111122223333:user/CMKUser",
"arn:aws:iam::111122223333:root"
]},
"Action": [
"kms:"
],
"Resource": ""
},

But as you can see, the Account itself (arn:aws:iam::111122223333:root) still has full permissions.

In other words, I don't believe, based on my testing, that the root account ARN can be ever removed from a CMK.

Lets go back to the following sentence: Also, IAM policies alone can't give a user permission to use the key. The key policy must allow the account to use IAM policies. If it doesn't the IAM policies are not effective.

The "if it does not" part will never actually happen according to my testing, which means IAM policies alone will always give a user permission to use the CMK, as long as that user is allowed to do so in their IAM policy, and such will happen even if we dont add them as a Key User. If this holds indeed to be true, a lot of modifications in the KMS docs have to be altered, even beyond the ones I highlighted. Please test and confirm

Bug in production:
By the way, if the above policy is applied, the button "Switch to policy View" is completely gone. After that, we dont have any options available under the main CMK screen, and we can only "Edit" the policy. Once the policy is edited, allowing only the root account, everything goes back to normal. I can provide more info if needed.

from aws-kms-developer-guide.

Thanks again for your contribution. IAM policies cannot control access to a CMK unless the key policy allows it.

from aws-kms-developer-guide.