Welcome back. In this lesson, we'll discuss the options you have for using your own OCI vault keys for block or boot volumes associated with OKE worker node instances. But before we discuss using your own keys, let's review how Oracle Cloud manages data encryption. You see by default, data on boot, and block volumes used by OKE is encrypted using an Oracle-managed master encryption key. Therefore, even if you're not leveraging the vault service, stored data, often referred to as data at rest, is always encrypted in the block volume service. You cannot turn it off, which is an important point to keep in mind. Then Oracle-managed Keys means that we use a master encryption key from an internal Oracle-Managed vault, which will generate a data encryption key to the block volumes service for encrypting, and decrypting data. However, when you decide not to use Oracle-managed Keys, this is where you are choosing to use a key from your own Vault. As you can see here in this boot volume example, you simply locate your vault, then choose the key you wish to use for all the boot volumes for worker node instances within the node pool. Before we can specify our own key for a block or boot volume encryption, you have to first create a suitable master encryption key in a vault that you have access to, or obtain the name, and OCID of such a key if it already is available to you. Next, you need to create an OCI, Identity, and Access Management Policy, authorizing both the OKE, and block storage services to use your master encryption key. Here's an example, limiting access to just one specific key. Now, you can use that key to handle data encryption, and decryption in worker node pool boot volumes or in other block volumes that are provisioned as persistent volume claims for your OKE cluster. Let's first look at specifying boot volumes. Here we are in our OCI console, and first things first, let's go take a look under Identity and Security, and at our Vault service. We'll look at the vault that I've created already for this demonstration. It's appropriately called a demo vault, and inside the demo vault, I do indeed have a master encryption key that I've already created That's uses the AES algorithm which is required, and here is that particular key. In fact, I can also, if I need to, which we might use for later for block volumes. I'll need to get a hold of that OCID that unique identifier by copying it. Of course, you can see what that entire OCID looks like. Now that we've seen where the key is, and what it's called. Let's navigate over to our Kubernetes cluster. In my Kubernetes cluster, I already have a cluster that I've got created. What we can do when we're defining this for the boot volume is when we're first creating a cluster, we can run through the wizard, and assign that, or as I'll show you now, we can actually do it to an existing cluster. I simply go down to my existing node pool. In that existing node pool, when I click on the option to edit it. I'll have the option to make that change for the boot volume. If you'll notice in addition to specifying a different custom volume size or whether or not I want to enable in-transit encryption. Here's the option for encrypting the volume with a key I managed. I`m simply now locating the vault. In this case, it's already been selected, and there's only one key, and I`m locating the key, and I just simply click to save those changes. It becomes applied for that node pool. For the other use case when your Kubernetes persistent volume claims are backed by the block volume service, you have the option to encrypt all of your volumes, and their backups using your keys as well. First, we see here an example manifest file for defining a storage class persistent volume that will be encrypted with an Oracle-managed key since this is the default when you are setting the attachment type to paravirtualized. Instead, you can specify the master encryption key to be used by the block storage service by adding the KMS key ID property, and providing the OCID of the key from your vault you wish to use. That's it for this lesson on leveraging user managed keys for block, and boot volumes, and OKE. Thanks for watching.
