![]() When a virtual image is launched with a trusted flavor, the trust scheduler in OpenStack Nova queries the attestation server for the trust status of available compute nodes and only selects trusted compute nodes for launching the virtual machine instance. In the screenshot of the Launch tab, the selected flavor is m1.usted, which in the reference implementation refers to a single virtual CPU, with 512 MB of memory, no extra disks, and a trust requirement from the attestation server. These extensions, and the Horizon dashboard and APi extensions to tag flavors with trustpolicies, have been part of openstack since the folsom release. Implemented in openstack as scheduler filters. ■ Note Trusted compute pools (TCP) function, as described in chapter 3, has been The flavor list is downloaded from Nova Controller and reflects the same list as is available in the Horizon dashboard.įigure 8-8. The MH client reference implementation conveniently preselects the last virtual machine image encrypted in the Upload tab. To launch an encrypted virtual machine, the encrypted virtual machine image is selected from the list, a trusted flavor is chosen to use for the virtual machine instance, and the Launch button is clicked. The Launch tab features a single launch step and a progress monitor. In practice this will be done either through use of OpenStack virtual machine launch APIs or from a portal such as OpenStack Horizon. The Launch tab, as shown in Figure 8-8, simulates a launch of a specific virtual machine. ![]() Selecting and binding a virtual machine image to an encryption key ![]() Third, the encrypted VM image is uploaded along with its encryption metadata to Glance, using the Glance client to upload the image and set its metadata in Glance.įigure 8-7. Second, a virtual macine image to encrypt is selected and encrypted using the key just selected or generated. (For the reference implementation, no HSM was used with the KMS.) The KMS returns the URL and a decryption key ID (DKID) to be associated with the encrypted target virtual machine. First, either an existing key is selected or a new key is generated to use for encryption. Although it is possible to upload encrypted virtual machine images manually to OpenStack Glance image service, and to use the Glance client to add the encryption metadata, it is far more convenient to let the MH client upload the encrypted virtual machine image and add the encryption flag and decryption key URL to the Glance image metadata using the Glance APIs.Īs can be seen in Figure 8-7, there are two steps before an encrypted virtual machine can be uploaded to OpenStack Glance. In OpenStack, a virtual machine image is assumed to be in disk image format, ISO, vmdk, xva, or vhd. The tenant or the service consumer, perhaps DevOps staff, uses the MH client to create keys, store them in the KMS, and encrypt the virtual machine images. The goal is to implement a secure process under tenant control. Tenant-controlled virtual machine encryption and decryption with trusted launch in OpenStackĪs shown in Figure 8-6, the process begins with creating the encryption keys to be applied to the virtual machine images. A set of screenshots of the implementation follows, illustrating the flow and the process of integration into OpenStack.įigure 8-6. ![]() It works with OpenStack environments using either KVM or Xen hypervisors. Figure 8-6 shows the reference implementation in OpenStack.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |