Hello and welcome to this lecture which will focus on the methods available to secure your KMS keys.  

As you are probably familiar with when working with different AWS services, you can control access to resources using IAM policies, however controlling who has access to your KMS keys is slightly different.  Although you can use a resource based IAM policy to control who has access to a KMS key, you must first allow the use of IAM policies as an access control method from within the corresponding KMS Key policy first.  Without allowing the use of IAM policies within this key policy then IAM policies will have no effect, unless it is to ‘deny’ access.

So what is a KMS Key policy?  Key policies are resource based policies created from within the KMS service and are tied to your KMS key.  Each and every Key will have no more than one Key Policy and they specify if IAM user permissions are allowed to control access, who can administer the key, who can access the key to perform cryptographic operations, and who can create Grants to control temporary access to a KMS key.

The key policy document itself is JSON based and the document syntax is much like that of IAM policies. They contain elements such as resource, action, effect, principal and optionally conditions. As a result, they typically look like the following.

Let's take a closer look at this policy, starting with the first Statement ID.

As I previously mentioned, permissions to allow you to access and use your KMS key can't be given and generated using IAM alone, IAM permissions have to be allowed from within your Key policy.  If we look at the first “Sid” of this example Key policy we can see how this is achieved.

As you can see this statement allows the root account, which represents the AWS account that owns the key, full access to KMS.  It’s important to understand that this doesn’t actually give any permissions to use the Key itself to any principal, it simply allows you to grant access to the Key through the use of IAM policies. Without this statement in your key policy any IAM statements that allow access to the key will be ignored, unless they are being used to deny access.

During the creation of a KMS key, whether you create it programmatically or if you create it through the AWS Management Console, this Sid is entered into every Key Policy, so if you don’t want to manage permissions with the help of IAM policies, then you need to ensure that you remove this entry in your key policy.

An added benefit of having the root principal access to KMS ensures that the KMS key will never become unusable as it's not possible to delete the root account. 

The next statement ID in the policy is…. Allow access for Key Administrators. For every KMS key you should also identify your Key administrators.  These can either be users or roles that you have set up and configured within IAM. These principals can only administer the KMS key and not use it to perform any encryption functions using that key. During the selection of key administrators, you can also specify if you would like them to be able to delete the key. An important point to bear in mind is that although these key administrators do not have access to use the KMS key, 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 KMS Key as a User of the key.  

Using our example policy shown earlier, this following entry shows the Key Administrators for the Key.

Here we can see that the user ‘CloudAcademy’ is added as a principal with a number of administrative actions that the user can perform against the KMS key, such as Update, Delete, Enable, ScheduleKeyDeletion, etc. 

The next statement ID is…. Allow use of the Key. Of course, the Key policy must also define who can use the key to perform cryptographic functions, and these are known as Key Users.  Looking at the policy again, we can see the entry here.

As shown, we have 2 users that have the use of the key to perform a number of actions, such as using the key to both encrypt and decrypt data, reencrypt data which will allow you to change the KMS key under which data is encrypted, generate data keys from the KMS key, and also describe the key which will provide detailed information about the key.

As you have seen in the examples I’ve given with the Key Administrators and the Key Users, you can have the same principal in both sections if you need to.  

The last Statement ID of the policy is… Allow attachment of persistent resources. In the last part of the Key policy we have an entry that allows you to control access through the use of Grants.

Grants allow you to delegate a subset of permissions that a Key user has to another principal on a temporary basis without having to update the Key Policy to define these permissions.   Grants are also used by different AWS services that integrate with KMS.  When required, the AWS service will create a grant on behalf of the user, perform the encryption operations needed, and then the Grant is removed.  

Much like the key policy, grants are another resource based method of access control to KMS keys. 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 KMS key, much like key policies are. 

In the policy example we see here, it shows 2 users are allowed to Create, List and Revoke Grants on the condition that of GrantIsForAWSResource.  This means that these grant operations can be called by AWS services that integrate with KMS, for example EBS, on the users behalf.

If you’re going to use Grants then there are a number of points that need to be considered.

• When a grant is created, it will only be available with a single KMS key that can either be  within your own account, or another account.
• The grantee principal (the principal that will be using the grant) can either be a user, a role, or a federated user or role.  It can’t be an IAM group, an AWS organization or an AWS Service Role.
• Statements within the Key Policy for Grant operations only apply to ‘Allow’ operations, ‘Deny’ operations are not supported.
• After creating a grant there could be a delay until the operation achieves eventual consistency.  If you want to use the permissions immediately after creating a grant then you will need to use a grant token.

After creating a grant, the grantee principal will be able to gain the permissions and the required level of operations specified by the grantee. Once the grant is active, the grantee principal can 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.