In this lecture, I want to show you how to create a new KMS key using the AWS Management Console and how the key policy is built to include key administrators, users and grants. 

From the dashboard of the AWS Management Console you need to go to the Key Management Service.  From here you can see on the left any AWS managed KMS keys that have already been created, for example from Lambda, RDS and EBS etc, in addition to any customer managed KMS keys.  As you can see, I only have 1 key, labeled as Demo key, but let’s go ahead and Create a new Key by clicking on the orange ‘Create Key’ icon.

From here we can start the configuration of our Key.  We can select which type of key we want, a symmetric or asymmetric key, and what we would like to use the key for.  Either cryptographic operations or for generating and verifying HMAC codes.  For this example, I will select symmetric as the key type, and Encrypt and decrypt as the key type.

If we move down to Advanced options, we can also specify the key material origin, and we could change this if we wanted to supply the key material from another source other than from within KMS, in addition to if we want to generate this key to be used across more than one region.  Again, for this demonstration I shall take the defaults of KMS as the key origin, and the option of a single-region key.

Moving onto the next screen I can set some basic metadata including the Alias name of the key, which I shall call NewKey.  I shall leave the description blank for this demo, but feel free to add in any information that will help you to understand the purpose behind the key.  Then finally you can also add a Tag to your KMS key, again, I shall leave this for the sake of this demonstration.

Moving on to the next screen we can start to see how the Key Policy is defined.  We are presented with a screen that is used to define who we want to use as Key Administrators for the KMS key which can be an IAM user or role.  Remember, Key administrators can only perform administrative actions against the key, they can’t actually use it for cryptographic operations. Using the checkboxes, simply select the Key administrators.  For this demo I shall select both Cloud Academy and Stuart. Also at the bottom of this screen you will notice a checkbox which also allows the Key administrator to delete the associated key if it’s selected.  I will leave this selected by default.

Moving to the next screen we can define the key usage permissions.  So here again I can use the check boxes to select which users or roles I would like to be able to use the key to perform cryptographic operations, and these users can either be in the account I’m using at the moment, or from another account.  If I wanted to select a user from another account I would need to add in the account ID of that additional account.  Again, and to keep things simple in this demonstration, I shall just keep the one user of Stuart before moving on to the final page of configuration.

This last page essentially shows all of the options that I selected from the previous screens as a review before creating the key.  We can review the key configuration, alias and description, the tags, and finally the key policy.  

This screen gives us an opportunity to look at the key policy in more detail, and if required we can edit the key policy directly from this screen before creating the key.  If we scroll through the policy we can see the default entry allowing access to this KMS Key being given via IAM if we wanted to centrally manage our permissions all from IAM.  Further down, we also have the entries showing which principles have been identified as our key administrators and all of their permissions as an administrator, and then further down we have our Key users as well showing the cryptographic operations that they can perform.  Then lastly we have the entry showing who can issue grants.  You would have noticed that defining who should be able to issue grants was not a part of the configurational process in setting up this Key, and that’s because by default whichever principles are added as Key Users they are also added as principles that can create grants.  

You can of course make any edits to the Key policy directly from here, it’s an editable document.  When you are happy with your KMS key, you can then click ‘Finish.’

From here you will then see your KMS Key under the customer-managed keys list.  If you click on your newly created key it will take you the details and information of that key. 

At the top we can see some general information, the alias, arn, status, when it was created and if the key is multi-regional or for a single region use only. 

Underneath that we have a bunch of tabs, and under the key policy tab we can view the key policy in an easy to read format showing you the principals selected for Key Administrators, who can delete the key, the users of the key.  However, this screen can also be viewed from a JSON perspective too, again, allowing you to edit the key policy as and how you need to.

The ‘Cryptographic configuration’ tab will detail the Key type, the origin source of the key, the key spec which determines if the key is symmetric or asymmetric, and then also the usage.  

The tags tab is what you’d expect, an area to view and create tags for your key.

The Key rotation tab allows you to select automatic rotation of the KMS key material, this is a good practice to adopt for your customer-managed keys.

And lastly, Alias will show you the name of the key in addition to the amazon resource name of the newly created KMS key.  

In the top right hand corner of this screen there is an option for a couple of Key actions.  Under here we have Disable and Schedule Key deletion.  If we are an administrator with the correct permissions we can disable the key, but beware of the warning when doing so as it could render some of your data unreadable that have been encrypted with this key.  

If you want to schedule the deletion of the KMS key then again be warned that it will make all data encrypted under that key unrecoverable! When scheduling the deletion you can set a waiting period in days from anywhere between 7 and 30.  You must then confirm you are happy to delete this key after that time period.

While I’m in the console here and running through Key policies etc, let me just show you that we can go ahead and look at the key policy for AWS managed keys, however we are unable to change or edit them in any way.  Being AWS managed, all we can do is view some of the metadata around these keys, and view the key policy.  So just remember that if you have access to edit a Key policy, then it will be a customer-managed key that you’re editing.

That’s it for this demonstration, it should now be a little clearer how you can create a new customer-managed Key within KMS and how you can view and edit the Key policy if required.