Amend spec to add more details around encryption secrets
This removes the mention of a flavor extra spec for indicating the encryption secret UUID of an encrypted image. The secret is related only to an image, not a flavor. This also adds more details about the handling of encryption secrets when instances with ephemeral encryption are snapshotted, shelved, or rescued. Related to blueprint ephemeral-storage-encryption Change-Id: I3599e2fe59113b1d27ba08019c7cd78f1ab5a725
This commit is contained in:
parent
ea0cf9579f
commit
5acad23725
|
@ -120,15 +120,155 @@ The format will be provided as a string that maps to a
|
|||
* ``luks`` for the LUKSv1 format
|
||||
|
||||
To enable snapshot and shelve of instances using ephemeral encryption, the UUID
|
||||
of the encryption security stored in the key manager for the resultant image
|
||||
will be kept with the image as a flavor extra spec or image property:
|
||||
of the encryption secret is stored in the key manager for the resultant image
|
||||
will be kept with the image as an image property:
|
||||
|
||||
* ``hw:ephemeral_encryption_secret_uuid``
|
||||
* ``hw_ephemeral_encryption_secret_uuid``
|
||||
|
||||
The secret UUID is needed when creating an instance from an ephemeral encrypted
|
||||
snapshot or when unshelving an ephemeral encrypted instance.
|
||||
|
||||
Create a new key manager secret for every new encrypted disk image
|
||||
------------------------------------------------------------------
|
||||
|
||||
The approach for disk image secrets is to never share secrets between different
|
||||
disk images and that each disk image has a unique secret. This is done to
|
||||
address both 1) the security implications and 2) the logistics of cleaning up
|
||||
secrets that are no longer in use.
|
||||
|
||||
For example:
|
||||
|
||||
Let's say ``Instance A`` has 3 disks: one root disk, one ephemeral disk, and
|
||||
one swap disk. Each disk will have its own secret.
|
||||
|
||||
This table is intended to illustrate the way secrets are handled in various
|
||||
scenarios.
|
||||
|
||||
.. code:: rst
|
||||
|
||||
+--------------------+-------------+--------------+------------------------------------------------------+
|
||||
| Instance or Image | Disk | Secret | Notes |
|
||||
| | | (passphrase) | |
|
||||
+====================+=============+==============+======================================================+
|
||||
| Instance A | disk (root) | Secret 1 | Secret 1, 2, and 3 will be automatically deleted |
|
||||
| +-------------+--------------+ by Nova when Instance A is deleted and its disks are |
|
||||
| | disk.eph0 | Secret 2 | destroyed |
|
||||
| +-------------+--------------+ |
|
||||
| | disk.swap | Secret 3 | |
|
||||
+--------------------+-------------+--------------+------------------------------------------------------+
|
||||
| Image Z (snapshot) | disk (root) | Secret 4 | Secret 4 will *not* be automatically deleted and |
|
||||
| created from | | (new secret | manual deletion will be needed if/when Image Z is |
|
||||
| Instance A | | is created) | deleted from Glance |
|
||||
+--------------------+-------------+--------------+------------------------------------------------------+
|
||||
| Instance B | disk (root) | Secret 5 | Secret 5, 6, and 7 will be automatically deleted |
|
||||
| created from +-------------+--------------+ by Nova when Instance B is deleted and its disks are |
|
||||
| Image Z (snapshot) | disk.eph0 | Secret 6 | destroyed |
|
||||
| +-------------+--------------+ |
|
||||
| | disk.swap | Secret 7 | |
|
||||
+--------------------+-------------+--------------+------------------------------------------------------+
|
||||
| Instance C | disk (root) | Secret 8 | Secret 8, 9, and 10 will be automatically deleted |
|
||||
| +-------------+--------------+ by Nova when Instance C is deleted and its disks are |
|
||||
| | disk.eph0 | Secret 9 | destroyed |
|
||||
| +-------------+--------------+ |
|
||||
| | disk.swap | Secret 10 | |
|
||||
+--------------------+-------------+--------------+------------------------------------------------------+
|
||||
| Image Y (snapshot) | disk (root) | Secret 8 | Secret 8 is *retained* when Instance C is shelved in |
|
||||
| created by shelve | | | part to prevent the possibility of a change in |
|
||||
| of Instance C | | | ownership of the root disk secret if, for example, |
|
||||
| | | | an admin user shelves a non-admin user's instance. |
|
||||
| | | | This approach could be avoided if there is some way |
|
||||
| | | | we could create a new secret using the instance's |
|
||||
| | | | user/project rather than the shelver's user/project |
|
||||
+--------------------+-------------+--------------+------------------------------------------------------+
|
||||
| Rescue disk | disk (root) | Secret 11 | Secret 11 is stashed in the instance's system |
|
||||
| created by rescue | | (new secret | metadata with key |
|
||||
| of Instance A | | is created) | ``rescue_disk_ephemeral_encryption_secret_uuid``. |
|
||||
| | | | This is done because a BDM record for the rescue |
|
||||
| | | | disk is not going to be persisted to the database. |
|
||||
+--------------------+-------------+--------------+------------------------------------------------------+
|
||||
|
||||
Snapshots of instances with ephemeral encryption
|
||||
````````````````````````````````````````````````
|
||||
|
||||
When an instance with ephemeral encryption is snapshotted, a new encryption
|
||||
secret is created and its key manager secret UUID is kept as an image property
|
||||
``hw_ephemeral_encryption_secret_uuid`` and the image is uploaded to Glance.
|
||||
|
||||
When a new instance is created from an encrypted image, the image property
|
||||
``hw_ephemeral_encryption_secret_uuid`` is passed down to the lower layers by
|
||||
storing it in the instance's system metadata with key
|
||||
``image_hw_ephemeral_encryption_secret_uuid``. This is done because at the
|
||||
lower layers (where ``qemu-img convert`` is called, for example) we no longer
|
||||
have access to the image metadata and refactoring to pass image metadata to
|
||||
several lower layer methods, or similar, would be required otherwise.
|
||||
|
||||
Snapshots created by shelving instances with ephemeral encryption
|
||||
`````````````````````````````````````````````````````````````````
|
||||
|
||||
When an instance with ephemeral encryption is shelved, the existing root disk
|
||||
encryption secret is *retained* and will be used to unshelve the instance
|
||||
later. This is done to prevent a potential change in ownership of the root disk
|
||||
encryption secret in a scenario where an admin user shelves a non-admin user's
|
||||
instance, for example. If a new secret were created owned by the admin user,
|
||||
the non-admin user who owns the instance will be unable to unshelve the
|
||||
instance.
|
||||
|
||||
This behavior could be avoided however if there is some way we could create a
|
||||
new encryption secret using the instance's user and project rather than the
|
||||
shelver's user and project. If that is possible, we would not need to reuse the
|
||||
encryption secret.
|
||||
|
||||
Rescue disk images created by rescuing instances with ephemeral encryption
|
||||
``````````````````````````````````````````````````````````````````````````
|
||||
|
||||
When rescuing an instance and an encrypted rescue image is
|
||||
specified, the rescue image secret UUID from the image property will be stashed
|
||||
in the instance's system metadata with key
|
||||
``rescue_image_hw_ephemeral_encryption_secret_uuid`` to pass it down to the
|
||||
lower layers. This is considered separate from
|
||||
``image_hw_ephemeral_encryption_secret_uuid`` which means the encrypted image
|
||||
from which the instance was created. Another reason to keep it separate is to
|
||||
avoid confusion for those reading or working on the code.
|
||||
|
||||
A new encryption secret is created when the rescue disk is created and its UUID
|
||||
is stashed in the instance's system metadata with key
|
||||
``rescue_disk_ephemeral_encryption_secret_uuid``. This is done because a block
|
||||
device mapping record for the rescue disk is not going to be persisted to the
|
||||
database.
|
||||
|
||||
The corresponding virt driver secret name pattern is
|
||||
``<instance UUID>_rescue_disk`` and any existing secrets with that name are
|
||||
deleted by the virt driver when a new rescue is requested.
|
||||
|
||||
The new encryption secret for the rescue disk is deleted from the key manager
|
||||
and the virt driver secret is also deleted when the instance is unrescued.
|
||||
|
||||
Cleanup of ephemeral encryption secrets
|
||||
```````````````````````````````````````
|
||||
|
||||
Ephemeral encryption secrets are deleted from the key manager and the virt
|
||||
driver when the corresponding instance is deleted and its disks are destroyed.
|
||||
The approach is that encryption secrets are *only* deleted when the disks
|
||||
associated with them are destroyed.
|
||||
|
||||
Encryption secrets that are created when a snapshot is created are *never*
|
||||
deleted by Nova. It would only be acceptable to delete the secret if and when
|
||||
the snapshot image is deleted. Cleanup of secrets whose images have been
|
||||
deleted from Glance must be deleted manually by the user or an admin.
|
||||
|
||||
.. note::
|
||||
|
||||
At the time of this writing, the newest Ceph release v17 (Quincy) does not
|
||||
support creating a cloned image with an encryption key different from its
|
||||
parent. For this reason, copy-on-write cloning will not be enabled for
|
||||
instances which have specified ephemeral encryption.
|
||||
|
||||
Support for creating a cloned image with an encryption key different from
|
||||
its parent should be supported in the next release of Ceph.
|
||||
When we are able to require a Ceph version >= v18, copy-on-write cloning
|
||||
with ephemeral encryption can be enabled.
|
||||
See https://github.com/ceph/ceph/commit/1d3de19 for reference.
|
||||
|
||||
BlockDeviceMapping changes
|
||||
--------------------------
|
||||
|
||||
|
|
Loading…
Reference in New Issue