Understanding Key Policies
With many services that you use within AWS, you can control access using IAM policies whether that is against a user, group, role or even a federated user. The point is access control for most services can be completely controlled and governed by using
IAM alone. However, for KMS, this is not the case.
To manage access to your CMKs, you must use a key policy.
Without a key policy associated to your CMK, users will not be able to use it.
Permissions to allow you to access and use your
CMK can’t be given and generated using
IAM alone. As a result, there are a number of different ways in which you can control access to your keys in KMS,
- using just key policies
- using key policies with IAM, and
- using key policies with grants.
What are Key policies?
Key policies are resource based policies which are tied to your CMK. And if you want a principal to be able to access your CMK, then a
key policy must be in place to do so. The key policy document
itself is JSON based much like IAM policies are and the document syntax is much like other IAM policies. They contain elements such as resource, action, effect, principal and optionally conditions. As a result, they typically look like the following:
During the creation of a CMK, whether you create it programmatically or if you create it through the AWS Management Console, either way KMS will create a default key policy for you to allow principals to use the CMK in question. As, remember a key policy is required for all CMKs.
With these default key policies, KMS will configure the root of the AWS account full access to the CMK, by doing so ensures that the CMK will never become unusable as it’s not possible to delete the root account.
If full access of the CMK was given to another user and then that user was deleted from IAM, it would not be possible to manage the CMK unless you contacted AWS support to regain the control required. Also, by allowing the root account full access to the CMK performs another important and useful function. It allows access to be given to the CMK by normal IAM policies for users and roles, etc. That’s why it’s not possible to allow users access to a CMK without a key policy. Without the root account having full access in the key policy, IAM can’t be used to manage access for other users.
Within the key policy, this section would look as follows.
The resource section shows an asterisk which essentially means this CMK that the key policy is being applied to.
Using Key Policies
When you create your CMK through the Management Console, then you have the chance to configure different permission sets. These include key administrators of the CMK and users which are allowed access to the CMK.
You’ll be asked to firstly define the key administrators. These can either be users or roles that you have setup and configured within IAM. These principals can only administer the CMK and not use it to perform any encryption function that may be needed within the CMK.
The administrative actions that are allowed by the key admins are shown below. During the selection of key admins, you can also specify if you would like them to be able to delete the key via a checkpoint option.
An important point to bear in mind is that although these key administrators do not have access to use the CMK, they do have access to update the associated key policy. As a result, if they wanted to, they could give themselves access to use the CMK.
Next you’ll be asked which users you want to allow to use the CMK. And by use, it’s essentially asking which users should be allowed to perform any encryption using the CMK. In addition to these permissions, the users associated will also be able to use grants to delegate a subset of their own permissions to another service which integrates with KMS.
For example, if you are attaching an encrypted EBS volume to an EC2 instance, then through the use of grants, you as the key user of the CMK which encrypted the EBS volume implicitly give permission to EC2 to be able to attach that encrypted EBS volume. Within the key policy, the grant permissions look as follows.
For every user or role selected as a user of the key will be displayed within the principal section. As you can see from this example, the only user currently selected for this key is Cloud Academy. The permissions given to use the key for any user selected are as follows.
As the key policy uses the same syntax as IAM policies, you can also restrict access to the CMK in the same way that you can restrict access to resources via the Effect element. Instead of using the Effect Allow, you can instead restrict and deny a particular user access to a CMK by specifying the Effect as deny.
Using Key Policies with IAM Policies
As mentioned, we can also use key policies in conjunction with IAM policies, but only if you have the following entry within the key policy allowing the root full KMS access to the CMK, by doing so enables you to centralize your permissions administration from within IAM as you would likely be doing for many other AWS services.
This would mean you can configure your IAM policies to allow users, groups and roles to perform the encryption and decryption process, for example using the KMS Encrypt and KMS Decrypt permissions.
Using the resource component within the policy, you can also specify which CMKs the user, group or role can use to perform the encryption and decryption process. In this example, we can see that the policy will allow the identity associated with the policy to use two different CMKs to encrypt and decrypt data. The first CMK is within the
US-East-1 region and the second CMK is within the
Using Key Policies with Grants
Finally, you can assign permissions using grants alongside key policies. I’ve mentioned grants a couple of times already, but in essence, they allow you to delegate your permissions to another AWS principal within your
AWS account. Much like the key policy, grants are another resource based method of access control to the CMKs.
The grants themselves need to be created using the AWS KMS APIs. It’s not possible to create them using the AWS Management Console and these grants are then attached to the CMK, much like key policies are. Within the key policy of the CMK, you will see the Sid which allows the users of the CMK to also perform three grant actions,
When issuing the CreateGrant API, a number of different parameters are also issued such as the CMK identifier. The grantee principal to gain the permissions and the required level of operations that the grantee can perform include the following on screen. Once the grant is active, the principal or grantee can then adopt the permissions programmatically based on the level of access provided within the grant.
Also, after the grant has been created, a
GrantToken and a
GrantID is issued. When a grant is created, there may be a delay in being able to use the permissions and this is due to the fact that eventual consistency has to take place. To get around this, you can use the
GrantToken with some APIs which would allow the grantee to perform the operation specified within the grant with immediate effect without having to wait for eventual consistency to complete.
The overall process of understanding who has access to a CMK in KMS can be a little confusing as there are three potential ways of gaining access and using a CMK, through the key policy, with IAM policies and also Grants. And determining the correct level of access means you need to understand how they all work together. So let’s look at a simple example to ensure we understand some key points. In this scenario, we have three CMKs and four users.
So let’s now look at each of these user’s access and what they have access to, starting with Alice.
Alice’s access to CMK-A is successful as her IAM policy allows all KMS actions against CMK-A and CMK-A allows for IAM policies to be used. Her access to CMK-B provides no access as the key policy for this CMK does not allow for IAM policies to be used. And her access to CMK-C is successful as the key policy allows her access despite her having no IAM policy relating to permissions.
Now let’s take a look at Bob. His access to CMK is denied as there are no explicit entries in the key policy for Bob’s access and he has no IAM policy. His access to CMK-B is successful as the key policy allows him access despite him having no IAM policy relating to permissions and access is denied to CMK-C due to explicit deny actions within the key policy and an explicit deny will always overrule any other allow.
Now let’s look at Charlie’s access. For CMK-A, he has encrypt access only which is given through his IAM policy and IAM policy permissions are allowed. For CMK-B, access is also successful as the key policy allows him access. His IAM policy permissions are irrelevant as the CMK does not allow for IAM policies to be used. And his access to CMK-C is denied due to the explicit deny actions within the key policy and an explicit deny will overrule any other allow.
And finally David’s access. He has no access to CMK-A as neither the key policy or his IAM policy provides permissions. He has no access to CMK-B as the key policy for this CMK does not allow for IAM policies to be used and access is also denied to CMK-C due to explicit deny actions within the key policy.