3 Answers
If you look into Key policy; it gives IAM entities permission to use, administer or delete the key but the granularity like permission to encrypt but not decrypt can be achieved only via IAM Policy.
You can try by editing Key policy but it fails when you try to add granular permissions.
I dont think this comment is correct. When you open your KMS CMK, you have what you mentioned but you can click the button "switch to policy view" where you can define granular actions.
This is definitely wrong. I just tried editing my policy and I was successful. I’m 99% certain I was able to do it even a year ago when I was deploying some KMS stuff
The AWS documentation is a bit confusing. On one hand you have this: https://docs.aws.amazon.com/kms/latest/developerguide/control-access-overview.html#managing-access
It literally states:
You can control access to your KMS CMKs in these ways:
Use the key policy – …you can use the key policy alone to control access, which means the full scope of access to the CMK is defined in a single document (the key policy).
Use IAM policies in combination with the key policy – … Controlling access this way enables you to manage all of the permissions for your IAM identities in IAM.
Use grants in combination with the key policy – … Controlling access this way enables you to allow access to the CMK in the key policy, and to allow users to delegate their access to others.
Then you also get a practical example of an IAM policy applying kms:Encrypt and kms:Decrypt within an IAM policy. See: https://docs.aws.amazon.com/kms/latest/developerguide/iam-policies.html#iam-policy-example-encrypt-decrypt-one-account
But then you have the API permissions reference which seems to imply that you can only use kms:Encrypt, kms:Decrypt and certain others only within key policies. See the table at: https://docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html
So, only one way to find out: let’s try it in the AWS Console. 🙂
The result: you can most definitely add Encrypt and Decrypt to an IAM policy. And you can also do this to a key policy BUT: the default setup is that KMS will create a default key policy like this:
{
"Id": "key-consolepolicy-3",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::000000000000:root"
},
"Action": "kms:*",
"Resource": "*"
}
]
}
Note that it explictly adds an Allow permission to the account root user for FULL management of KMS. You are free to change this but must then realize that you can theoretically lock yourself out from managing CMK’s. See: https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html#key-policy-default-allow-root-enable-iam
So: technically the correct answers are both A and D but realistically most users will setup KMS so that key policies are used to control CMK management whereas IAM policies would be used to control who does what with those CMKs.
"so that key policies are used to control CMK management whereas IAM policies would be used to control who does what with those CMKs." Absolutely not. When you try to control access to an S3 bucket, it’d be foolish to do it via only IAM. People often get s3:*. You need to be able to control at the resource level so you should be using bucket policies. Sames goes for KMS keys
"When the type is key policy, you can specify the permission explicitly in the key policy. Or, if the key policy contains the policy statement that enables IAM policies, you can specify the permission in an IAM policy." – I read this as saying that they key policy can be used to enable IAM policies to control encrypt and decrypt operations. IOW, the table by itself doesn’t tell you all you need to know about the scope of the permission.
I dont think this is fully correct. KMS CMK have editable Key policies (you can specify actions for principal in similar style like in other resource policies e.g. s3 bucket policy) so the correct answer should be both a) and d).