)]}'
{"specs/stein/approved/image-encryption.rst":[{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"98ee83bc064f62de935632ab1c71b10648d7579f","unresolved":false,"context_lines":[{"line_number":44,"context_line":"1. A user wants to create a new server based on an encrypted image. The"},{"line_number":45,"context_line":"corresponding compute host has to be able to decrypt the image using the"},{"line_number":46,"context_line":"symmetric key stored in the key manager and transform it into the requested"},{"line_number":47,"context_line":"resource (server disk)."},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"2.1. A user wants to create an encrypted image from a server. The server uses"},{"line_number":50,"context_line":"an unencrypted ephemeral storage. The target image is to be encrypted using"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_d6f8327f","line":47,"range":{"start_line":47,"start_character":17,"end_line":47,"end_character":21},"updated":"2018-10-11 13:52:45.000000000","message":"s/disk/disk image/","commit_id":"ac6e6caba36074c06eca46c7ebb72620fe2c3416"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"25feb49c9c375120f88252d16010c30044981c49","unresolved":false,"context_lines":[{"line_number":44,"context_line":"1. A user wants to create a new server based on an encrypted image. The"},{"line_number":45,"context_line":"corresponding compute host has to be able to decrypt the image using the"},{"line_number":46,"context_line":"symmetric key stored in the key manager and transform it into the requested"},{"line_number":47,"context_line":"resource (server disk)."},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"2.1. A user wants to create an encrypted image from a server. The server uses"},{"line_number":50,"context_line":"an unencrypted ephemeral storage. The target image is to be encrypted using"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_43c25404","line":47,"range":{"start_line":47,"start_character":17,"end_line":47,"end_character":21},"in_reply_to":"3f79a3b5_d6f8327f","updated":"2018-10-22 13:50:58.000000000","message":"Done","commit_id":"ac6e6caba36074c06eca46c7ebb72620fe2c3416"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"98ee83bc064f62de935632ab1c71b10648d7579f","unresolved":false,"context_lines":[{"line_number":46,"context_line":"symmetric key stored in the key manager and transform it into the requested"},{"line_number":47,"context_line":"resource (server disk)."},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"2.1. A user wants to create an encrypted image from a server. The server uses"},{"line_number":50,"context_line":"an unencrypted ephemeral storage. The target image is to be encrypted using"},{"line_number":51,"context_line":"the proposed image encryption mechanism and a specified key."},{"line_number":52,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_564182a6","line":49,"range":{"start_line":49,"start_character":4,"end_line":49,"end_character":46},"updated":"2018-10-11 13:52:45.000000000","message":"might be more common to say \"A user wants to snapshot a server that uses an unencrypted disk image and encrypt the snapshot before storage\".","commit_id":"ac6e6caba36074c06eca46c7ebb72620fe2c3416"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"25feb49c9c375120f88252d16010c30044981c49","unresolved":false,"context_lines":[{"line_number":46,"context_line":"symmetric key stored in the key manager and transform it into the requested"},{"line_number":47,"context_line":"resource (server disk)."},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"2.1. A user wants to create an encrypted image from a server. The server uses"},{"line_number":50,"context_line":"an unencrypted ephemeral storage. The target image is to be encrypted using"},{"line_number":51,"context_line":"the proposed image encryption mechanism and a specified key."},{"line_number":52,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_63c51009","line":49,"range":{"start_line":49,"start_character":4,"end_line":49,"end_character":46},"in_reply_to":"3f79a3b5_564182a6","updated":"2018-10-22 13:50:58.000000000","message":"Done","commit_id":"ac6e6caba36074c06eca46c7ebb72620fe2c3416"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"98ee83bc064f62de935632ab1c71b10648d7579f","unresolved":false,"context_lines":[{"line_number":50,"context_line":"an unencrypted ephemeral storage. The target image is to be encrypted using"},{"line_number":51,"context_line":"the proposed image encryption mechanism and a specified key."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"2.2. A user wants to create an encrypted image from a server. The server uses"},{"line_number":54,"context_line":"an encrypted ephemeral storage. The target image is to be re-encrypted using"},{"line_number":55,"context_line":"the proposed image encryption mechanism and a specified key."},{"line_number":56,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_d606f274","line":53,"range":{"start_line":53,"start_character":4,"end_line":53,"end_character":60},"updated":"2018-10-11 13:52:45.000000000","message":"perhaps more common to say \"A user wants to snapshot a server that uses an encrypted disk image\"?","commit_id":"ac6e6caba36074c06eca46c7ebb72620fe2c3416"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"25feb49c9c375120f88252d16010c30044981c49","unresolved":false,"context_lines":[{"line_number":50,"context_line":"an unencrypted ephemeral storage. The target image is to be encrypted using"},{"line_number":51,"context_line":"the proposed image encryption mechanism and a specified key."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"2.2. A user wants to create an encrypted image from a server. The server uses"},{"line_number":54,"context_line":"an encrypted ephemeral storage. The target image is to be re-encrypted using"},{"line_number":55,"context_line":"the proposed image encryption mechanism and a specified key."},{"line_number":56,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_03cc5c32","line":53,"range":{"start_line":53,"start_character":4,"end_line":53,"end_character":60},"in_reply_to":"3f79a3b5_d606f274","updated":"2018-10-22 13:50:58.000000000","message":"Done","commit_id":"ac6e6caba36074c06eca46c7ebb72620fe2c3416"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"98ee83bc064f62de935632ab1c71b10648d7579f","unresolved":false,"context_lines":[{"line_number":51,"context_line":"the proposed image encryption mechanism and a specified key."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"2.2. A user wants to create an encrypted image from a server. The server uses"},{"line_number":54,"context_line":"an encrypted ephemeral storage. The target image is to be re-encrypted using"},{"line_number":55,"context_line":"the proposed image encryption mechanism and a specified key."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_7617de9e","line":55,"range":{"start_line":54,"start_character":32,"end_line":55,"end_character":60},"updated":"2018-10-11 13:52:45.000000000","message":"Why re-encrypt? if the target is already encrypted, why do the encryption again?","commit_id":"ac6e6caba36074c06eca46c7ebb72620fe2c3416"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"25feb49c9c375120f88252d16010c30044981c49","unresolved":false,"context_lines":[{"line_number":51,"context_line":"the proposed image encryption mechanism and a specified key."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"2.2. A user wants to create an encrypted image from a server. The server uses"},{"line_number":54,"context_line":"an encrypted ephemeral storage. The target image is to be re-encrypted using"},{"line_number":55,"context_line":"the proposed image encryption mechanism and a specified key."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_e3d040c9","line":55,"range":{"start_line":54,"start_character":32,"end_line":55,"end_character":60},"in_reply_to":"3f79a3b5_7617de9e","updated":"2018-10-22 13:50:58.000000000","message":"Done","commit_id":"ac6e6caba36074c06eca46c7ebb72620fe2c3416"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"acae2e9d4824c732c4a088b4c5ea3e62a392be02","unresolved":false,"context_lines":[{"line_number":51,"context_line":"the proposed image encryption mechanism and a specified key."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"2.2. A user wants to create an encrypted image from a server. The server uses"},{"line_number":54,"context_line":"an encrypted ephemeral storage. The target image is to be re-encrypted using"},{"line_number":55,"context_line":"the proposed image encryption mechanism and a specified key."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_79f1f469","line":55,"range":{"start_line":54,"start_character":32,"end_line":55,"end_character":60},"in_reply_to":"3f79a3b5_7617de9e","updated":"2018-10-12 14:54:35.000000000","message":"Simply because the encryption mechanisms differ. Our proposed solution specifies a GPG-based AES256 encryption. The encryption of ephemeral storage disks currently supported is LUKS-based aes-xts-plain64 encryption. LUKS is substantially different from the GPG format, thus one needs to be transformed into the other. Essentially we consider images and ephemeral disks (or volumes) to be entirely separate resources that may be transformed into one another. Currently, both volume and ephemeral storage encryption is LUKS-based so we could theoretically re-use this but what if other formats are involved as target or source? We would suggest against limiting the possibilities of the image encryption concept by binding it to the currently used technologies for other resources. If you had a LUKS-based image encryption format, transformation into any other format would be really dirty because:\n\n* you would need root permissions for cryptsetup to open up the LUKS container as a dmcrypt devmapper endpoint\n\n* a dmcrypt devmapper endpoint needs to exist while the image is being read from - this exposes the image data for the root user, kinda like creating a temporary unencrypted copy of the image","commit_id":"ac6e6caba36074c06eca46c7ebb72620fe2c3416"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"98ee83bc064f62de935632ab1c71b10648d7579f","unresolved":false,"context_lines":[{"line_number":78,"context_line":"encryption/decryption processes, which is important as we require the"},{"line_number":79,"context_line":"streamability of the encryption/decryption mechanism for two reasons:"},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"1. Loading entire images into the memory of compute hosts is unacceptable."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"2. We propose direct decryption-streaming into the target storage disk to"},{"line_number":84,"context_line":"   prevent the creation of temporary unencrypted files."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_76f35e6e","line":81,"updated":"2018-10-11 13:52:45.000000000","message":"++","commit_id":"ac6e6caba36074c06eca46c7ebb72620fe2c3416"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"98ee83bc064f62de935632ab1c71b10648d7579f","unresolved":false,"context_lines":[{"line_number":81,"context_line":"1. Loading entire images into the memory of compute hosts is unacceptable."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"2. We propose direct decryption-streaming into the target storage disk to"},{"line_number":84,"context_line":"   prevent the creation of temporary unencrypted files."},{"line_number":85,"context_line":""},{"line_number":86,"context_line":"The decryption of the image should be done right when it is streamed into the"},{"line_number":87,"context_line":"ephemeral storage. We propose to limit the usage of encrypted images to"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_b6fd763c","line":84,"updated":"2018-10-11 13:52:45.000000000","message":"++","commit_id":"ac6e6caba36074c06eca46c7ebb72620fe2c3416"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"d2b13c15b837b5b361bcb4f08f4a1f2179268a3f","unresolved":false,"context_lines":[{"line_number":87,"context_line":"ephemeral storage. We propose to limit the usage of encrypted images to"},{"line_number":88,"context_line":"ephemeral storage backends that support encryption. For LibVirt this only"},{"line_number":89,"context_line":"applies to the LVM backend. Otherwise image data would be exposed through the"},{"line_number":90,"context_line":"ephemeral storage."},{"line_number":91,"context_line":""},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_7b073720","line":90,"updated":"2018-10-18 10:41:50.000000000","message":"Does streaming means that the image content is decrypted on the fly as the running server accessing content on the encrypted disk?","commit_id":"ac6e6caba36074c06eca46c7ebb72620fe2c3416"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"25feb49c9c375120f88252d16010c30044981c49","unresolved":false,"context_lines":[{"line_number":87,"context_line":"ephemeral storage. We propose to limit the usage of encrypted images to"},{"line_number":88,"context_line":"ephemeral storage backends that support encryption. For LibVirt this only"},{"line_number":89,"context_line":"applies to the LVM backend. Otherwise image data would be exposed through the"},{"line_number":90,"context_line":"ephemeral storage."},{"line_number":91,"context_line":""},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_03e53ca4","line":90,"in_reply_to":"3f79a3b5_7b073720","updated":"2018-10-22 13:50:58.000000000","message":"Done","commit_id":"ac6e6caba36074c06eca46c7ebb72620fe2c3416"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"c9e6158d47b95ba267f6445eb0c65a64098923fd","unresolved":false,"context_lines":[{"line_number":87,"context_line":"ephemeral storage. We propose to limit the usage of encrypted images to"},{"line_number":88,"context_line":"ephemeral storage backends that support encryption. For LibVirt this only"},{"line_number":89,"context_line":"applies to the LVM backend. Otherwise image data would be exposed through the"},{"line_number":90,"context_line":"ephemeral storage."},{"line_number":91,"context_line":""},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_a1dda040","line":90,"in_reply_to":"3f79a3b5_7b073720","updated":"2018-10-18 11:55:14.000000000","message":"No, at the time of the server start the decryption process has been finished already. Streaming in this context means the direct conversion of encrypted image into encrypted ephemeral disk prior to server start, avoiding the creation of temporary unencrypted files.","commit_id":"ac6e6caba36074c06eca46c7ebb72620fe2c3416"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"54491fe0a63a0e8d1c3e5e906b9a101aeba66cda","unresolved":false,"context_lines":[{"line_number":87,"context_line":"ephemeral storage. We propose to limit the usage of encrypted images to"},{"line_number":88,"context_line":"ephemeral storage backends that support encryption. For LibVirt this only"},{"line_number":89,"context_line":"applies to the LVM backend. Otherwise image data would be exposed through the"},{"line_number":90,"context_line":"ephemeral storage."},{"line_number":91,"context_line":""},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_02bf96ca","line":90,"in_reply_to":"3f79a3b5_a1dda040","updated":"2018-10-19 15:14:10.000000000","message":"Thanks","commit_id":"ac6e6caba36074c06eca46c7ebb72620fe2c3416"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"98ee83bc064f62de935632ab1c71b10648d7579f","unresolved":false,"context_lines":[{"line_number":94,"context_line":"------------"},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"Regarding the image encryption, we also explored the possibility of using more"},{"line_number":97,"context_line":"elaborated and dynamic approaches like PKCS#7 (CMS) but ultimately failed to"},{"line_number":98,"context_line":"find a free open-source implementation (e.g. OpenSSL) that supports streamable"},{"line_number":99,"context_line":"decryption of CMS-wrapped encrypted data. More precisely, no implementation we"},{"line_number":100,"context_line":"tested was able to decrypt a symmetrically encrypted, CMS-wrapped container"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_f6b52e7e","line":97,"range":{"start_line":97,"start_character":0,"end_line":97,"end_character":10},"updated":"2018-10-11 13:52:45.000000000","message":"elaborate","commit_id":"ac6e6caba36074c06eca46c7ebb72620fe2c3416"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"25feb49c9c375120f88252d16010c30044981c49","unresolved":false,"context_lines":[{"line_number":94,"context_line":"------------"},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"Regarding the image encryption, we also explored the possibility of using more"},{"line_number":97,"context_line":"elaborated and dynamic approaches like PKCS#7 (CMS) but ultimately failed to"},{"line_number":98,"context_line":"find a free open-source implementation (e.g. OpenSSL) that supports streamable"},{"line_number":99,"context_line":"decryption of CMS-wrapped encrypted data. More precisely, no implementation we"},{"line_number":100,"context_line":"tested was able to decrypt a symmetrically encrypted, CMS-wrapped container"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_c3fe6438","line":97,"range":{"start_line":97,"start_character":0,"end_line":97,"end_character":10},"in_reply_to":"3f79a3b5_f6b52e7e","updated":"2018-10-22 13:50:58.000000000","message":"Done","commit_id":"ac6e6caba36074c06eca46c7ebb72620fe2c3416"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"d2b13c15b837b5b361bcb4f08f4a1f2179268a3f","unresolved":false,"context_lines":[{"line_number":105,"context_line":"Data model impact"},{"line_number":106,"context_line":"-----------------"},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"None"},{"line_number":109,"context_line":""},{"line_number":110,"context_line":""},{"line_number":111,"context_line":"REST API impact"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_9e3241f3","line":108,"updated":"2018-10-18 10:41:50.000000000","message":"If there will be new fields in the REST API then I guess that data will need to be carried over RPC and therefore will affect nova versioned objects.","commit_id":"ac6e6caba36074c06eca46c7ebb72620fe2c3416"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"25feb49c9c375120f88252d16010c30044981c49","unresolved":false,"context_lines":[{"line_number":105,"context_line":"Data model impact"},{"line_number":106,"context_line":"-----------------"},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"None"},{"line_number":109,"context_line":""},{"line_number":110,"context_line":""},{"line_number":111,"context_line":"REST API impact"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_838dccd5","line":108,"in_reply_to":"3f79a3b5_9e3241f3","updated":"2018-10-22 13:50:58.000000000","message":"I\u0027ve update the REST API impact section. Strictly speaking, there\u0027s no genuine API update as we re-use an existing property in the request body. Do you think there will still be impact to the versioned objects?","commit_id":"ac6e6caba36074c06eca46c7ebb72620fe2c3416"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"98ee83bc064f62de935632ab1c71b10648d7579f","unresolved":false,"context_lines":[{"line_number":113,"context_line":""},{"line_number":114,"context_line":"For creating encrypted images from servers, additional properties in the"},{"line_number":115,"context_line":"request body will need to be introduced to specify the desired encryption"},{"line_number":116,"context_line":"format and key id."},{"line_number":117,"context_line":""},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"Security impact"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_567982c3","line":116,"updated":"2018-10-11 13:52:45.000000000","message":"Please outline the specific REST API changes you will be proposing for this functionality.","commit_id":"ac6e6caba36074c06eca46c7ebb72620fe2c3416"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"d2b13c15b837b5b361bcb4f08f4a1f2179268a3f","unresolved":false,"context_lines":[{"line_number":113,"context_line":""},{"line_number":114,"context_line":"For creating encrypted images from servers, additional properties in the"},{"line_number":115,"context_line":"request body will need to be introduced to specify the desired encryption"},{"line_number":116,"context_line":"format and key id."},{"line_number":117,"context_line":""},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"Security impact"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_fe21f5a2","line":116,"in_reply_to":"3f79a3b5_567982c3","updated":"2018-10-18 10:41:50.000000000","message":"+1","commit_id":"ac6e6caba36074c06eca46c7ebb72620fe2c3416"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"25feb49c9c375120f88252d16010c30044981c49","unresolved":false,"context_lines":[{"line_number":113,"context_line":""},{"line_number":114,"context_line":"For creating encrypted images from servers, additional properties in the"},{"line_number":115,"context_line":"request body will need to be introduced to specify the desired encryption"},{"line_number":116,"context_line":"format and key id."},{"line_number":117,"context_line":""},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"Security impact"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_a38808c3","line":116,"in_reply_to":"3f79a3b5_567982c3","updated":"2018-10-22 13:50:58.000000000","message":"Done","commit_id":"ac6e6caba36074c06eca46c7ebb72620fe2c3416"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"98ee83bc064f62de935632ab1c71b10648d7579f","unresolved":false,"context_lines":[{"line_number":144,"context_line":"------------------"},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"The proposed encryption/decryption mechanisms in Nova will only be utilized"},{"line_number":147,"context_line":"on-demand and skipped entirely for image container types that aren’t"},{"line_number":148,"context_line":"encrypted."},{"line_number":149,"context_line":""},{"line_number":150,"context_line":"Thus, any performance impact is only applicable to the newly introduced"},{"line_number":151,"context_line":"encrypted image type where the processing of the image will have increased"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_b90c8939","line":148,"range":{"start_line":147,"start_character":57,"end_line":148,"end_character":9},"updated":"2018-10-11 13:52:45.000000000","message":"This is confusing to me. Are you saying that an image is only able to be encrypted/decrypted if it is of a particular container_format? This seems odd to me. Wouldn\u0027t the aspect of an image being encrypted or not be tangential to the container format it has? In other words, wouldn\u0027t the entire image object (all the bits of it, etc) be encrypted together as a single unit?","commit_id":"ac6e6caba36074c06eca46c7ebb72620fe2c3416"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"acae2e9d4824c732c4a088b4c5ea3e62a392be02","unresolved":false,"context_lines":[{"line_number":144,"context_line":"------------------"},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"The proposed encryption/decryption mechanisms in Nova will only be utilized"},{"line_number":147,"context_line":"on-demand and skipped entirely for image container types that aren’t"},{"line_number":148,"context_line":"encrypted."},{"line_number":149,"context_line":""},{"line_number":150,"context_line":"Thus, any performance impact is only applicable to the newly introduced"},{"line_number":151,"context_line":"encrypted image type where the processing of the image will have increased"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_d9ffe832","line":148,"range":{"start_line":147,"start_character":57,"end_line":148,"end_character":9},"in_reply_to":"3f79a3b5_b90c8939","updated":"2018-10-12 14:54:35.000000000","message":"Yes, the whole image data is to be encrypted. Isn\u0027t that what the container_format describes? The encapsulated disk_format may vary but the outermost structure is the encrypted format. We currently plan to add a \"os_decrypt_container_format\" property as the Glance guys suggested, which describes the format after decryption. I guess this is what you are looking for?\n\nOn a side note: making encrypted images have a dedicated container_format simplifies the code handling them, since they will most likely always require special treatment. The container_format would be accessible upfront without crawling through the additional metadata properties, reducing code complexity.","commit_id":"ac6e6caba36074c06eca46c7ebb72620fe2c3416"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"98ee83bc064f62de935632ab1c71b10648d7579f","unresolved":false,"context_lines":[{"line_number":148,"context_line":"encrypted."},{"line_number":149,"context_line":""},{"line_number":150,"context_line":"Thus, any performance impact is only applicable to the newly introduced"},{"line_number":151,"context_line":"encrypted image type where the processing of the image will have increased"},{"line_number":152,"context_line":"computational costs and longer processing times than regular images. Impact"},{"line_number":153,"context_line":"will vary depending on the individual host performance and supported CPU"},{"line_number":154,"context_line":"extensions for cipher algorithms."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_194a5d5a","line":151,"range":{"start_line":151,"start_character":0,"end_line":151,"end_character":20},"updated":"2018-10-11 13:52:45.000000000","message":"I don\u0027t see a mention of this new image type anywhere? Per my comment above on line 148, I\u0027m wondering why there would be a new image type versus some separate image property that indicates that the image bits have been encrypted with some particular encryption algorithm and key location.","commit_id":"ac6e6caba36074c06eca46c7ebb72620fe2c3416"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"acae2e9d4824c732c4a088b4c5ea3e62a392be02","unresolved":false,"context_lines":[{"line_number":148,"context_line":"encrypted."},{"line_number":149,"context_line":""},{"line_number":150,"context_line":"Thus, any performance impact is only applicable to the newly introduced"},{"line_number":151,"context_line":"encrypted image type where the processing of the image will have increased"},{"line_number":152,"context_line":"computational costs and longer processing times than regular images. Impact"},{"line_number":153,"context_line":"will vary depending on the individual host performance and supported CPU"},{"line_number":154,"context_line":"extensions for cipher algorithms."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_1997a0ec","line":151,"range":{"start_line":151,"start_character":0,"end_line":151,"end_character":20},"in_reply_to":"3f79a3b5_194a5d5a","updated":"2018-10-12 14:54:35.000000000","message":"That\u0027s basically the new container_format called \"encrypted\". See my other reply to L148","commit_id":"ac6e6caba36074c06eca46c7ebb72620fe2c3416"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"d2b13c15b837b5b361bcb4f08f4a1f2179268a3f","unresolved":false,"context_lines":[{"line_number":151,"context_line":"encrypted image type where the processing of the image will have increased"},{"line_number":152,"context_line":"computational costs and longer processing times than regular images. Impact"},{"line_number":153,"context_line":"will vary depending on the individual host performance and supported CPU"},{"line_number":154,"context_line":"extensions for cipher algorithms."},{"line_number":155,"context_line":""},{"line_number":156,"context_line":""},{"line_number":157,"context_line":"Other deployer impact"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_1e839157","line":154,"updated":"2018-10-18 10:41:50.000000000","message":"Does the extra CPU load will occur on the PCPUs used by the VM or it will be load on the PCPUs used by the host OS?","commit_id":"ac6e6caba36074c06eca46c7ebb72620fe2c3416"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"25feb49c9c375120f88252d16010c30044981c49","unresolved":false,"context_lines":[{"line_number":151,"context_line":"encrypted image type where the processing of the image will have increased"},{"line_number":152,"context_line":"computational costs and longer processing times than regular images. Impact"},{"line_number":153,"context_line":"will vary depending on the individual host performance and supported CPU"},{"line_number":154,"context_line":"extensions for cipher algorithms."},{"line_number":155,"context_line":""},{"line_number":156,"context_line":""},{"line_number":157,"context_line":"Other deployer impact"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_83a62c54","line":154,"in_reply_to":"3f79a3b5_1e839157","updated":"2018-10-22 13:50:58.000000000","message":"Done","commit_id":"ac6e6caba36074c06eca46c7ebb72620fe2c3416"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"c9e6158d47b95ba267f6445eb0c65a64098923fd","unresolved":false,"context_lines":[{"line_number":151,"context_line":"encrypted image type where the processing of the image will have increased"},{"line_number":152,"context_line":"computational costs and longer processing times than regular images. Impact"},{"line_number":153,"context_line":"will vary depending on the individual host performance and supported CPU"},{"line_number":154,"context_line":"extensions for cipher algorithms."},{"line_number":155,"context_line":""},{"line_number":156,"context_line":""},{"line_number":157,"context_line":"Other deployer impact"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_81bf44fc","line":154,"in_reply_to":"3f79a3b5_1e839157","updated":"2018-10-18 11:55:14.000000000","message":"The load will occur on the host PCPUs.","commit_id":"ac6e6caba36074c06eca46c7ebb72620fe2c3416"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"54491fe0a63a0e8d1c3e5e906b9a101aeba66cda","unresolved":false,"context_lines":[{"line_number":151,"context_line":"encrypted image type where the processing of the image will have increased"},{"line_number":152,"context_line":"computational costs and longer processing times than regular images. Impact"},{"line_number":153,"context_line":"will vary depending on the individual host performance and supported CPU"},{"line_number":154,"context_line":"extensions for cipher algorithms."},{"line_number":155,"context_line":""},{"line_number":156,"context_line":""},{"line_number":157,"context_line":"Other deployer impact"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_02947640","line":154,"in_reply_to":"3f79a3b5_81bf44fc","updated":"2018-10-19 15:14:10.000000000","message":"this info could be a input for the deployer about host resource dimensioning.","commit_id":"ac6e6caba36074c06eca46c7ebb72620fe2c3416"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"98ee83bc064f62de935632ab1c71b10648d7579f","unresolved":false,"context_lines":[{"line_number":157,"context_line":"Other deployer impact"},{"line_number":158,"context_line":"---------------------"},{"line_number":159,"context_line":""},{"line_number":160,"context_line":"* The Rootwrapper configuration for compute hosts might need to be adjusted"},{"line_number":161,"context_line":"depending on the encryption mechanism to whitelist any executable needed."},{"line_number":162,"context_line":""},{"line_number":163,"context_line":"* A key manager - like Barbican - is required."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_3978798d","line":160,"range":{"start_line":160,"start_character":6,"end_line":160,"end_character":32},"updated":"2018-10-11 13:52:45.000000000","message":"this is more oslo.privsep now, but yes, same idea.","commit_id":"ac6e6caba36074c06eca46c7ebb72620fe2c3416"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"acae2e9d4824c732c4a088b4c5ea3e62a392be02","unresolved":false,"context_lines":[{"line_number":157,"context_line":"Other deployer impact"},{"line_number":158,"context_line":"---------------------"},{"line_number":159,"context_line":""},{"line_number":160,"context_line":"* The Rootwrapper configuration for compute hosts might need to be adjusted"},{"line_number":161,"context_line":"depending on the encryption mechanism to whitelist any executable needed."},{"line_number":162,"context_line":""},{"line_number":163,"context_line":"* A key manager - like Barbican - is required."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_79bfb45f","line":160,"range":{"start_line":160,"start_character":6,"end_line":160,"end_character":32},"in_reply_to":"3f79a3b5_3978798d","updated":"2018-10-12 14:54:35.000000000","message":"So, we should go for privsep from the start?","commit_id":"ac6e6caba36074c06eca46c7ebb72620fe2c3416"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"98ee83bc064f62de935632ab1c71b10648d7579f","unresolved":false,"context_lines":[{"line_number":194,"context_line":"Work Items"},{"line_number":195,"context_line":"----------"},{"line_number":196,"context_line":""},{"line_number":197,"context_line":"* Add a decryption implementation in Nova for creating servers (ephemeral"},{"line_number":198,"context_line":"storage disks) from GPG encrypted images"},{"line_number":199,"context_line":""},{"line_number":200,"context_line":"* Add a dedicated encryption workflow and implementation in Nova for creating"},{"line_number":201,"context_line":"encrypted images from servers using the proposed image encryption format (GPG)"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_192b3d33","line":198,"range":{"start_line":197,"start_character":0,"end_line":198,"end_character":40},"updated":"2018-10-11 13:52:45.000000000","message":"I would suggest that you could make a generic encryption/decryption steaming library in Oslo and keep that code there and just add the oslo library as a dependency to nova.\n\nThis is the way that the folks working on certificate signing features in Nova went. They created the cursive library [1] for digital signature validation and then import cursive into nova [2]\n\n[1] https://github.com/openstack/cursive\n[2] https://github.com/openstack/nova/blob/c6218428e9b29a2c52808ec7d27b4b21aadc0299/nova/image/glance.py#L31-L33\nhttps://github.com/openstack/nova/blob/c6218428e9b29a2c52808ec7d27b4b21aadc0299/nova/image/glance.py#L414-L420","commit_id":"ac6e6caba36074c06eca46c7ebb72620fe2c3416"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"acae2e9d4824c732c4a088b4c5ea3e62a392be02","unresolved":false,"context_lines":[{"line_number":194,"context_line":"Work Items"},{"line_number":195,"context_line":"----------"},{"line_number":196,"context_line":""},{"line_number":197,"context_line":"* Add a decryption implementation in Nova for creating servers (ephemeral"},{"line_number":198,"context_line":"storage disks) from GPG encrypted images"},{"line_number":199,"context_line":""},{"line_number":200,"context_line":"* Add a dedicated encryption workflow and implementation in Nova for creating"},{"line_number":201,"context_line":"encrypted images from servers using the proposed image encryption format (GPG)"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_399cdc0b","line":198,"range":{"start_line":197,"start_character":0,"end_line":198,"end_character":40},"in_reply_to":"3f79a3b5_192b3d33","updated":"2018-10-12 14:54:35.000000000","message":"This is what we intended to do actually, see the reference to a global library in the \"Dependencies\" section. Also, this is a very controversial discussion point between the involved projects currently. We had all kinds of suggestions on where to put the code and there seems to be no broad consent about this. We are currently suggesting the OpenStack SDK as it is meant to be included into most projects in the near future anyways [1].\n\n[1] http://eavesdrop.openstack.org/irclogs/%23openstack-sdks/%23openstack-sdks.2018-06-29.log.html#t2018-06-29T12:35:11","commit_id":"ac6e6caba36074c06eca46c7ebb72620fe2c3416"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"96dd7b9c6492a448813e037db3608f960baab8b7","unresolved":false,"context_lines":[{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"Image Encryption and Decryption"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"OpenStack already has the ability to create encrypted volumes and ephemeral"},{"line_number":12,"context_line":"storage to ensure the confidentiality of block data. In contrast to that,"},{"line_number":13,"context_line":"images are currently handled without protection towards confidentiality, only"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_1c46cb57","line":10,"updated":"2018-12-06 00:16:44.000000000","message":"You need to link your spec to a blueprint here, see the template:\n\nhttps://github.com/openstack/nova-specs/blob/master/specs/stein-template.rst#example-spec---the-title-of-your-blueprint","commit_id":"0af254d5f48950ed8705f917ccce3e12a5cd9ca1"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"f7ca922e73559b71491287cced6d5b0de53eb4ee","unresolved":false,"context_lines":[{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"OpenStack already has the ability to create encrypted volumes and ephemeral"},{"line_number":12,"context_line":"storage to ensure the confidentiality of block data. In contrast to that,"},{"line_number":13,"context_line":"images are currently handled without protection towards confidentiality, only"},{"line_number":14,"context_line":"providing the possibility to ensure integrity using image signatures. For"},{"line_number":15,"context_line":"further protection of user data - e.g. when a user uploads an image containing"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_24c2c4ea","line":12,"range":{"start_line":12,"start_character":22,"end_line":12,"end_character":37},"updated":"2019-05-23 14:53:00.000000000","message":"I think this is the main win for users here and should be spoken of more in this section and the problem description.","commit_id":"0af254d5f48950ed8705f917ccce3e12a5cd9ca1"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"f7ca922e73559b71491287cced6d5b0de53eb4ee","unresolved":false,"context_lines":[{"line_number":8,"context_line":"Image Encryption and Decryption"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"OpenStack already has the ability to create encrypted volumes and ephemeral"},{"line_number":12,"context_line":"storage to ensure the confidentiality of block data. In contrast to that,"},{"line_number":13,"context_line":"images are currently handled without protection towards confidentiality, only"},{"line_number":14,"context_line":"providing the possibility to ensure integrity using image signatures. For"},{"line_number":15,"context_line":"further protection of user data - e.g. when a user uploads an image containing"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_2493a451","line":12,"range":{"start_line":11,"start_character":66,"end_line":12,"end_character":7},"updated":"2019-05-23 14:53:00.000000000","message":"I\u0027d call the Libvirt virt driver capabilities limited at best currently.","commit_id":"0af254d5f48950ed8705f917ccce3e12a5cd9ca1"},{"author":{"_account_id":9555,"name":"Matthew Booth","email":"mbooth@redhat.com","username":"MatthewBooth"},"change_message_id":"48b55313da2d9bb79fa07c097c8008c39a6a840b","unresolved":false,"context_lines":[{"line_number":13,"context_line":"images are currently handled without protection towards confidentiality, only"},{"line_number":14,"context_line":"providing the possibility to ensure integrity using image signatures. For"},{"line_number":15,"context_line":"further protection of user data - e.g. when a user uploads an image containing"},{"line_number":16,"context_line":"private data or confidential information - the image data should not be"},{"line_number":17,"context_line":"accessible for unauthorized entities. For this purpose, an encrypted image"},{"line_number":18,"context_line":"format is to be introduced in OpenStack."},{"line_number":19,"context_line":"In conclusion, several adjustments to support image encryption/decryption in"},{"line_number":20,"context_line":"various projects, e.g. Nova, Glance, Cinder and OSC, need to be implemented."}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_ae457c19","line":17,"range":{"start_line":16,"start_character":43,"end_line":17,"end_character":36},"updated":"2019-05-20 14:11:27.000000000","message":"Why not just rely on glance permissions and a secure transport during upload?\n\nMy concern here is that we might be selling this as technology which secures the contents of an encrypted image from openstack itself.","commit_id":"0af254d5f48950ed8705f917ccce3e12a5cd9ca1"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"f7ca922e73559b71491287cced6d5b0de53eb4ee","unresolved":false,"context_lines":[{"line_number":13,"context_line":"images are currently handled without protection towards confidentiality, only"},{"line_number":14,"context_line":"providing the possibility to ensure integrity using image signatures. For"},{"line_number":15,"context_line":"further protection of user data - e.g. when a user uploads an image containing"},{"line_number":16,"context_line":"private data or confidential information - the image data should not be"},{"line_number":17,"context_line":"accessible for unauthorized entities. For this purpose, an encrypted image"},{"line_number":18,"context_line":"format is to be introduced in OpenStack."},{"line_number":19,"context_line":"In conclusion, several adjustments to support image encryption/decryption in"},{"line_number":20,"context_line":"various projects, e.g. Nova, Glance, Cinder and OSC, need to be implemented."}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_e4490c8b","line":17,"range":{"start_line":16,"start_character":43,"end_line":17,"end_character":36},"in_reply_to":"bfb3d3c7_ae457c19","updated":"2019-05-23 14:53:00.000000000","message":"I think this is more about data confidentiality at rest in a public cloud setting. Yes there will be various layers of defence before someone could get access to the image but I still think this is valid additional layer.","commit_id":"0af254d5f48950ed8705f917ccce3e12a5cd9ca1"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"f7ca922e73559b71491287cced6d5b0de53eb4ee","unresolved":false,"context_lines":[{"line_number":52,"context_line":"Use Cases"},{"line_number":53,"context_line":"---------"},{"line_number":54,"context_line":""},{"line_number":55,"context_line":"1. A user wants to create a new server based on an encrypted image. The"},{"line_number":56,"context_line":"corresponding compute host has to be able to decrypt the image"},{"line_number":57,"context_line":"using the symmetric key stored in the key manager and transform it into the"},{"line_number":58,"context_line":"requested resource (server disk image)."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"2.1. A user wants to snapshot a server that uses an unencrypted disk image"},{"line_number":61,"context_line":"(ephemeral storage) and encrypt the snapshot before storage. The target image"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_2435e4f7","line":58,"range":{"start_line":55,"start_character":0,"end_line":58,"end_character":39},"updated":"2019-05-23 14:53:00.000000000","message":"I question the need to ever decrypt the image here, with LUKS etc we can rotate keys out without every fully decrypting the image.","commit_id":"0af254d5f48950ed8705f917ccce3e12a5cd9ca1"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"f7ca922e73559b71491287cced6d5b0de53eb4ee","unresolved":false,"context_lines":[{"line_number":57,"context_line":"using the symmetric key stored in the key manager and transform it into the"},{"line_number":58,"context_line":"requested resource (server disk image)."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"2.1. A user wants to snapshot a server that uses an unencrypted disk image"},{"line_number":61,"context_line":"(ephemeral storage) and encrypt the snapshot before storage. The target image"},{"line_number":62,"context_line":"is to be encrypted using the proposed image encryption mechanism and a"},{"line_number":63,"context_line":"specified key."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"2.2. A user wants to snapshot a server that uses an encrypted disk image"},{"line_number":66,"context_line":"(ephemeral storage). Because the encryption mechanisms used for encrypted disk"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_a409d431","line":63,"range":{"start_line":60,"start_character":0,"end_line":63,"end_character":14},"updated":"2019-05-23 14:53:00.000000000","message":"That\u0027s an odd use case tbh, if the user hasn\u0027t encrypted their disks why would they want to encrypt their snapshots?","commit_id":"0af254d5f48950ed8705f917ccce3e12a5cd9ca1"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"f7ca922e73559b71491287cced6d5b0de53eb4ee","unresolved":false,"context_lines":[{"line_number":63,"context_line":"specified key."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"2.2. A user wants to snapshot a server that uses an encrypted disk image"},{"line_number":66,"context_line":"(ephemeral storage). Because the encryption mechanisms used for encrypted disk"},{"line_number":67,"context_line":"images and image encryption differ, the data is to be re-encrypted using the"},{"line_number":68,"context_line":"proposed image encryption mechanism and a specified key before storage."},{"line_number":69,"context_line":""},{"line_number":70,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_8425b0c4","line":67,"range":{"start_line":66,"start_character":21,"end_line":67,"end_character":34},"updated":"2019-05-23 14:53:00.000000000","message":"I think you mean that the encrypted disk image and snapshot?","commit_id":"0af254d5f48950ed8705f917ccce3e12a5cd9ca1"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"f7ca922e73559b71491287cced6d5b0de53eb4ee","unresolved":false,"context_lines":[{"line_number":76,"context_line":"properties to store information about the encryption. See the referenced"},{"line_number":77,"context_line":"Glance spec for details."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"In Nova we want to add support for decrypting an encrypted image when a"},{"line_number":80,"context_line":"server’s ephemeral disk is created. This includes direct decryption"},{"line_number":81,"context_line":"streaming for encrypted disks. Nova should select a suitable mechanism"},{"line_number":82,"context_line":"according to the image container_format and metadata. The symmetric key will"},{"line_number":83,"context_line":"be retrieved from the key manager (e.g. Barbican)."},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"Additionally, Nova should be able to encrypt server data in a similar fashion,"},{"line_number":86,"context_line":"if the user requests an encrypted image to be created from a server according"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_64443cb8","line":83,"range":{"start_line":79,"start_character":0,"end_line":83,"end_character":50},"updated":"2019-05-23 14:53:00.000000000","message":"Doesn\u0027t the decryption of the image on the compute host defeat the purpose of this whole endeavor?\n\nHow would you stream the decrypted disk content into QEMU for example? NBD?\n\nIf we used LUKS we could copy the image to the compute, rotate the keys (passphrases) and use the still encrypted image natively.","commit_id":"0af254d5f48950ed8705f917ccce3e12a5cd9ca1"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"f7ca922e73559b71491287cced6d5b0de53eb4ee","unresolved":false,"context_lines":[{"line_number":103,"context_line":"OpenStack components to prevent individual implementations of the encryption"},{"line_number":104,"context_line":"mechanism."},{"line_number":105,"context_line":""},{"line_number":106,"context_line":"For general image encryption, we propose to use an implementation of symmetric"},{"line_number":107,"context_line":"AES 256 provided by GnuPG as a basic mechanism supported by this draft. It is"},{"line_number":108,"context_line":"a well established implementation of PGP and supports streamable"},{"line_number":109,"context_line":"encryption/decryption processes, which is important as we require the"},{"line_number":110,"context_line":"streamability of the encryption/decryption mechanism for two reasons:"},{"line_number":111,"context_line":""},{"line_number":112,"context_line":"1. Loading entire images into the memory of compute hosts is unacceptable."},{"line_number":113,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_0729c288","line":110,"range":{"start_line":106,"start_character":0,"end_line":110,"end_character":69},"updated":"2019-05-23 14:53:00.000000000","message":"As above, I\u0027m not sure about using this over something like LUKS that allows simple key rotation and is already a supported disk format for QEMU etc.","commit_id":"0af254d5f48950ed8705f917ccce3e12a5cd9ca1"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"f7ca922e73559b71491287cced6d5b0de53eb4ee","unresolved":false,"context_lines":[{"line_number":114,"context_line":"2. We propose direct decryption-streaming into the target storage disk to"},{"line_number":115,"context_line":"   prevent the creation of temporary unencrypted files."},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"The decryption of the image should be done right when it is streamed into the"},{"line_number":118,"context_line":"ephemeral storage, i.e. a direct conversion of the encrypted image into"},{"line_number":119,"context_line":"encrypted ephemeral disk prior to server start, avoiding the creation of"},{"line_number":120,"context_line":"temporary unencrypted files."},{"line_number":121,"context_line":""},{"line_number":122,"context_line":"We propose to limit the usage of encrypted images to ephemeral storage"},{"line_number":123,"context_line":"backends that support encryption. For LibVirt this only applies to the LVM"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_44225802","line":120,"range":{"start_line":117,"start_character":0,"end_line":120,"end_character":28},"updated":"2019-05-23 14:53:00.000000000","message":"You have lost me here, what\u0027s the actual disk format of the ephemeral disk used by the instance? RAW?","commit_id":"0af254d5f48950ed8705f917ccce3e12a5cd9ca1"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"96dd7b9c6492a448813e037db3608f960baab8b7","unresolved":false,"context_lines":[{"line_number":120,"context_line":"temporary unencrypted files."},{"line_number":121,"context_line":""},{"line_number":122,"context_line":"We propose to limit the usage of encrypted images to ephemeral storage"},{"line_number":123,"context_line":"backends that support encryption. For LibVirt this only applies to the LVM"},{"line_number":124,"context_line":"backend. Otherwise image data would be exposed through the ephemeral storage."},{"line_number":125,"context_line":""},{"line_number":126,"context_line":""},{"line_number":127,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_1c880b18","line":124,"range":{"start_line":123,"start_character":34,"end_line":124,"end_character":7},"updated":"2018-12-06 00:16:44.000000000","message":"Does this mean this proposal would only implement encrypted image support for the LVM backend of the libvirt driver? Would it be possible to implement encrypted image support for other virt drivers if their subteams were interested in adding it? Or is the libvirt driver the only one that could support this?","commit_id":"0af254d5f48950ed8705f917ccce3e12a5cd9ca1"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"f7ca922e73559b71491287cced6d5b0de53eb4ee","unresolved":false,"context_lines":[{"line_number":120,"context_line":"temporary unencrypted files."},{"line_number":121,"context_line":""},{"line_number":122,"context_line":"We propose to limit the usage of encrypted images to ephemeral storage"},{"line_number":123,"context_line":"backends that support encryption. For LibVirt this only applies to the LVM"},{"line_number":124,"context_line":"backend. Otherwise image data would be exposed through the ephemeral storage."},{"line_number":125,"context_line":""},{"line_number":126,"context_line":""},{"line_number":127,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_4450185e","line":124,"range":{"start_line":123,"start_character":34,"end_line":124,"end_character":7},"in_reply_to":"3f79a3b5_1c880b18","updated":"2019-05-23 14:53:00.000000000","message":"FWIW this implementation leaves a decrypted device on the host and doesn\u0027t use LUKS.","commit_id":"0af254d5f48950ed8705f917ccce3e12a5cd9ca1"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"7a3b742587d9351d947ee3c8dbb4a850c1da3d04","unresolved":false,"context_lines":[{"line_number":139,"context_line":"Data model impact"},{"line_number":140,"context_line":"-----------------"},{"line_number":141,"context_line":""},{"line_number":142,"context_line":"None"},{"line_number":143,"context_line":""},{"line_number":144,"context_line":""},{"line_number":145,"context_line":"REST API impact"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_fd369401","line":142,"updated":"2018-11-20 10:37:23.000000000","message":"If there will be new Glance image metadata properties then Nova\u0027s ImageMeta versioned object [1] needs to be extended.\n\n[1] https://github.com/openstack/nova/blob/c6218428e9b29a2c52808ec7d27b4b21aadc0299/nova/objects/image_meta.py#L34","commit_id":"0af254d5f48950ed8705f917ccce3e12a5cd9ca1"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"96dd7b9c6492a448813e037db3608f960baab8b7","unresolved":false,"context_lines":[{"line_number":139,"context_line":"Data model impact"},{"line_number":140,"context_line":"-----------------"},{"line_number":141,"context_line":""},{"line_number":142,"context_line":"None"},{"line_number":143,"context_line":""},{"line_number":144,"context_line":""},{"line_number":145,"context_line":"REST API impact"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_5cf763d3","line":142,"in_reply_to":"3f79a3b5_fd369401","updated":"2018-12-06 00:16:44.000000000","message":"+1 looks like they would be additions to the ImageMetaProps class.","commit_id":"0af254d5f48950ed8705f917ccce3e12a5cd9ca1"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"f7ca922e73559b71491287cced6d5b0de53eb4ee","unresolved":false,"context_lines":[{"line_number":154,"context_line":"* \"os_encrypt_type\"   - encryption type, e.g. \"symmetric\""},{"line_number":155,"context_line":"* \"os_encrypt_cipher\" - the cipher algorithm, e.g. \"AES256\""},{"line_number":156,"context_line":"* \"os_encrypt_key_id\" - reference to key in the key manager"},{"line_number":157,"context_line":"* \u0027os_decrypt_container_format\u0027 - format after payload decryption"},{"line_number":158,"context_line":"* \u0027os_decrypt_size\u0027 - size after payload decryption"},{"line_number":159,"context_line":""},{"line_number":160,"context_line":"This is not strictly a change in the API, since the \"metadata\" object is"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_873cd2c8","line":157,"range":{"start_line":157,"start_character":0,"end_line":157,"end_character":65},"updated":"2019-05-23 14:53:00.000000000","message":"Why would we need to know this?","commit_id":"0af254d5f48950ed8705f917ccce3e12a5cd9ca1"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"96dd7b9c6492a448813e037db3608f960baab8b7","unresolved":false,"context_lines":[{"line_number":205,"context_line":"Other deployer impact"},{"line_number":206,"context_line":"---------------------"},{"line_number":207,"context_line":""},{"line_number":208,"context_line":"* The Rootwrapper configuration for compute hosts might need to be adjusted"},{"line_number":209,"context_line":"depending on the encryption mechanism to whitelist any executable needed."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"* A key manager - like Barbican - is required."}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_fcd66f25","line":208,"range":{"start_line":208,"start_character":6,"end_line":208,"end_character":17},"updated":"2018-12-06 00:16:44.000000000","message":"This would need to be done with privsep instead of rootwrap, as we transitioned away from using rootwrap for escalated permissions.","commit_id":"0af254d5f48950ed8705f917ccce3e12a5cd9ca1"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"96dd7b9c6492a448813e037db3608f960baab8b7","unresolved":false,"context_lines":[{"line_number":247,"context_line":""},{"line_number":248,"context_line":"* Add a dedicated encryption workflow and implementation in Nova for creating"},{"line_number":249,"context_line":"  encrypted images from servers using the proposed image encryption format"},{"line_number":250,"context_line":"  (GPG)"},{"line_number":251,"context_line":""},{"line_number":252,"context_line":""},{"line_number":253,"context_line":"Dependencies"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_1c9a4b74","line":250,"updated":"2018-12-06 00:16:44.000000000","message":"Maybe it\u0027s just me, but usually the work items are described in much more detail here. For example, one work item would be: \"Add encryption-related glance image properties to the ImageMetaProps object\". And another work item would describe where/how (libvirt driver? other?) the image properties will be used. And so on. The \"Work Items\" section should be able to be used as a checklist for all main steps that need to be done to implement the feature.","commit_id":"0af254d5f48950ed8705f917ccce3e12a5cd9ca1"}],"specs/train/approved/image-encryption.rst":[{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"d070a12eaf82ca382458339eec13a7817c2b7cc0","unresolved":false,"context_lines":[{"line_number":108,"context_line":"handled in the usual way. As the image data has then been decrypted (and is at"},{"line_number":109,"context_line":"best located in an encrypted ephemeral storage) the encryption-related"},{"line_number":110,"context_line":"additional metadata properties become irrelevant and thus may be discarded"},{"line_number":111,"context_line":"instead of being carried over into the servers metadata."},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"The second addition, the encryption, takes places when an image is created"},{"line_number":114,"context_line":"from a server with ephemeral storage. It happens in a similar fashion as the"}],"source_content_type":"text/x-rst","patch_set":8,"id":"9fb8cfa7_bbb08441","line":111,"range":{"start_line":111,"start_character":39,"end_line":111,"end_character":46},"updated":"2019-07-02 13:57:29.000000000","message":"server\u0027s","commit_id":"8554ea5c39f9226147673532181dfc600207d81e"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"d070a12eaf82ca382458339eec13a7817c2b7cc0","unresolved":false,"context_lines":[{"line_number":110,"context_line":"additional metadata properties become irrelevant and thus may be discarded"},{"line_number":111,"context_line":"instead of being carried over into the servers metadata."},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"The second addition, the encryption, takes places when an image is created"},{"line_number":114,"context_line":"from a server with ephemeral storage. It happens in a similar fashion as the"},{"line_number":115,"context_line":"decryption. At the point the image file is created, Nova selects a suitable"},{"line_number":116,"context_line":"encryption method from os_brick and uses it to encrypt the image. The metadata"}],"source_content_type":"text/x-rst","patch_set":8,"id":"9fb8cfa7_7b88cc6f","line":113,"range":{"start_line":113,"start_character":43,"end_line":113,"end_character":49},"updated":"2019-07-02 13:57:29.000000000","message":"place","commit_id":"8554ea5c39f9226147673532181dfc600207d81e"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"d070a12eaf82ca382458339eec13a7817c2b7cc0","unresolved":false,"context_lines":[{"line_number":117,"context_line":"for the image is gathered from the encryption request and workflow and is"},{"line_number":118,"context_line":"saved into the Glance image metadata properties. To indicate that the image to"},{"line_number":119,"context_line":"be created should be encrypted, the \"metadata\" object of the \"createImage\""},{"line_number":120,"context_line":"action will be adjusted as described in the REST API section."},{"line_number":121,"context_line":""},{"line_number":122,"context_line":"When handling encrypted images, Nova should respect the \"os_decrypt_size\""},{"line_number":123,"context_line":"property. Whenever an encrypted snapshot is created, this property should be"}],"source_content_type":"text/x-rst","patch_set":8,"id":"9fb8cfa7_3b0fb4e0","line":120,"updated":"2019-07-02 13:57:29.000000000","message":"Thanks for adding this; it makes the pieces come together for me.","commit_id":"8554ea5c39f9226147673532181dfc600207d81e"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"81dc86c81a59b5d0e88df5a9f8ad44e96e65293b","unresolved":false,"context_lines":[{"line_number":128,"context_line":"bypassing the temporary image size changes due to encryption."},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"The implementations in Nova should make use of a centralized encryption"},{"line_number":131,"context_line":"implementation provided by a global library, shared between all involved"},{"line_number":132,"context_line":"OpenStack components to prevent individual implementations of the encryption"},{"line_number":133,"context_line":"mechanism."},{"line_number":134,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"9fb8cfa7_ed44ef49","line":131,"range":{"start_line":131,"start_character":27,"end_line":131,"end_character":43},"updated":"2019-07-03 13:08:49.000000000","message":"nit - Would be nice if we could say where but it isn\u0027t critical to this spec landing.","commit_id":"8554ea5c39f9226147673532181dfc600207d81e"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"36d64efbbd9ad800b8cd781da0eca86380b3ca7d","unresolved":false,"context_lines":[{"line_number":128,"context_line":"bypassing the temporary image size changes due to encryption."},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"The implementations in Nova should make use of a centralized encryption"},{"line_number":131,"context_line":"implementation provided by a global library, shared between all involved"},{"line_number":132,"context_line":"OpenStack components to prevent individual implementations of the encryption"},{"line_number":133,"context_line":"mechanism."},{"line_number":134,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"7faddb67_cd7321b1","line":131,"range":{"start_line":131,"start_character":27,"end_line":131,"end_character":43},"in_reply_to":"9fb8cfa7_ed44ef49","updated":"2019-07-23 16:03:15.000000000","message":"i assume it will be os-brick but it could be a oslo lib too i guess if we wanted to create a new one.","commit_id":"8554ea5c39f9226147673532181dfc600207d81e"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"25a6cac566bc1c4eab3e2bf582b9e2d0d9fed794","unresolved":false,"context_lines":[{"line_number":138,"context_line":"encryption/decryption processes, which is important as we require the"},{"line_number":139,"context_line":"streamability of the encryption/decryption mechanism for two reasons:"},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"1. Loading entire images into the memory of compute hosts is unacceptable."},{"line_number":142,"context_line":""},{"line_number":143,"context_line":"2. We propose direct decryption-streaming into the target storage disk to"},{"line_number":144,"context_line":"   prevent the creation of temporary unencrypted files."}],"source_content_type":"text/x-rst","patch_set":8,"id":"9fb8cfa7_7081c14d","line":141,"range":{"start_line":141,"start_character":0,"end_line":141,"end_character":74},"updated":"2019-07-02 21:30:23.000000000","message":"yes nova shoudl not do that...","commit_id":"8554ea5c39f9226147673532181dfc600207d81e"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"25a6cac566bc1c4eab3e2bf582b9e2d0d9fed794","unresolved":false,"context_lines":[{"line_number":140,"context_line":""},{"line_number":141,"context_line":"1. Loading entire images into the memory of compute hosts is unacceptable."},{"line_number":142,"context_line":""},{"line_number":143,"context_line":"2. We propose direct decryption-streaming into the target storage disk to"},{"line_number":144,"context_line":"   prevent the creation of temporary unencrypted files."},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"The decryption of the image should be done right when it is streamed into the"},{"line_number":147,"context_line":"ephemeral storage, i.e. a direct conversion of the encrypted image into"}],"source_content_type":"text/x-rst","patch_set":8,"id":"9fb8cfa7_50803d47","line":144,"range":{"start_line":143,"start_character":0,"end_line":144,"end_character":55},"updated":"2019-07-02 21:30:23.000000000","message":"+1","commit_id":"8554ea5c39f9226147673532181dfc600207d81e"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"81dc86c81a59b5d0e88df5a9f8ad44e96e65293b","unresolved":false,"context_lines":[{"line_number":172,"context_line":"without trying to completely load it into memory or suffering from other"},{"line_number":173,"context_line":"limitations regarding big files."},{"line_number":174,"context_line":""},{"line_number":175,"context_line":"We also evaluated an image encryption implementation based on LUKS which is"},{"line_number":176,"context_line":"already used in Cinder and Nova as an encryption mechanism for volumes and"},{"line_number":177,"context_line":"ephemeral disks respectively. However, we were unable to find a suitable"},{"line_number":178,"context_line":"solution to directly handle file-based LUKS encryption in user space. Firstly,"},{"line_number":179,"context_line":"the handling of LUKS devices (even when file-based) via cryptsetup always"},{"line_number":180,"context_line":"requires the dm-crypt kernel module and corresponding root privileges."},{"line_number":181,"context_line":"Secondly, in contrast to native LUKS used by LibVirt, the LUKS handling"},{"line_number":182,"context_line":"available via cryptsetup creates temporary device mapper endpoints where data"},{"line_number":183,"context_line":"is read from or written to. There is no direct reading/writing from/to an"},{"line_number":184,"context_line":"encrypted LUKS file and LUKS opening/closing needs to be handled accordingly."},{"line_number":185,"context_line":"Lastly, LUKS is a format primarily designed for disk encryption. Although it"},{"line_number":186,"context_line":"may be used for files as well (by formatting files as LUKS devices), the"},{"line_number":187,"context_line":"handling is rather inconvenient; for example, the size of the LUKS container"},{"line_number":188,"context_line":"file needs to be calculated and allocated beforehand since it acts like a disk"}],"source_content_type":"text/x-rst","patch_set":8,"id":"9fb8cfa7_227456d0","line":185,"range":{"start_line":175,"start_character":0,"end_line":185,"end_character":64},"updated":"2019-07-03 13:08:49.000000000","message":"Thanks for adding this, I was sure qemu-img convert etc could handle this but on further review that isn\u0027t the case at present.","commit_id":"8554ea5c39f9226147673532181dfc600207d81e"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"81dc86c81a59b5d0e88df5a9f8ad44e96e65293b","unresolved":false,"context_lines":[{"line_number":183,"context_line":"is read from or written to. There is no direct reading/writing from/to an"},{"line_number":184,"context_line":"encrypted LUKS file and LUKS opening/closing needs to be handled accordingly."},{"line_number":185,"context_line":"Lastly, LUKS is a format primarily designed for disk encryption. Although it"},{"line_number":186,"context_line":"may be used for files as well (by formatting files as LUKS devices), the"},{"line_number":187,"context_line":"handling is rather inconvenient; for example, the size of the LUKS container"},{"line_number":188,"context_line":"file needs to be calculated and allocated beforehand since it acts like a disk"},{"line_number":189,"context_line":"with a fixed size."},{"line_number":190,"context_line":""},{"line_number":191,"context_line":""},{"line_number":192,"context_line":"Data model impact"}],"source_content_type":"text/x-rst","patch_set":8,"id":"9fb8cfa7_a2bb6673","line":189,"range":{"start_line":186,"start_character":69,"end_line":189,"end_character":18},"updated":"2019-07-03 13:08:49.000000000","message":"nit - That isn\u0027t actually true, you can have sparse files that contain a LUKS header that are then mapped to what appears to be a fully allocated block device using cryptsetup.","commit_id":"8554ea5c39f9226147673532181dfc600207d81e"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"25a6cac566bc1c4eab3e2bf582b9e2d0d9fed794","unresolved":false,"context_lines":[{"line_number":282,"context_line":"pCPU."},{"line_number":283,"context_line":""},{"line_number":284,"context_line":""},{"line_number":285,"context_line":"Other deployer impact"},{"line_number":286,"context_line":"---------------------"},{"line_number":287,"context_line":""},{"line_number":288,"context_line":"* A key manager - like Barbican - is required."}],"source_content_type":"text/x-rst","patch_set":8,"id":"9fb8cfa7_702b0133","line":285,"range":{"start_line":285,"start_character":0,"end_line":285,"end_character":21},"updated":"2019-07-02 21:30:23.000000000","message":"so we dont cover instance lifecycle operation in this spec.\n\nhave you thought about how this will work with live migration, cold migration ,shelve and rescue.\n\nfor cold migration  assume we can jsut to the normal rsync/block copy we do and as long we can retrive the encyrption key and pass it to the destination qemu it should be fine.\n\nfor live migration i assume libvirt/qemu will just do everthing for use so i dont expect use to need to do anything special.\n\nrescue is more tricky as i am booting form either a second copy of the same image or a rescue image i have provided but i will need to be able ot acess the encryped servce epmeral disk to be able to rescue it.\n\nand for shelve we auto create a snap shot so  we will need to ensure that shelving an encurpted instaces auto encrypts the snapshot. we might also want to allow you to do an encrypetd shevelve of an unencrypted image.\n\nfinally for cross cell resize/migrate we plan to also create snapshots since we can assume we ca rsync the file between the compute nodes so as with shelve we need to auto encrypt the snapshot.\n\nwe shoudl ideally document the expected behavior in  all of these cases.","commit_id":"8554ea5c39f9226147673532181dfc600207d81e"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"04872aa433693cb77703be4bc813b448c8aae7b2","unresolved":false,"context_lines":[{"line_number":282,"context_line":"pCPU."},{"line_number":283,"context_line":""},{"line_number":284,"context_line":""},{"line_number":285,"context_line":"Other deployer impact"},{"line_number":286,"context_line":"---------------------"},{"line_number":287,"context_line":""},{"line_number":288,"context_line":"* A key manager - like Barbican - is required."}],"source_content_type":"text/x-rst","patch_set":8,"id":"9fb8cfa7_10f40587","line":285,"range":{"start_line":285,"start_character":0,"end_line":285,"end_character":21},"in_reply_to":"9fb8cfa7_702b0133","updated":"2019-07-02 21:46:19.000000000","message":"change to -1.\n\nim still happy with the rest of the spec but i think we should document what server lifecycle action are supproted and the interaction with shelve and cross cell resize.\n\nif the documetation is \"it just works\" then awsome but i assume some work would be requried to make this all work?","commit_id":"8554ea5c39f9226147673532181dfc600207d81e"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"81dc86c81a59b5d0e88df5a9f8ad44e96e65293b","unresolved":false,"context_lines":[{"line_number":339,"context_line":""},{"line_number":340,"context_line":"* This spec requires the implementation of appropriate encryption/decryption"},{"line_number":341,"context_line":"  functionality in a global library shared between the components involved in"},{"line_number":342,"context_line":"  image encryption workflows (Nova, Cinder, OSC), like os-brick"},{"line_number":343,"context_line":""},{"line_number":344,"context_line":"Testing"},{"line_number":345,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":8,"id":"9fb8cfa7_2d6447e5","line":342,"range":{"start_line":342,"start_character":55,"end_line":342,"end_character":63},"updated":"2019-07-03 13:08:49.000000000","message":"Ah! Please ignore my earlier nit.","commit_id":"8554ea5c39f9226147673532181dfc600207d81e"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"81dc86c81a59b5d0e88df5a9f8ad44e96e65293b","unresolved":false,"context_lines":[{"line_number":339,"context_line":""},{"line_number":340,"context_line":"* This spec requires the implementation of appropriate encryption/decryption"},{"line_number":341,"context_line":"  functionality in a global library shared between the components involved in"},{"line_number":342,"context_line":"  image encryption workflows (Nova, Cinder, OSC), like os-brick"},{"line_number":343,"context_line":""},{"line_number":344,"context_line":"Testing"},{"line_number":345,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":8,"id":"9fb8cfa7_0dace3ec","line":342,"range":{"start_line":342,"start_character":44,"end_line":342,"end_character":47},"updated":"2019-07-03 13:08:49.000000000","message":"FWIW OSC doesn\u0027t use os-brick at the moment.","commit_id":"8554ea5c39f9226147673532181dfc600207d81e"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"81dc86c81a59b5d0e88df5a9f8ad44e96e65293b","unresolved":false,"context_lines":[{"line_number":344,"context_line":"Testing"},{"line_number":345,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":346,"context_line":""},{"line_number":347,"context_line":"Tempest tests would require access to encrypted images for testing. This means"},{"line_number":348,"context_line":"that Tempest either needs to be provided with an image file that is already"},{"line_number":349,"context_line":"encrypted and its corresponding key or needs to be able to encrypt images"},{"line_number":350,"context_line":"itself. This point is still open for discussion."},{"line_number":351,"context_line":""},{"line_number":352,"context_line":""},{"line_number":353,"context_line":"Documentation Impact"}],"source_content_type":"text/x-rst","patch_set":8,"id":"9fb8cfa7_cd324bf3","line":350,"range":{"start_line":347,"start_character":68,"end_line":350,"end_character":48},"updated":"2019-07-03 13:08:49.000000000","message":"Ib346d383c430d5151d9aafa6e856dd0a7cae8a23 introduced a separate configurable to pass a signed image so I would assume we would want to go that way. That approach delegates the creation of the image to devstack or whatever is deploying/orchestrating the env.","commit_id":"8554ea5c39f9226147673532181dfc600207d81e"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"0166baf57f1b283fa9ffbb3a81bc00fabf2cfb4e","unresolved":false,"context_lines":[{"line_number":96,"context_line":"to the snapshot use cases 2.1 and 2.2 illustrated above. For this we intercept"},{"line_number":97,"context_line":"the image creation when an ‘image_key_id’ is present in the server’s metadata"},{"line_number":98,"context_line":"and encrypt the image. The necessary information about format, type and cipher"},{"line_number":99,"context_line":"should be declared in the Nova config in a new section for the image"},{"line_number":100,"context_line":"encryption. Nova will execute the encryption of the data prior to the upload"},{"line_number":101,"context_line":"to Glance accordingly."},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"The first addition, the decryption, takes place when downloading an encrypted"}],"source_content_type":"text/x-rst","patch_set":10,"id":"7faddb67_d0280d98","line":100,"range":{"start_line":99,"start_character":19,"end_line":100,"end_character":10},"updated":"2019-07-15 22:14:23.000000000","message":"The config should be described here.\n\nYou\u0027ve referred below to \"image_encryption_format\", \"image_encryption_type\" and \"image_encryption_cipher\". IMO you should create a section for [image_encryption] and have the conf options be `format`, `encryption_type`, and `cipher` or similar. Include their data types and a brief description.","commit_id":"fa924165b096585a37326b67f4f00cce3cff0c61"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"0166baf57f1b283fa9ffbb3a81bc00fabf2cfb4e","unresolved":false,"context_lines":[{"line_number":114,"context_line":"resize or snapshot creation. It happens in a similar fashion as the"},{"line_number":115,"context_line":"decryption. At the point the image file is created, Nova selects a suitable"},{"line_number":116,"context_line":"encryption method from os_brick and uses it to encrypt the image. The metadata"},{"line_number":117,"context_line":"for the image is created at this moment on the base of defaults and the key"},{"line_number":118,"context_line":"used for the encryption comes from the new metadata property ‘image_key_id’"},{"line_number":119,"context_line":"shich references a key in the keymanager."},{"line_number":120,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"7faddb67_90c4d5f6","line":117,"range":{"start_line":117,"start_character":40,"end_line":117,"end_character":54},"updated":"2019-07-15 22:14:23.000000000","message":"based on","commit_id":"fa924165b096585a37326b67f4f00cce3cff0c61"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"0166baf57f1b283fa9ffbb3a81bc00fabf2cfb4e","unresolved":false,"context_lines":[{"line_number":114,"context_line":"resize or snapshot creation. It happens in a similar fashion as the"},{"line_number":115,"context_line":"decryption. At the point the image file is created, Nova selects a suitable"},{"line_number":116,"context_line":"encryption method from os_brick and uses it to encrypt the image. The metadata"},{"line_number":117,"context_line":"for the image is created at this moment on the base of defaults and the key"},{"line_number":118,"context_line":"used for the encryption comes from the new metadata property ‘image_key_id’"},{"line_number":119,"context_line":"shich references a key in the keymanager."},{"line_number":120,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"7faddb67_d0a56d48","line":117,"range":{"start_line":117,"start_character":55,"end_line":117,"end_character":63},"updated":"2019-07-15 22:14:23.000000000","message":"conf options?","commit_id":"fa924165b096585a37326b67f4f00cce3cff0c61"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"0166baf57f1b283fa9ffbb3a81bc00fabf2cfb4e","unresolved":false,"context_lines":[{"line_number":116,"context_line":"encryption method from os_brick and uses it to encrypt the image. The metadata"},{"line_number":117,"context_line":"for the image is created at this moment on the base of defaults and the key"},{"line_number":118,"context_line":"used for the encryption comes from the new metadata property ‘image_key_id’"},{"line_number":119,"context_line":"shich references a key in the keymanager."},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"When handling encrypted images, Nova should respect the \"os_decrypt_size\""},{"line_number":122,"context_line":"property. Whenever an encrypted snapshot is created, this property should be"}],"source_content_type":"text/x-rst","patch_set":10,"id":"7faddb67_30b5e17e","line":119,"range":{"start_line":119,"start_character":0,"end_line":119,"end_character":5},"updated":"2019-07-15 22:14:23.000000000","message":"which","commit_id":"fa924165b096585a37326b67f4f00cce3cff0c61"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"0166baf57f1b283fa9ffbb3a81bc00fabf2cfb4e","unresolved":false,"context_lines":[{"line_number":160,"context_line":"uploaded and unregister as a consumer when the image is deleted in Glance."},{"line_number":161,"context_line":""},{"line_number":162,"context_line":"In Nova we will use this behavior in a mechanism called “keylock” hereafter."},{"line_number":163,"context_line":"Either a user adds a key_id to the servers metadata or it is inherited from"},{"line_number":164,"context_line":"the original source image, in case the image used to create the server was"},{"line_number":165,"context_line":"encrypted and the key_id was added to the servers metadata. In both cases Nova"},{"line_number":166,"context_line":"adds itself and the server as a consumer of this secret in the key-manager."}],"source_content_type":"text/x-rst","patch_set":10,"id":"7faddb67_306ac1ec","line":163,"range":{"start_line":163,"start_character":35,"end_line":163,"end_character":42},"updated":"2019-07-15 22:14:23.000000000","message":"server\u0027s","commit_id":"fa924165b096585a37326b67f4f00cce3cff0c61"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"0166baf57f1b283fa9ffbb3a81bc00fabf2cfb4e","unresolved":false,"context_lines":[{"line_number":162,"context_line":"In Nova we will use this behavior in a mechanism called “keylock” hereafter."},{"line_number":163,"context_line":"Either a user adds a key_id to the servers metadata or it is inherited from"},{"line_number":164,"context_line":"the original source image, in case the image used to create the server was"},{"line_number":165,"context_line":"encrypted and the key_id was added to the servers metadata. In both cases Nova"},{"line_number":166,"context_line":"adds itself and the server as a consumer of this secret in the key-manager."},{"line_number":167,"context_line":"This key will be used for creating the new snapshots, for which Glance"},{"line_number":168,"context_line":"registers as a consumer. So the user can keep track on whether the key is"}],"source_content_type":"text/x-rst","patch_set":10,"id":"7faddb67_f07749d3","line":165,"range":{"start_line":165,"start_character":42,"end_line":165,"end_character":49},"updated":"2019-07-15 22:14:23.000000000","message":"server\u0027s","commit_id":"fa924165b096585a37326b67f4f00cce3cff0c61"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"0166baf57f1b283fa9ffbb3a81bc00fabf2cfb4e","unresolved":false,"context_lines":[{"line_number":206,"context_line":"A new metadata property \"image_key_id\" is added. It bears the (Barbican) id of"},{"line_number":207,"context_line":"the secret which was used to encrypt the original image and is used to encrypt"},{"line_number":208,"context_line":"future snapshots. It can be changed through the normal update of this"},{"line_number":209,"context_line":"key-value pair."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":""},{"line_number":212,"context_line":"REST API impact"}],"source_content_type":"text/x-rst","patch_set":10,"id":"7faddb67_6b292a88","line":209,"updated":"2019-07-15 22:14:23.000000000","message":"Does this require a change in any RPC objects or database fields?","commit_id":"fa924165b096585a37326b67f4f00cce3cff0c61"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"e7cdbb41f206ad0731283c7d0bdfb17f495056fc","unresolved":false,"context_lines":[{"line_number":206,"context_line":"A new metadata property \"image_key_id\" is added. It bears the (Barbican) id of"},{"line_number":207,"context_line":"the secret which was used to encrypt the original image and is used to encrypt"},{"line_number":208,"context_line":"future snapshots. It can be changed through the normal update of this"},{"line_number":209,"context_line":"key-value pair."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":""},{"line_number":212,"context_line":"REST API impact"}],"source_content_type":"text/x-rst","patch_set":10,"id":"7faddb67_2a5e5e45","line":209,"in_reply_to":"7faddb67_6b292a88","updated":"2019-07-23 13:19:53.000000000","message":"Discussed in yesterday\u0027s meeting [1]. TLDR: no.\n\nhttp://eavesdrop.openstack.org/meetings/image_encryption/2019/image_encryption.2019-07-22-13.00.log.html#l-44","commit_id":"fa924165b096585a37326b67f4f00cce3cff0c61"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"0166baf57f1b283fa9ffbb3a81bc00fabf2cfb4e","unresolved":false,"context_lines":[{"line_number":225,"context_line":"* image encryption is introduced, thus additional cryptographic algorithms"},{"line_number":226,"context_line":"  will be used in Nova to implement this functionality"},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"* defaults for \"image_encryption_format\", \"image_encryption_type\" and"},{"line_number":229,"context_line":"  \"image_encryption_cipher\" should be noted in the nova config"},{"line_number":230,"context_line":""},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"Notifications impact"}],"source_content_type":"text/x-rst","patch_set":10,"id":"7faddb67_9037f5ff","line":229,"range":{"start_line":228,"start_character":2,"end_line":229,"end_character":62},"updated":"2019-07-15 22:14:23.000000000","message":"This is the first mention of these config options. IMO they should be described earlier (see above). And they should be described in more detail (also see above).","commit_id":"fa924165b096585a37326b67f4f00cce3cff0c61"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"0166baf57f1b283fa9ffbb3a81bc00fabf2cfb4e","unresolved":false,"context_lines":[{"line_number":244,"context_line":"* If an administrator has configured Glance to reject unencrypted images, such"},{"line_number":245,"context_line":"  images will not be accepted when attempted to be uploaded to Glance."},{"line_number":246,"context_line":""},{"line_number":247,"context_line":"* The image encryption key attribute on a server can be set and rotate. This"},{"line_number":248,"context_line":"  will force Nova to encrypt snapshots."},{"line_number":249,"context_line":""},{"line_number":250,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"7faddb67_902055ae","line":247,"range":{"start_line":247,"start_character":56,"end_line":247,"end_character":70},"updated":"2019-07-15 22:14:23.000000000","message":"what does this mean?","commit_id":"fa924165b096585a37326b67f4f00cce3cff0c61"},{"author":{"_account_id":28271,"name":"Josephine Seifert","email":"josephine.seifert@cloudandheat.com","username":"josei"},"change_message_id":"7523a9b7d1e7c13e35f52ce130c4ccb5fe7f2403","unresolved":false,"context_lines":[{"line_number":244,"context_line":"* If an administrator has configured Glance to reject unencrypted images, such"},{"line_number":245,"context_line":"  images will not be accepted when attempted to be uploaded to Glance."},{"line_number":246,"context_line":""},{"line_number":247,"context_line":"* The image encryption key attribute on a server can be set and rotate. This"},{"line_number":248,"context_line":"  will force Nova to encrypt snapshots."},{"line_number":249,"context_line":""},{"line_number":250,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"7faddb67_4dae6a99","line":247,"range":{"start_line":247,"start_character":56,"end_line":247,"end_character":70},"in_reply_to":"7faddb67_902055ae","updated":"2019-07-22 11:51:16.000000000","message":"The attribute image ancryption key will contain a key id (id in Barbican) which is then used to encrypt any image created from the server (temporary images and snapshots). When creating such images, the key id is also written to its metadata in glance. In conclusion, we have a key id for a key which was not yet used to encrypt an image - so we can easily change it, if needed. Allowing this would also give users the opportunity to set an image encryption key for other servers (created from unencrypted images). Images from these servers would then also be encrypted. \nAnd if a user wants to use another key at some point, it would be possible to simply change the key id (allowing key rotation).","commit_id":"fa924165b096585a37326b67f4f00cce3cff0c61"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"0166baf57f1b283fa9ffbb3a81bc00fabf2cfb4e","unresolved":false,"context_lines":[{"line_number":272,"context_line":"* The key manager needs to be accessible from compute, requiring appropriate"},{"line_number":273,"context_line":"  nova.conf adjustments."},{"line_number":274,"context_line":""},{"line_number":275,"context_line":"* default values for \"image_encryption_format\", \"image_encryption_type\" and"},{"line_number":276,"context_line":"  \"image_encryption_cipher\" should be added to the nova config file"},{"line_number":277,"context_line":""},{"line_number":278,"context_line":""},{"line_number":279,"context_line":"Developer impact"}],"source_content_type":"text/x-rst","patch_set":10,"id":"7faddb67_6b004a02","line":276,"range":{"start_line":275,"start_character":0,"end_line":276,"end_character":67},"updated":"2019-07-15 22:14:23.000000000","message":"if the conf options are set up with appropriate defaults, no action is necessary, right?","commit_id":"fa924165b096585a37326b67f4f00cce3cff0c61"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"0166baf57f1b283fa9ffbb3a81bc00fabf2cfb4e","unresolved":false,"context_lines":[{"line_number":315,"context_line":""},{"line_number":316,"context_line":"    * Retrieve encryption key from Barbican using the id"},{"line_number":317,"context_line":""},{"line_number":318,"context_line":"    * Use the encryption library functions to decrypt the locally cached image"},{"line_number":319,"context_line":"      into the target ephemeral disk, use privsep if root privileges are"},{"line_number":320,"context_line":"      required for writing"},{"line_number":321,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"7faddb67_cb2ffe85","line":318,"range":{"start_line":318,"start_character":58,"end_line":318,"end_character":78},"updated":"2019-07-15 22:14:23.000000000","message":"oh, I thought we could do this streaming-ly.","commit_id":"fa924165b096585a37326b67f4f00cce3cff0c61"},{"author":{"_account_id":28271,"name":"Josephine Seifert","email":"josephine.seifert@cloudandheat.com","username":"josei"},"change_message_id":"7523a9b7d1e7c13e35f52ce130c4ccb5fe7f2403","unresolved":false,"context_lines":[{"line_number":315,"context_line":""},{"line_number":316,"context_line":"    * Retrieve encryption key from Barbican using the id"},{"line_number":317,"context_line":""},{"line_number":318,"context_line":"    * Use the encryption library functions to decrypt the locally cached image"},{"line_number":319,"context_line":"      into the target ephemeral disk, use privsep if root privileges are"},{"line_number":320,"context_line":"      required for writing"},{"line_number":321,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"7faddb67_08b500ee","line":318,"range":{"start_line":318,"start_character":58,"end_line":318,"end_character":78},"in_reply_to":"7faddb67_cb2ffe85","updated":"2019-07-22 11:51:16.000000000","message":"The decryption does happen streaming-ly.\nThe current state is, that nova caches a glance image (also to check the signature) and copies it into the ephemeral storage disk.\nWith our image encryption, the cached image is still encrypted. We decrypt it at the point it is streamed into the ephemeral storage disk.\nWithout streaming-ly decryption, we would have to create a second temporary unencrypted image file. That is what we avoid.","commit_id":"fa924165b096585a37326b67f4f00cce3cff0c61"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"0166baf57f1b283fa9ffbb3a81bc00fabf2cfb4e","unresolved":false,"context_lines":[{"line_number":326,"context_line":"    * Retrieve encryption key from Barbican using the \"image_key_id\""},{"line_number":327,"context_line":""},{"line_number":328,"context_line":"    * Instead of just copying the data from the ephemeral storage disk into"},{"line_number":329,"context_line":"      the target image file, encrypt it using the encryption library functions"},{"line_number":330,"context_line":"      and the key as retrieved from Barbican"},{"line_number":331,"context_line":""},{"line_number":332,"context_line":"    * Upload the image to Glance as usual, including the encryption-related"},{"line_number":333,"context_line":"      metadata properties"},{"line_number":334,"context_line":""},{"line_number":335,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"7faddb67_4b59ce32","line":332,"range":{"start_line":329,"start_character":29,"end_line":332,"end_character":22},"updated":"2019-07-15 22:14:23.000000000","message":"ditto","commit_id":"fa924165b096585a37326b67f4f00cce3cff0c61"},{"author":{"_account_id":28271,"name":"Josephine Seifert","email":"josephine.seifert@cloudandheat.com","username":"josei"},"change_message_id":"7523a9b7d1e7c13e35f52ce130c4ccb5fe7f2403","unresolved":false,"context_lines":[{"line_number":326,"context_line":"    * Retrieve encryption key from Barbican using the \"image_key_id\""},{"line_number":327,"context_line":""},{"line_number":328,"context_line":"    * Instead of just copying the data from the ephemeral storage disk into"},{"line_number":329,"context_line":"      the target image file, encrypt it using the encryption library functions"},{"line_number":330,"context_line":"      and the key as retrieved from Barbican"},{"line_number":331,"context_line":""},{"line_number":332,"context_line":"    * Upload the image to Glance as usual, including the encryption-related"},{"line_number":333,"context_line":"      metadata properties"},{"line_number":334,"context_line":""},{"line_number":335,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"7faddb67_88f25099","line":332,"range":{"start_line":329,"start_character":29,"end_line":332,"end_character":22},"in_reply_to":"7faddb67_4b59ce32","updated":"2019-07-22 11:51:16.000000000","message":"It\u0027s the same way like for the decryption.\nThe current state is, that nova creates a temporary file and copies the ephemeral storage image into this file. After that a signature could be generated.\nWith our image encryption, we would encrypt the data while streaming into this temporary file. Thus having an encrypted temporary file, which then could also be signed.\nAgain without streaming-ly encryption we would have to create a second unencrypted temporary file for the image data. Which is what we avoid.","commit_id":"fa924165b096585a37326b67f4f00cce3cff0c61"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"e7cdbb41f206ad0731283c7d0bdfb17f495056fc","unresolved":false,"context_lines":[{"line_number":103,"context_line":"    [image_encryption]"},{"line_number":104,"context_line":"    encryption_format \u003d GPG"},{"line_number":105,"context_line":"    encryption_type \u003d symmetric"},{"line_number":106,"context_line":"    encryption_cipher \u003d AES256"},{"line_number":107,"context_line":"    ..."},{"line_number":108,"context_line":""},{"line_number":109,"context_line":"These also resemble the default values for the image encryption. Nova will"}],"source_content_type":"text/x-rst","patch_set":11,"id":"7faddb67_2a75fecc","line":106,"updated":"2019-07-23 13:19:53.000000000","message":"I guess all of these will be enums? Or maybe we need to make them strings so we don\u0027t have to keep them up to date as the thing that\u0027s actually using them changes?\n\nAnyway, we can sort that out at implementation time.","commit_id":"88518116850638483468f2a9de86f4f2f22013d2"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"36d64efbbd9ad800b8cd781da0eca86380b3ca7d","unresolved":false,"context_lines":[{"line_number":103,"context_line":"    [image_encryption]"},{"line_number":104,"context_line":"    encryption_format \u003d GPG"},{"line_number":105,"context_line":"    encryption_type \u003d symmetric"},{"line_number":106,"context_line":"    encryption_cipher \u003d AES256"},{"line_number":107,"context_line":"    ..."},{"line_number":108,"context_line":""},{"line_number":109,"context_line":"These also resemble the default values for the image encryption. Nova will"}],"source_content_type":"text/x-rst","patch_set":11,"id":"7faddb67_6a5e9346","line":106,"in_reply_to":"7faddb67_2a75fecc","updated":"2019-07-23 16:03:15.000000000","message":"i would stick with enums untill we need to extend them.\nbut yes that can be adressed as an implementation detail.","commit_id":"88518116850638483468f2a9de86f4f2f22013d2"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"268bf194c31df67dc47939ef46bc89528e3beb1a","unresolved":false,"context_lines":[{"line_number":110,"context_line":"then execute the encryption of the data prior to the upload to Glance"},{"line_number":111,"context_line":"accordingly."},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"The first addition, the decryption, takes place when downloading an encrypted"},{"line_number":114,"context_line":"image from Glance. With the information of the image metadata the"},{"line_number":115,"context_line":"corresponding decryption method in os_brick is called when transferring the"},{"line_number":116,"context_line":"image data into the ephemeral storage disk. After that the server may be"},{"line_number":117,"context_line":"handled in the usual way. As the image data has then been decrypted (and is at"}],"source_content_type":"text/x-rst","patch_set":11,"id":"7faddb67_b8e428e1","line":114,"range":{"start_line":113,"start_character":0,"end_line":114,"end_character":17},"updated":"2019-08-05 17:32:57.000000000","message":"Doesn\u0027t this defeat the stated goal of leaving the image encrypted in caches? With this approach, the only place it\u0027s stored encrypted is on the glance servers. The compute hosts are arguably the least secure nodes in the system, but they have the image stored unencrypted at rest?\n\nI would think that in order to make this actually work the way a user expects, the decryption step needs to be on the flatten operation, and that encrypted images are always flattened out of the cache during boot or something. That\u0027s a bit larger of a step than what is described here, which is just to transparently decrypt during download, AFAICT.\n\nIf you\u0027re not talking about decryption during download (as you state here), then this should be changed to reflect what actually happens (in libvirt at least, not sure about the others) where the base image is downloaded in its entirety, and then copied, flattened, or CoW\u0027d to create the instance\u0027s disk.","commit_id":"88518116850638483468f2a9de86f4f2f22013d2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"602a66b2dce324ea4b3808d23ca937ca78b6cc8b","unresolved":false,"context_lines":[{"line_number":111,"context_line":"accordingly."},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"The first addition, the decryption, takes place when downloading an encrypted"},{"line_number":114,"context_line":"image from Glance. With the information of the image metadata the"},{"line_number":115,"context_line":"corresponding decryption method in os_brick is called when transferring the"},{"line_number":116,"context_line":"image data into the ephemeral storage disk. After that the server may be"},{"line_number":117,"context_line":"handled in the usual way. As the image data has then been decrypted (and is at"},{"line_number":118,"context_line":"best located in an encrypted ephemeral storage) the encryption-related"},{"line_number":119,"context_line":"additional metadata properties except for the key_id become irrelevant and"}],"source_content_type":"text/x-rst","patch_set":11,"id":"7faddb67_b421fea1","line":116,"range":{"start_line":114,"start_character":19,"end_line":116,"end_character":43},"updated":"2019-07-29 15:24:24.000000000","message":"Does this happen generically in the ComputeManager or in the virt driver code? Because if the latter, we would want a compute capability flag/trait per driver so we that we can filter hosts properly during scheduling so we don\u0027t send these types of images to computes with hypervisor drivers that don\u0027t support them.","commit_id":"88518116850638483468f2a9de86f4f2f22013d2"},{"author":{"_account_id":9555,"name":"Matthew Booth","email":"mbooth@redhat.com","username":"MatthewBooth"},"change_message_id":"d8a4578aa5fb527fca9b6a300aabe7ae1225ff4a","unresolved":false,"context_lines":[{"line_number":111,"context_line":"accordingly."},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"The first addition, the decryption, takes place when downloading an encrypted"},{"line_number":114,"context_line":"image from Glance. With the information of the image metadata the"},{"line_number":115,"context_line":"corresponding decryption method in os_brick is called when transferring the"},{"line_number":116,"context_line":"image data into the ephemeral storage disk. After that the server may be"},{"line_number":117,"context_line":"handled in the usual way. As the image data has then been decrypted (and is at"},{"line_number":118,"context_line":"best located in an encrypted ephemeral storage) the encryption-related"},{"line_number":119,"context_line":"additional metadata properties except for the key_id become irrelevant and"}],"source_content_type":"text/x-rst","patch_set":11,"id":"3fa7e38b_e71ddfbe","line":116,"range":{"start_line":114,"start_character":19,"end_line":116,"end_character":43},"in_reply_to":"7faddb67_3ef7e48d","updated":"2019-11-07 14:34:09.000000000","message":"It\u0027s worth noting here that encrypted LVM offers no additional protection over unencrypted LVM in practise: we give the key to dm-crypt, then present the unencrypted device as a device-mapper block device on the compute host. Any attack which compromises the encrypted data also has access to the unencrypted data, so this is literally useless.\n\nIf ephemeral storage is a related goal, I strongly suggest throwing the existing work in LVM away and starting again. Something based on QEMU native encryption would be a much better bet.","commit_id":"88518116850638483468f2a9de86f4f2f22013d2"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"0be7b2535eef73ac8ef6db5830398a5fec2e37ca","unresolved":false,"context_lines":[{"line_number":111,"context_line":"accordingly."},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"The first addition, the decryption, takes place when downloading an encrypted"},{"line_number":114,"context_line":"image from Glance. With the information of the image metadata the"},{"line_number":115,"context_line":"corresponding decryption method in os_brick is called when transferring the"},{"line_number":116,"context_line":"image data into the ephemeral storage disk. After that the server may be"},{"line_number":117,"context_line":"handled in the usual way. As the image data has then been decrypted (and is at"},{"line_number":118,"context_line":"best located in an encrypted ephemeral storage) the encryption-related"},{"line_number":119,"context_line":"additional metadata properties except for the key_id become irrelevant and"}],"source_content_type":"text/x-rst","patch_set":11,"id":"7faddb67_e6f8efc4","line":116,"range":{"start_line":114,"start_character":19,"end_line":116,"end_character":43},"in_reply_to":"7faddb67_576097a5","updated":"2019-08-01 14:14:58.000000000","message":"@Luzi, the traits in that file are for filtering support by disk_format. IIUC you\u0027re using container_format to indicate \u0027encrypted\u0027 - when unencrypted, the disk would still be in one of those existing TYPE_* formats. Do I have that right?\n\nIf so, you\u0027ll want to introduce a trait in a different \"namespace\" to avoid confusion - e.g. COMPUTE_IMAGE_CONTAINER_ENCRYPTED - and add new request filter logic that converts container_format\u003d\u0027encrypted\u0027 to trait:COMPUTE_IMAGE_CONTAINER_ENCRYPTED\u003drequired. I\u0027m not sure how hard it would be to encompass filtering for *all* container types, but at the very least you could just special-case \u0027encrypted\u0027 and ignore the rest.\n\nIt\u0027s probably appropriate to fold that logic into the existing require_image_type_support filter [1], which is the one that deals with the COMPUTE_IMAGE_TYPE_* traits you pointed out. As luck would have it, that filter and its conf switch were named \"*_image_type_*\", which is generic enough to encompass both disk_format and container_format :) (It would have been nice if the traits were named COMPUTE_IMAGE_DISK_FORMAT_*, but alas...)\n\nMy only concern with reusing the same filter is that IMO we should *always* be imposing this new logic, not forcing the operator to switch on that scheduler filter to be not-broken. But (again IMO) the same argument applies to the existing logic there, so meh.\n\n[1] https://opendev.org/openstack/nova/src/commit/877a78a63b13dc6599aed7c152b26b25501a52e8/nova/scheduler/request_filter.py#L124","commit_id":"88518116850638483468f2a9de86f4f2f22013d2"},{"author":{"_account_id":28271,"name":"Josephine Seifert","email":"josephine.seifert@cloudandheat.com","username":"josei"},"change_message_id":"7c49b516612726f7c32cc06ff888a35120aadd7e","unresolved":false,"context_lines":[{"line_number":111,"context_line":"accordingly."},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"The first addition, the decryption, takes place when downloading an encrypted"},{"line_number":114,"context_line":"image from Glance. With the information of the image metadata the"},{"line_number":115,"context_line":"corresponding decryption method in os_brick is called when transferring the"},{"line_number":116,"context_line":"image data into the ephemeral storage disk. After that the server may be"},{"line_number":117,"context_line":"handled in the usual way. As the image data has then been decrypted (and is at"},{"line_number":118,"context_line":"best located in an encrypted ephemeral storage) the encryption-related"},{"line_number":119,"context_line":"additional metadata properties except for the key_id become irrelevant and"}],"source_content_type":"text/x-rst","patch_set":11,"id":"7faddb67_576097a5","line":116,"range":{"start_line":114,"start_character":19,"end_line":116,"end_character":43},"in_reply_to":"7faddb67_b421fea1","updated":"2019-08-01 08:54:31.000000000","message":"It happens in the virt driver code.\nAre you suggesting to add a capability trait like „TYPE_ENCRYPTED“ ? https://github.com/openstack/os-traits/blob/0c908e86080882c78ea50ccc9f54ef3d4f61a038/os_traits/compute/image.py\nThat does sound reasonable – especially in combination with your last comment.","commit_id":"88518116850638483468f2a9de86f4f2f22013d2"},{"author":{"_account_id":28271,"name":"Josephine Seifert","email":"josephine.seifert@cloudandheat.com","username":"josei"},"change_message_id":"a4023bbd4d12baa9ff2a73b5013dfd5cbbc6c035","unresolved":false,"context_lines":[{"line_number":111,"context_line":"accordingly."},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"The first addition, the decryption, takes place when downloading an encrypted"},{"line_number":114,"context_line":"image from Glance. With the information of the image metadata the"},{"line_number":115,"context_line":"corresponding decryption method in os_brick is called when transferring the"},{"line_number":116,"context_line":"image data into the ephemeral storage disk. After that the server may be"},{"line_number":117,"context_line":"handled in the usual way. As the image data has then been decrypted (and is at"},{"line_number":118,"context_line":"best located in an encrypted ephemeral storage) the encryption-related"},{"line_number":119,"context_line":"additional metadata properties except for the key_id become irrelevant and"}],"source_content_type":"text/x-rst","patch_set":11,"id":"7faddb67_3ef7e48d","line":116,"range":{"start_line":114,"start_character":19,"end_line":116,"end_character":43},"in_reply_to":"7faddb67_bdb8c1c7","updated":"2019-08-02 09:16:34.000000000","message":"The scope of this spec is just the encryption and decryption of images.\nThe encryption of ephemeral storage is a separate concern. Currently it is possible for LVM to have encrypted ephemeral storage. \nIt would be a very good thing to also have that in Ceph, where even native LUKS-encryption would be possible. \nActually this is the point, why we wanted to have a streamable decryption. In case the ephemeral storage is or will be encrypted - the image data is streamed into the encrypted ephemeral storage and thus never exposed as a whole file.\nBut as for example in Ceph: that might be a follow up task.","commit_id":"88518116850638483468f2a9de86f4f2f22013d2"},{"author":{"_account_id":1004,"name":"Mohammed Naser","email":"mnaser@vexxhost.com","username":"mnaser"},"change_message_id":"3e91f464e264ee534a654205af21b483ee9a28f5","unresolved":false,"context_lines":[{"line_number":111,"context_line":"accordingly."},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"The first addition, the decryption, takes place when downloading an encrypted"},{"line_number":114,"context_line":"image from Glance. With the information of the image metadata the"},{"line_number":115,"context_line":"corresponding decryption method in os_brick is called when transferring the"},{"line_number":116,"context_line":"image data into the ephemeral storage disk. After that the server may be"},{"line_number":117,"context_line":"handled in the usual way. As the image data has then been decrypted (and is at"},{"line_number":118,"context_line":"best located in an encrypted ephemeral storage) the encryption-related"},{"line_number":119,"context_line":"additional metadata properties except for the key_id become irrelevant and"}],"source_content_type":"text/x-rst","patch_set":11,"id":"7faddb67_bdb8c1c7","line":116,"range":{"start_line":114,"start_character":19,"end_line":116,"end_character":43},"in_reply_to":"7faddb67_e6f8efc4","updated":"2019-08-01 21:54:38.000000000","message":"If I understand correctly, the data will be decrypted then stored unencrypted on the ephemeral storage disk.\n\nAs a user, I would like to for example always be under the impression that my data is encrypted, so uploading encrypted data to Glance only for it to live decrypted on the compute host seems like it\u0027s not necessarily providing the best security?\n\nAlso, in some cases, with Ceph, it means that data is stored decrypted for all hosts to be able to access..  But maybe I am not parsing this correctly :)","commit_id":"88518116850638483468f2a9de86f4f2f22013d2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"602a66b2dce324ea4b3808d23ca937ca78b6cc8b","unresolved":false,"context_lines":[{"line_number":117,"context_line":"handled in the usual way. As the image data has then been decrypted (and is at"},{"line_number":118,"context_line":"best located in an encrypted ephemeral storage) the encryption-related"},{"line_number":119,"context_line":"additional metadata properties except for the key_id become irrelevant and"},{"line_number":120,"context_line":"thus may be discarded instead of being carried over into the server\u0027s metadata."},{"line_number":121,"context_line":""},{"line_number":122,"context_line":"The second addition, the encryption, takes place when an image is created from"},{"line_number":123,"context_line":"a server with ephemeral storage. This is the case for shelve, cross-cell"}],"source_content_type":"text/x-rst","patch_set":11,"id":"7faddb67_943ba2c6","line":120,"range":{"start_line":120,"start_character":70,"end_line":120,"end_character":78},"updated":"2019-07-29 15:24:24.000000000","message":"Technically I think you\u0027re talking about system_metadata here which is where the image properties associated with the server are stored, and is not visible to the owner of the server, only the metadata is user-facing.","commit_id":"88518116850638483468f2a9de86f4f2f22013d2"},{"author":{"_account_id":1004,"name":"Mohammed Naser","email":"mnaser@vexxhost.com","username":"mnaser"},"change_message_id":"3e91f464e264ee534a654205af21b483ee9a28f5","unresolved":false,"context_lines":[{"line_number":152,"context_line":"2. We propose direct decryption-streaming into the target storage disk to"},{"line_number":153,"context_line":"   prevent the creation of temporary unencrypted files."},{"line_number":154,"context_line":""},{"line_number":155,"context_line":"The decryption of the image should be done right when it is streamed into the"},{"line_number":156,"context_line":"ephemeral storage, i.e. a direct conversion of the encrypted image into"},{"line_number":157,"context_line":"encrypted ephemeral disk prior to server start, avoiding the creation of"},{"line_number":158,"context_line":"temporary unencrypted files."},{"line_number":159,"context_line":""},{"line_number":160,"context_line":"The key management is handled differently than with encrypted volumes or"},{"line_number":161,"context_line":"encrypted ephemeral storage. The reason for this is, that the encryption and"}],"source_content_type":"text/x-rst","patch_set":11,"id":"7faddb67_3dd131fc","line":158,"range":{"start_line":155,"start_character":0,"end_line":158,"end_character":28},"updated":"2019-08-01 21:54:38.000000000","message":"This will be tricky if using something like Ceph .. how would something like images which are uploaded with copy-on-write enabled?  Will it do a full manual copy and decrypt it in place?","commit_id":"88518116850638483468f2a9de86f4f2f22013d2"},{"author":{"_account_id":9555,"name":"Matthew Booth","email":"mbooth@redhat.com","username":"MatthewBooth"},"change_message_id":"d8a4578aa5fb527fca9b6a300aabe7ae1225ff4a","unresolved":false,"context_lines":[{"line_number":152,"context_line":"2. We propose direct decryption-streaming into the target storage disk to"},{"line_number":153,"context_line":"   prevent the creation of temporary unencrypted files."},{"line_number":154,"context_line":""},{"line_number":155,"context_line":"The decryption of the image should be done right when it is streamed into the"},{"line_number":156,"context_line":"ephemeral storage, i.e. a direct conversion of the encrypted image into"},{"line_number":157,"context_line":"encrypted ephemeral disk prior to server start, avoiding the creation of"},{"line_number":158,"context_line":"temporary unencrypted files."},{"line_number":159,"context_line":""},{"line_number":160,"context_line":"The key management is handled differently than with encrypted volumes or"},{"line_number":161,"context_line":"encrypted ephemeral storage. The reason for this is, that the encryption and"}],"source_content_type":"text/x-rst","patch_set":11,"id":"3fa7e38b_626c7dd0","line":158,"range":{"start_line":155,"start_character":0,"end_line":158,"end_character":28},"in_reply_to":"7faddb67_18f53c57","updated":"2019-11-07 14:34:09.000000000","message":"After speaking to Dan B, seems that although QEMU supports an encrypted backing file there\u0027s no libvirt support for it, yet, so we can\u0027t do that either. It\u0027s coming RSN though, apparently. The feature is -blockdev.","commit_id":"88518116850638483468f2a9de86f4f2f22013d2"},{"author":{"_account_id":28271,"name":"Josephine Seifert","email":"josephine.seifert@cloudandheat.com","username":"josei"},"change_message_id":"a4023bbd4d12baa9ff2a73b5013dfd5cbbc6c035","unresolved":false,"context_lines":[{"line_number":152,"context_line":"2. We propose direct decryption-streaming into the target storage disk to"},{"line_number":153,"context_line":"   prevent the creation of temporary unencrypted files."},{"line_number":154,"context_line":""},{"line_number":155,"context_line":"The decryption of the image should be done right when it is streamed into the"},{"line_number":156,"context_line":"ephemeral storage, i.e. a direct conversion of the encrypted image into"},{"line_number":157,"context_line":"encrypted ephemeral disk prior to server start, avoiding the creation of"},{"line_number":158,"context_line":"temporary unencrypted files."},{"line_number":159,"context_line":""},{"line_number":160,"context_line":"The key management is handled differently than with encrypted volumes or"},{"line_number":161,"context_line":"encrypted ephemeral storage. The reason for this is, that the encryption and"}],"source_content_type":"text/x-rst","patch_set":11,"id":"7faddb67_79b336ea","line":158,"range":{"start_line":155,"start_character":0,"end_line":158,"end_character":28},"in_reply_to":"7faddb67_3dd131fc","updated":"2019-08-02 09:16:34.000000000","message":"In the case of using GPG-encrypted Images a full copy would be needed.\nIf there would be something like native LUKS-encrypted ephemeral storage in Ceph. We could think about adding another \"driver\" or encryption mechanism - namely LUKS - for the Image encryption. Because in that case copy-on-write would be possible with both image and ephemeral storage encrypted in the same way. \nBut that would be a very specific use case: just for Ceph. We want to provide a more general approach for all kind of use cases and combinations of Glance storage backends and hypervisors. Plus ephemeral storage encryption in Ceph is currently not implemented.","commit_id":"88518116850638483468f2a9de86f4f2f22013d2"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"268bf194c31df67dc47939ef46bc89528e3beb1a","unresolved":false,"context_lines":[{"line_number":152,"context_line":"2. We propose direct decryption-streaming into the target storage disk to"},{"line_number":153,"context_line":"   prevent the creation of temporary unencrypted files."},{"line_number":154,"context_line":""},{"line_number":155,"context_line":"The decryption of the image should be done right when it is streamed into the"},{"line_number":156,"context_line":"ephemeral storage, i.e. a direct conversion of the encrypted image into"},{"line_number":157,"context_line":"encrypted ephemeral disk prior to server start, avoiding the creation of"},{"line_number":158,"context_line":"temporary unencrypted files."},{"line_number":159,"context_line":""},{"line_number":160,"context_line":"The key management is handled differently than with encrypted volumes or"},{"line_number":161,"context_line":"encrypted ephemeral storage. The reason for this is, that the encryption and"}],"source_content_type":"text/x-rst","patch_set":11,"id":"7faddb67_18f53c57","line":158,"range":{"start_line":155,"start_character":0,"end_line":158,"end_character":28},"in_reply_to":"7faddb67_79b336ea","updated":"2019-08-05 17:32:57.000000000","message":"This is the case even for files on disk right? If the image is not a native disk encryption format (i.e. LUKS) you can\u0027t base your CoW image on the encrypted one.","commit_id":"88518116850638483468f2a9de86f4f2f22013d2"},{"author":{"_account_id":1004,"name":"Mohammed Naser","email":"mnaser@vexxhost.com","username":"mnaser"},"change_message_id":"3e91f464e264ee534a654205af21b483ee9a28f5","unresolved":false,"context_lines":[{"line_number":170,"context_line":"uploaded and unregister as a consumer when the image is deleted in Glance."},{"line_number":171,"context_line":""},{"line_number":172,"context_line":"In Nova we will use this behavior in a mechanism called “keylock” hereafter."},{"line_number":173,"context_line":"Either a user adds a key_id to the server\u0027s metadata or it is inherited from"},{"line_number":174,"context_line":"the original source image, in case the image used to create the server was"},{"line_number":175,"context_line":"encrypted and the key_id was added to the server\u0027s metadata. In both cases"},{"line_number":176,"context_line":"Nova adds itself and the server as a consumer of this secret in the key-"},{"line_number":177,"context_line":"manager. This key will be used for creating the new snapshots, for which"}],"source_content_type":"text/x-rst","patch_set":11,"id":"7faddb67_fdef19ae","line":174,"range":{"start_line":173,"start_character":56,"end_line":174,"end_character":25},"updated":"2019-08-01 21:54:38.000000000","message":"which means we probably need to store that in metadata?","commit_id":"88518116850638483468f2a9de86f4f2f22013d2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"602a66b2dce324ea4b3808d23ca937ca78b6cc8b","unresolved":false,"context_lines":[{"line_number":213,"context_line":"Data model impact"},{"line_number":214,"context_line":"-----------------"},{"line_number":215,"context_line":""},{"line_number":216,"context_line":"A new metadata property \"image_key_id\" is added. It bears the (Barbican) id of"},{"line_number":217,"context_line":"the secret which was used to encrypt the original image and is used to encrypt"},{"line_number":218,"context_line":"future snapshots. It can be changed through the normal update of this"},{"line_number":219,"context_line":"key-value pair."},{"line_number":220,"context_line":""},{"line_number":221,"context_line":""},{"line_number":222,"context_line":"REST API impact"}],"source_content_type":"text/x-rst","patch_set":11,"id":"7faddb67_344aee54","line":219,"range":{"start_line":216,"start_character":0,"end_line":219,"end_character":15},"updated":"2019-07-29 15:24:24.000000000","message":"This is for glance only, right? For this nova spec the answer to this section is None.","commit_id":"88518116850638483468f2a9de86f4f2f22013d2"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"268bf194c31df67dc47939ef46bc89528e3beb1a","unresolved":false,"context_lines":[{"line_number":213,"context_line":"Data model impact"},{"line_number":214,"context_line":"-----------------"},{"line_number":215,"context_line":""},{"line_number":216,"context_line":"A new metadata property \"image_key_id\" is added. It bears the (Barbican) id of"},{"line_number":217,"context_line":"the secret which was used to encrypt the original image and is used to encrypt"},{"line_number":218,"context_line":"future snapshots. It can be changed through the normal update of this"},{"line_number":219,"context_line":"key-value pair."},{"line_number":220,"context_line":""},{"line_number":221,"context_line":""},{"line_number":222,"context_line":"REST API impact"}],"source_content_type":"text/x-rst","patch_set":11,"id":"7faddb67_3846f8c1","line":219,"range":{"start_line":216,"start_character":0,"end_line":219,"end_character":15},"in_reply_to":"7faddb67_17569fcf","updated":"2019-08-05 17:32:57.000000000","message":"You mean nova will *set* that property on the image when it creates a snapshot, right? That\u0027s not a nova data model change, which is why this should be None.","commit_id":"88518116850638483468f2a9de86f4f2f22013d2"},{"author":{"_account_id":28271,"name":"Josephine Seifert","email":"josephine.seifert@cloudandheat.com","username":"josei"},"change_message_id":"7c49b516612726f7c32cc06ff888a35120aadd7e","unresolved":false,"context_lines":[{"line_number":213,"context_line":"Data model impact"},{"line_number":214,"context_line":"-----------------"},{"line_number":215,"context_line":""},{"line_number":216,"context_line":"A new metadata property \"image_key_id\" is added. It bears the (Barbican) id of"},{"line_number":217,"context_line":"the secret which was used to encrypt the original image and is used to encrypt"},{"line_number":218,"context_line":"future snapshots. It can be changed through the normal update of this"},{"line_number":219,"context_line":"key-value pair."},{"line_number":220,"context_line":""},{"line_number":221,"context_line":""},{"line_number":222,"context_line":"REST API impact"}],"source_content_type":"text/x-rst","patch_set":11,"id":"7faddb67_17569fcf","line":219,"range":{"start_line":216,"start_character":0,"end_line":219,"end_character":15},"in_reply_to":"7faddb67_344aee54","updated":"2019-08-01 08:54:31.000000000","message":"No, this is explicitly added to nova, because we want to use this key for encryption, whenever an image is created from a server. We explained it in\nthe key-lock paragraph.","commit_id":"88518116850638483468f2a9de86f4f2f22013d2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"602a66b2dce324ea4b3808d23ca937ca78b6cc8b","unresolved":false,"context_lines":[{"line_number":222,"context_line":"REST API impact"},{"line_number":223,"context_line":"---------------"},{"line_number":224,"context_line":""},{"line_number":225,"context_line":"None"},{"line_number":226,"context_line":""},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"Security impact"}],"source_content_type":"text/x-rst","patch_set":11,"id":"7faddb67_74ae26e8","line":225,"updated":"2019-07-29 15:24:24.000000000","message":"The createBackup server action also creates snapshots - will that be changed here? Or will that just not support encrypted snapshots?\n\nhttps://docs.openstack.org/api-ref/compute/#create-server-back-up-createbackup-action\n\nI think for the most part we\u0027ve been trying to essentially freeze changes to that API since it\u0027s purely an orchestration API that isn\u0027t really necessary to be part of compute since users can replicate the same thing externally.","commit_id":"88518116850638483468f2a9de86f4f2f22013d2"},{"author":{"_account_id":28271,"name":"Josephine Seifert","email":"josephine.seifert@cloudandheat.com","username":"josei"},"change_message_id":"7c49b516612726f7c32cc06ff888a35120aadd7e","unresolved":false,"context_lines":[{"line_number":222,"context_line":"REST API impact"},{"line_number":223,"context_line":"---------------"},{"line_number":224,"context_line":""},{"line_number":225,"context_line":"None"},{"line_number":226,"context_line":""},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"Security impact"}],"source_content_type":"text/x-rst","patch_set":11,"id":"7faddb67_5705f7c0","line":225,"in_reply_to":"7faddb67_74ae26e8","updated":"2019-08-01 08:54:31.000000000","message":"First: there won‘t be any changes to the API – we do all the decryption and encryption decisions in the backend based on present metadata objects.\nSecond: the createBackup API is essentially a wrapper around the same functionality which createImage uses under the hood (snapshot function). Since we propose to use the „image_key_id“ property for the snapshot step, the encryption should happen automatically regardless which of the APIs was used.","commit_id":"88518116850638483468f2a9de86f4f2f22013d2"},{"author":{"_account_id":1004,"name":"Mohammed Naser","email":"mnaser@vexxhost.com","username":"mnaser"},"change_message_id":"3e91f464e264ee534a654205af21b483ee9a28f5","unresolved":false,"context_lines":[{"line_number":248,"context_line":"Other end user impact"},{"line_number":249,"context_line":"---------------------"},{"line_number":250,"context_line":""},{"line_number":251,"context_line":"* Users should be able to optionally, but knowingly create an encrypted image"},{"line_number":252,"context_line":"  from a server based on ephemeral storage."},{"line_number":253,"context_line":""},{"line_number":254,"context_line":"* If an administrator has configured Glance to reject unencrypted images, such"},{"line_number":255,"context_line":"  images will not be accepted when attempted to be uploaded to Glance."}],"source_content_type":"text/x-rst","patch_set":11,"id":"7faddb67_fd44f9b9","line":252,"range":{"start_line":251,"start_character":0,"end_line":252,"end_character":43},"updated":"2019-08-01 21:54:38.000000000","message":"I think appropriate measures should be done to make sure the VMs land on a hypervisor that can store data encrypted (and figuring out some sort of solution for things like rbd)","commit_id":"88518116850638483468f2a9de86f4f2f22013d2"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"268bf194c31df67dc47939ef46bc89528e3beb1a","unresolved":false,"context_lines":[{"line_number":272,"context_line":"will vary depending on the individual host performance and supported CPU"},{"line_number":273,"context_line":"extensions for cipher algorithms. The increased load will occur on the host"},{"line_number":274,"context_line":"pCPU."},{"line_number":275,"context_line":""},{"line_number":276,"context_line":""},{"line_number":277,"context_line":"Other deployer impact"},{"line_number":278,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":11,"id":"7faddb67_581ad4c5","line":275,"updated":"2019-08-05 17:32:57.000000000","message":"If the images are stored encrypted and decrypted only when creating an instance\u0027s disk, then another performance impact is that instances from these images take up more disk than expected. It also means that users control whether or not a spawn takes a little bit of disk on the compute, or a lot. And, it definitely impacts the time to spawn, not only because of the decryption but also the IO involved in copying all the data.","commit_id":"88518116850638483468f2a9de86f4f2f22013d2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"602a66b2dce324ea4b3808d23ca937ca78b6cc8b","unresolved":false,"context_lines":[{"line_number":289,"context_line":"None"},{"line_number":290,"context_line":""},{"line_number":291,"context_line":""},{"line_number":292,"context_line":"Upgrade impact"},{"line_number":293,"context_line":"--------------"},{"line_number":294,"context_line":""},{"line_number":295,"context_line":"Setting the new metadata property “image_key_id” is also possible for already"}],"source_content_type":"text/x-rst","patch_set":11,"id":"7faddb67_c913c365","line":292,"updated":"2019-07-29 15:24:24.000000000","message":"Anything that involves changes to behavior on the nova-compute service will be impacted by this, e.g. a request to a snapshot a server and create an encrypted snapshot image out of it, if that happens on the compute and the compute is old (Stein in this case for rolling upgrade support), then you can\u0027t support the operation. Would the API check the compute service version and fail if it\u0027s not new enough and the API can know ahead of time that the compute is being asked to do an encrypted snapshot? Otherwise the API will happily accept the request and pass it to an old compute that won\u0027t honor it.\n\nSimilar issues for creating a server from an encrypted image - how are we going to handle those? There are a few options:\n\n1. Do things the old school openstack way and just don\u0027t care and let things fail in the compute, but that sucks.\n\n2. Don\u0027t allow creating servers from encrypted images until all computes in the deployment are upgraded. That\u0027s a bigger hammer but we\u0027ve done it for other things (I think trusted image certificate IDs is one example).\n\n3. Do something with scheduler filtering such that if we\u0027re asked to boot from an encrypted image, we only do it on computes that support it (so anything upgraded and with a virt driver that supports encrypted images - which I\u0027m guessing would be only the libvirt driver to start since we\u0027re talking about using os-brick?). This is the most flexible and also makes sense once we\u0027re past Train and all computes are expected to be upgraded, but not all virt drivers support this feature. In this case, the drivers could expose a compute capability trait to placement and we could have a pre-request scheduler filter [1] that translates a request to use an encrypted image to a required trait on the RequestSpec so the scheduler only asks placement for hosts that support encrypted images.\n\n[1] https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#prefiltering","commit_id":"88518116850638483468f2a9de86f4f2f22013d2"},{"author":{"_account_id":28271,"name":"Josephine Seifert","email":"josephine.seifert@cloudandheat.com","username":"josei"},"change_message_id":"7c49b516612726f7c32cc06ff888a35120aadd7e","unresolved":false,"context_lines":[{"line_number":289,"context_line":"None"},{"line_number":290,"context_line":""},{"line_number":291,"context_line":""},{"line_number":292,"context_line":"Upgrade impact"},{"line_number":293,"context_line":"--------------"},{"line_number":294,"context_line":""},{"line_number":295,"context_line":"Setting the new metadata property “image_key_id” is also possible for already"}],"source_content_type":"text/x-rst","patch_set":11,"id":"7faddb67_170bffd4","line":292,"in_reply_to":"7faddb67_c913c365","updated":"2019-08-01 08:54:31.000000000","message":"Thats a good argument. Of course number three would be the way to choose, as it would also cover the compute capability trait. I will add this to the spec.","commit_id":"88518116850638483468f2a9de86f4f2f22013d2"},{"author":{"_account_id":1004,"name":"Mohammed Naser","email":"mnaser@vexxhost.com","username":"mnaser"},"change_message_id":"3e91f464e264ee534a654205af21b483ee9a28f5","unresolved":false,"context_lines":[{"line_number":289,"context_line":"None"},{"line_number":290,"context_line":""},{"line_number":291,"context_line":""},{"line_number":292,"context_line":"Upgrade impact"},{"line_number":293,"context_line":"--------------"},{"line_number":294,"context_line":""},{"line_number":295,"context_line":"Setting the new metadata property “image_key_id” is also possible for already"}],"source_content_type":"text/x-rst","patch_set":11,"id":"7faddb67_3d2851e0","line":292,"in_reply_to":"7faddb67_c913c365","updated":"2019-08-01 21:54:38.000000000","message":"i like option #3","commit_id":"88518116850638483468f2a9de86f4f2f22013d2"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"268bf194c31df67dc47939ef46bc89528e3beb1a","unresolved":false,"context_lines":[{"line_number":313,"context_line":"----------"},{"line_number":314,"context_line":""},{"line_number":315,"context_line":"* Add a decryption implementation in Nova for creating servers (ephemeral"},{"line_number":316,"context_line":"  storage disks) from GPG encrypted images"},{"line_number":317,"context_line":""},{"line_number":318,"context_line":"    * Upon server creation, retrieve and cache encrypted image from Glance or"},{"line_number":319,"context_line":"      use from local cache if existing"}],"source_content_type":"text/x-rst","patch_set":11,"id":"7faddb67_98ae0c2c","line":316,"updated":"2019-08-05 17:32:57.000000000","message":"...to libvirt? All the drivers? The image handling code is not fully generic and virt-independent. I\u0027m assuming you want to implement this first for libvirt, but it needs to be done in a way that works for the other drivers. Can we get some input from the others about whether or not they can support decryption in the same way?","commit_id":"88518116850638483468f2a9de86f4f2f22013d2"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"268bf194c31df67dc47939ef46bc89528e3beb1a","unresolved":false,"context_lines":[{"line_number":324,"context_line":""},{"line_number":325,"context_line":"    * Use the encryption library functions to decrypt the locally cached image"},{"line_number":326,"context_line":"      into the target ephemeral disk, use privsep if root privileges are"},{"line_number":327,"context_line":"      required for writing"},{"line_number":328,"context_line":""},{"line_number":329,"context_line":"* Add a dedicated encryption workflow and implementation in Nova for creating"},{"line_number":330,"context_line":"  encrypted images from servers using the proposed image encryption format"}],"source_content_type":"text/x-rst","patch_set":11,"id":"7faddb67_b86ae8e9","line":327,"updated":"2019-08-05 17:32:57.000000000","message":"Just to be clear on all of the above... If the image has something sensitive in it, then it\u0027s safe until this step (or the download step, depending on the answers to the above). I guess it seems like a bit of a false security blanket to keep the thing locked up super tight until someone boots it, at which time the secrets are all dumped on disk in plaintext.\n\nIt seems like it would be a lot better to use some sort of natively encrypted disk format so that it\u0027s safe at rest in all the places.","commit_id":"88518116850638483468f2a9de86f4f2f22013d2"}]}