Q: You are attempting to decrypt a file which you have already successfully encrypted using your CMK, however when you try to decrypt you are not authorized to do so. Which policy should you check?
Marked as correct:
- The IAM policy attached to your user
What is THE MOST correct (which is said to be wrong in the quiz):
- The CMK Key policy
"Access to use KMS CMKs is controlled by the Key Policy which defines who the key users and key administrators are, and also the user’s IAM Policy which defines which API calls the user is authorized to perform. In this case, the user does not have permission to call the kms:Decrypt API. Further information: https://docs.aws.amazon.com/kms/latest/developerguide/iam-policies.html#iam-policy-example-encrypt-decrypt-specific-cmks"
Looking into the source page provided one can read:
Important: Some of the permissions in the following policies are allowed only when the CMK’s key policy also allows them.
To conclude, CMK Key policy dictates what action one is entitled to perform UNLESS the key policy activates IAM permissions by giving permissions the root in the Key policy.
AWS has resource based and user based permission policies. The permissions in are evaluated together- either must explicitly allow.
KMS is little bit unique – it must specifically enable IAM permissions. (not the case with other resource based permissions)
KMS enables IAM by allowing it user’s root account. you would typically allow all to root, it is further delegated to specific users suitably:
In this case since the user can encrypt so the IAM permission has been enabled in the KMS policy. But as the user cannot decrypt – it must be an IAM policy issue not KMS policy issue.
There is no evidence at all that this key was enabling IAM permissions. The Key policy can be something like:
Principal: aws: - John Doe actin: - kms:encrypt
Also, from a security point of view I would do exactly the opposite of that "you would typically allow all to root" since this opens a major door for privilege escalation.
Allowing All to root is the recommended way. Root has all privileges any way – so nothing is getting escalated.
Well here is the caveat, Root does not have permissions to use or managed a customer CMK unless you explicitly provide it within the key policy. I suggest you to run a couple of tests in some AWS account and you will see on your own.