)]}'
{"specs/stein/image-encryption.rst":[{"author":{"_account_id":4523,"name":"Eric Harney","email":"eharney@redhat.com","username":"eharney"},"change_message_id":"ec6d42c6025928c6bdd155e64992684fdab7d354","unresolved":false,"context_lines":[{"line_number":60,"context_line":"uses an encrypted volume type (LUKS-based). The target image is to be"},{"line_number":61,"context_line":"re-encrypted using the proposed image encryption mechanism and a specified"},{"line_number":62,"context_line":"key."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"Proposed change"},{"line_number":66,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_66418c36","line":63,"updated":"2018-10-10 16:02:25.000000000","message":"2.2 and 2.3 are not clear to me in the context of this spec.\n\n2.2 sounds like it isn\u0027t going to use the encryption mechanism designed here?\n\n2.3 doesn\u0027t seem like the behavior I would expect.  If we are creating an encrypted image with the symmetric encryption described here, I would expect that encryption to be done on top of the LUKS layer used by Cinder volumes currently, not for the volume/image to be \"re-encrypted\".\n\nHow should these two encryption methods intersect?","commit_id":"b41b293cfba5034d213eaf54d27b6c19177b2434"},{"author":{"_account_id":28271,"name":"Josephine Seifert","email":"josephine.seifert@cloudandheat.com","username":"josei"},"change_message_id":"1e92020ffbaef824740bf242a7a680ebb8f3ca9a","unresolved":false,"context_lines":[{"line_number":60,"context_line":"uses an encrypted volume type (LUKS-based). The target image is to be"},{"line_number":61,"context_line":"re-encrypted using the proposed image encryption mechanism and a specified"},{"line_number":62,"context_line":"key."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"Proposed change"},{"line_number":66,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_c1dab548","line":63,"in_reply_to":"3f79a3b5_66418c36","updated":"2018-10-11 09:26:24.000000000","message":"Regarding 2.2: correct, we didn\u0027t want to break your current supported behavior of \"inheriting\" the encryption of the LUKS device. Thus, it will not use the GPG method but the LUKS method and will reflect the same behavior as before just with different metadata in the image. Would you prefer entirely removing this in favor of the proposed image encryption?\n\nRegarding 2.3: if we were to apply the encryption on top of the LUKS layer we\u0027d have to manage, store and transfer two keys, the key for the image encryption plus the key for the encapsulated LUKS encryption. However, we\u0027d like to treat images and volumes as separate resources that can be transformed into one another instead.","commit_id":"b41b293cfba5034d213eaf54d27b6c19177b2434"},{"author":{"_account_id":4523,"name":"Eric Harney","email":"eharney@redhat.com","username":"eharney"},"change_message_id":"ec6d42c6025928c6bdd155e64992684fdab7d354","unresolved":false,"context_lines":[{"line_number":220,"context_line":""},{"line_number":221,"context_line":"* Add a dedicated encryption workflow and implementation in Cinder for"},{"line_number":222,"context_line":"  creating encrypted images from volumes using the proposed image encryption"},{"line_number":223,"context_line":"  format (GPG)"},{"line_number":224,"context_line":""},{"line_number":225,"context_line":""},{"line_number":226,"context_line":"Dependencies"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_86d86880","line":223,"updated":"2018-10-10 16:02:25.000000000","message":"What is the workflow?  Is this new arguments to \"cinder upload-to-image\"?\n\nCan users provide a key or is the key always generated behind the scenes?","commit_id":"b41b293cfba5034d213eaf54d27b6c19177b2434"},{"author":{"_account_id":28271,"name":"Josephine Seifert","email":"josephine.seifert@cloudandheat.com","username":"josei"},"change_message_id":"1e92020ffbaef824740bf242a7a680ebb8f3ca9a","unresolved":false,"context_lines":[{"line_number":220,"context_line":""},{"line_number":221,"context_line":"* Add a dedicated encryption workflow and implementation in Cinder for"},{"line_number":222,"context_line":"  creating encrypted images from volumes using the proposed image encryption"},{"line_number":223,"context_line":"  format (GPG)"},{"line_number":224,"context_line":""},{"line_number":225,"context_line":""},{"line_number":226,"context_line":"Dependencies"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_24b13746","line":223,"in_reply_to":"3f79a3b5_86d86880","updated":"2018-10-11 09:26:24.000000000","message":"correct, the encryption should take place at the point \"cinder upload-to-image\". In our proposal users should provide a key-id referencing the key in the key-manger, that should be used for encryption. The key-id will then be part of the metadata of the encrypted image.","commit_id":"b41b293cfba5034d213eaf54d27b6c19177b2434"},{"author":{"_account_id":4523,"name":"Eric Harney","email":"eharney@redhat.com","username":"eharney"},"change_message_id":"ec6d42c6025928c6bdd155e64992684fdab7d354","unresolved":false,"context_lines":[{"line_number":262,"context_line":"References"},{"line_number":263,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":264,"context_line":""},{"line_number":265,"context_line":"None"},{"line_number":266,"context_line":""},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"History"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_e6f11c02","line":265,"updated":"2018-10-10 16:02:25.000000000","message":"Specs in other projects?","commit_id":"b41b293cfba5034d213eaf54d27b6c19177b2434"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"5853d050f6c2c14225ef038d31bbfe1de7c2101d","unresolved":false,"context_lines":[{"line_number":33,"context_line":"foremost this includes the image storage hosts of Glance itself. Furthermore"},{"line_number":34,"context_line":"it might also involve other systems such as volume hosts. In conclusion they"},{"line_number":35,"context_line":"are exposed to a multitude of potential scenarios involving different hosts"},{"line_number":36,"context_line":"with different access patterns and attack surfaces. The OpenStack components"},{"line_number":37,"context_line":"involved in those scenarios – including Cinder - do not protect the"},{"line_number":38,"context_line":"confidentiality of image data. That’s why we propose the introduction of an"},{"line_number":39,"context_line":"encrypted image format."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_7b6f37fb","line":38,"range":{"start_line":36,"start_character":52,"end_line":38,"end_character":30},"updated":"2018-10-31 16:02:49.000000000","message":"This isn\u0027t quite true if the user is using the current Cinder LUKS-encrypted volume functionality.  I\u0027m bringing it up because in your case 2.2 below, you\u0027re proposing not to do anything at all but continue to use the current functionality.","commit_id":"eae92e6dda23978fb5936266a496b411af5f539b"},{"author":{"_account_id":4523,"name":"Eric Harney","email":"eharney@redhat.com","username":"eharney"},"change_message_id":"68c42ab0ff1af13a7c942292efb3c463e4b63cc7","unresolved":false,"context_lines":[{"line_number":220,"context_line":""},{"line_number":221,"context_line":"* Add a dedicated encryption workflow and implementation in Cinder for"},{"line_number":222,"context_line":"  creating encrypted images from volumes using the proposed image encryption"},{"line_number":223,"context_line":"  format (GPG)"},{"line_number":224,"context_line":""},{"line_number":225,"context_line":""},{"line_number":226,"context_line":"Dependencies"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_661b306f","line":223,"updated":"2018-10-17 16:24:08.000000000","message":"Glance has to learn how to delete keys from Barbican when images are deleted.","commit_id":"eae92e6dda23978fb5936266a496b411af5f539b"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"2057fe3bb8dd9c61c9fd470d7530b610d5f49e04","unresolved":false,"context_lines":[{"line_number":220,"context_line":""},{"line_number":221,"context_line":"* Add a dedicated encryption workflow and implementation in Cinder for"},{"line_number":222,"context_line":"  creating encrypted images from volumes using the proposed image encryption"},{"line_number":223,"context_line":"  format (GPG)"},{"line_number":224,"context_line":""},{"line_number":225,"context_line":""},{"line_number":226,"context_line":"Dependencies"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_bb062f74","line":223,"in_reply_to":"3f79a3b5_661b306f","updated":"2018-10-31 15:56:09.000000000","message":"I\u0027m not sure about that.  For cases 2.1 and 2.3, iiuc, the user will supply a key_id in Barbican.  So it\u0027s possible that there will be a one-to-many relation between a key and encrypted images.  And even if you delete all the images using key K, you still might want to keep K around to use the next time you create an encrypted image.  So I think this proposal places the key management responsibility on the user (except for the LUKS case that\u0027s using the current Cinder functionality ... Glance needs to learn about that one because I believe it\u0027s a unique per-image key that\u0027s created in Barbican?).\n\nI think it would be a good idea to make the user key management expectations explicit in the Problem Description section.","commit_id":"eae92e6dda23978fb5936266a496b411af5f539b"},{"author":{"_account_id":4523,"name":"Eric Harney","email":"eharney@redhat.com","username":"eharney"},"change_message_id":"1f30d6f90efa5b6960babe3ff87b97d926a3e6d5","unresolved":false,"context_lines":[{"line_number":220,"context_line":""},{"line_number":221,"context_line":"* Add a dedicated encryption workflow and implementation in Cinder for"},{"line_number":222,"context_line":"  creating encrypted images from volumes using the proposed image encryption"},{"line_number":223,"context_line":"  format (GPG)"},{"line_number":224,"context_line":""},{"line_number":225,"context_line":""},{"line_number":226,"context_line":"Dependencies"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_ca5f7e0e","line":223,"in_reply_to":"3f79a3b5_bb062f74","updated":"2018-11-01 19:20:40.000000000","message":"Yes, we definitely need to define this carefully...\n\nCurrently, Cinder assumes a 1:1 relationship between volumes and keys.  When uploading encrypted volumes to Glance, this assumption is kept in the same way.  (A new key is cloned just for the Glance image.)\n\nI assume this model would extend to encrypted Glance images, but I don\u0027t know -- is there a reason to model it differently?  If so, it should be described as part of these specs...","commit_id":"eae92e6dda23978fb5936266a496b411af5f539b"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"e811e9e1295f3524243b666563e6d13afd73ef31","unresolved":false,"context_lines":[{"line_number":235,"context_line":""},{"line_number":236,"context_line":"* This spec requires the implementation of appropriate encryption/decryption"},{"line_number":237,"context_line":"  functionality in a global library shared between the components involved"},{"line_number":238,"context_line":"  in image encryption workflows (Nova, Cinder, OSC), like OpenStack SDK for"},{"line_number":239,"context_line":"  example"},{"line_number":240,"context_line":""},{"line_number":241,"context_line":""},{"line_number":242,"context_line":"Testing"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_05b007dc","line":239,"range":{"start_line":238,"start_character":53,"end_line":239,"end_character":9},"updated":"2018-11-01 20:32:35.000000000","message":"I just want to flag this.  I\u0027m not convinced that OpenStack SDK is the correct place for this.  There\u0027s discussion happening on this etherpad: https://etherpad.openstack.org/p/library-for-image-encryption-and-decryption","commit_id":"eae92e6dda23978fb5936266a496b411af5f539b"},{"author":{"_account_id":4523,"name":"Eric Harney","email":"eharney@redhat.com","username":"eharney"},"change_message_id":"196a3cde5bc2035dbbafe9712197fbe035897147","unresolved":false,"context_lines":[{"line_number":235,"context_line":""},{"line_number":236,"context_line":"* This spec requires the implementation of appropriate encryption/decryption"},{"line_number":237,"context_line":"  functionality in a global library shared between the components involved"},{"line_number":238,"context_line":"  in image encryption workflows (Nova, Cinder, OSC), like OpenStack SDK for"},{"line_number":239,"context_line":"  example"},{"line_number":240,"context_line":""},{"line_number":241,"context_line":""},{"line_number":242,"context_line":"Testing"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_5f1a476b","line":239,"range":{"start_line":238,"start_character":53,"end_line":239,"end_character":9},"in_reply_to":"3f79a3b5_05b007dc","updated":"2018-11-16 11:24:44.000000000","message":"We talked about this at the summit a bit -- the current plan is not to use OpenStack SDK for this.","commit_id":"eae92e6dda23978fb5936266a496b411af5f539b"},{"author":{"_account_id":28271,"name":"Josephine Seifert","email":"josephine.seifert@cloudandheat.com","username":"josei"},"change_message_id":"19d19ad5626853784c1bdef31ebc96dbacfa69b3","unresolved":false,"context_lines":[{"line_number":235,"context_line":""},{"line_number":236,"context_line":"* This spec requires the implementation of appropriate encryption/decryption"},{"line_number":237,"context_line":"  functionality in a global library shared between the components involved"},{"line_number":238,"context_line":"  in image encryption workflows (Nova, Cinder, OSC), like OpenStack SDK for"},{"line_number":239,"context_line":"  example"},{"line_number":240,"context_line":""},{"line_number":241,"context_line":""},{"line_number":242,"context_line":"Testing"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_7f52a313","line":239,"range":{"start_line":238,"start_character":53,"end_line":239,"end_character":9},"in_reply_to":"3f79a3b5_5f1a476b","updated":"2018-11-16 11:28:26.000000000","message":"I\u0027m currently writing the spec for the oslo library and will update all other specs after that.","commit_id":"eae92e6dda23978fb5936266a496b411af5f539b"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"ddbe10a22b8143d24013d7010a0bfa5377f5ce79","unresolved":false,"context_lines":[{"line_number":55,"context_line":"1. A user wants to create a new volume based on an encrypted image. The"},{"line_number":56,"context_line":"corresponding volume host has to be able to decrypt the image using the"},{"line_number":57,"context_line":"symmetric key stored in the key manager and transform it into the requested"},{"line_number":58,"context_line":"volume resource."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"2.1. A user wants to create an encrypted image from a volume. The volume"},{"line_number":61,"context_line":"does not use an encrypted volume type. The target image is to be encrypted"}],"source_content_type":"text/x-rst","patch_set":4,"id":"dfd5e7cf_97917e9c","line":58,"updated":"2019-01-09 21:01:12.000000000","message":"Whether the resulting volume is encrypted or not depends on the volume-type.  So it would be possible for someone to create an unencrypted volume from an encrypted image and then create an unencrypted image from the volume.  I guess that\u0027s OK?  It makes it really easy to compromise the encrypted data by mistake, though.","commit_id":"10ee169dcba161ab7a3b695b58b69538b2a6c19e"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"ddbe10a22b8143d24013d7010a0bfa5377f5ce79","unresolved":false,"context_lines":[{"line_number":69,"context_line":"2.3. A user wants to create an encrypted image from a volume. The volume"},{"line_number":70,"context_line":"uses an encrypted volume type (LUKS-based). The target image is to be"},{"line_number":71,"context_line":"re-encrypted using the proposed image encryption mechanism and a specified"},{"line_number":72,"context_line":"key."},{"line_number":73,"context_line":""},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":4,"id":"dfd5e7cf_3744521b","line":72,"updated":"2019-01-09 21:01:12.000000000","message":"use case 2.3: you have a cinder-encrypted volume that you want to store in glance using the new scheme.  With the current LUKS-based encryption in Cinder, don\u0027t you need to get the volume into an unencrypted state before you can encrypt it in-flight using the new scheme?  Looking at the current code, you\u0027d have to change the volume-type to an unencrypted type, and the only way to do that is to do a volume migration (and then only if the volume-type has an \u0027on-demand\u0027 migration_policy).  I guess the code could do this all behind the scenes (clone the volume, migrate the volume, convert volume to image, delete the migrated clone, probably some extra metadata management).  This seems pretty resource-intensive, though.  Is it what you have in mind, or am I completely misunderstanding how this would work?  I wonder whether we should allow only use cases 2.2 and 2.1.","commit_id":"10ee169dcba161ab7a3b695b58b69538b2a6c19e"},{"author":{"_account_id":28948,"name":"Liang Fang","email":"liang.a.fang@intel.com","username":"liang"},"change_message_id":"d935bee4e9cd76b5244ec65fb52a373ac58d81ca","unresolved":false,"context_lines":[{"line_number":69,"context_line":"2.3. A user wants to create an encrypted image from a volume. The volume"},{"line_number":70,"context_line":"uses an encrypted volume type (LUKS-based). The target image is to be"},{"line_number":71,"context_line":"re-encrypted using the proposed image encryption mechanism and a specified"},{"line_number":72,"context_line":"key."},{"line_number":73,"context_line":""},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfdaf3ff_09c59a3c","line":72,"in_reply_to":"dfd5e7cf_3744521b","updated":"2019-01-14 01:03:38.000000000","message":"encrypt/decrypt-intensive, can leverage some hardware accelerators which may already integrated in the server. So we may can allow the use case, but let user to decide whether to use the case or not.","commit_id":"10ee169dcba161ab7a3b695b58b69538b2a6c19e"},{"author":{"_account_id":15961,"name":"lisali","email":"xiaoyan.li@intel.com","username":"lisali"},"change_message_id":"c311c8760d8a78d971eb2d156e1215c48b48341f","unresolved":false,"context_lines":[{"line_number":90,"context_line":"mechanism."},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"For general image encryption, we propose to use an implementation of"},{"line_number":93,"context_line":"symmetric AES 256 provided by GnuPG as a basic mechanism supported by this"},{"line_number":94,"context_line":"draft. It is a well established implementation of PGP and supports"},{"line_number":95,"context_line":"streamable encryption/decryption processes, which is important as we require"},{"line_number":96,"context_line":"the streamability of the encryption/decryption mechanism for two reasons:"}],"source_content_type":"text/x-rst","patch_set":4,"id":"dfd5e7cf_c67672d9","line":93,"updated":"2019-01-10 06:03:42.000000000","message":"Can we put doc about GnuPG in references part?","commit_id":"10ee169dcba161ab7a3b695b58b69538b2a6c19e"},{"author":{"_account_id":15961,"name":"lisali","email":"xiaoyan.li@intel.com","username":"lisali"},"change_message_id":"c311c8760d8a78d971eb2d156e1215c48b48341f","unresolved":false,"context_lines":[{"line_number":135,"context_line":""},{"line_number":136,"context_line":"For creating encrypted images from volumes, additional properties in the"},{"line_number":137,"context_line":"request body of “os-volume_upload_image” will need to be introduced to"},{"line_number":138,"context_line":"specify the desired encryption format and key id."},{"line_number":139,"context_line":""},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"Security impact"}],"source_content_type":"text/x-rst","patch_set":4,"id":"dfd5e7cf_06b8fa73","line":138,"updated":"2019-01-10 06:03:42.000000000","message":"-1 Do users need to provide an encryption key when uploading a volume to an encrypted image? \nIs it enough to give key length and encryption format? Let Cinder create an encryption key and encrypt the image.","commit_id":"10ee169dcba161ab7a3b695b58b69538b2a6c19e"},{"author":{"_account_id":15961,"name":"lisali","email":"xiaoyan.li@intel.com","username":"lisali"},"change_message_id":"c311c8760d8a78d971eb2d156e1215c48b48341f","unresolved":false,"context_lines":[{"line_number":230,"context_line":""},{"line_number":231,"context_line":"* Add a dedicated encryption workflow and implementation in Cinder for"},{"line_number":232,"context_line":"  creating encrypted images from volumes using the proposed image encryption"},{"line_number":233,"context_line":"  format (GPG)"},{"line_number":234,"context_line":""},{"line_number":235,"context_line":""},{"line_number":236,"context_line":"Dependencies"}],"source_content_type":"text/x-rst","patch_set":4,"id":"dfd5e7cf_71798291","line":233,"updated":"2019-01-10 06:03:42.000000000","message":"-1 Please also address Eric\u0027s comments in the last patch. When uploading encrypted images, Cinder creates/clones the encryption key of the image, and passes it to Glance. Glance is responsible for deletion of the encryption key.\nAs when deleting every encrypted volume, its encryption key is deleted. An encryption key can\u0027t be shared by more than one objects(volume or image).","commit_id":"10ee169dcba161ab7a3b695b58b69538b2a6c19e"}],"specs/train/image-encryption.rst":[{"author":{"_account_id":18058,"name":"Lucio Seki","email":"lseki@redhat.com","username":"lseki"},"change_message_id":"4111060daf9f18d512ec64cdc9e97d8f4766af9b","unresolved":false,"context_lines":[{"line_number":108,"context_line":"simply copied into the image, the encryption (usually LUKS) is automatically"},{"line_number":109,"context_line":"inherited - as is the encryption key, which is simply cloned in Barbican."},{"line_number":110,"context_line":"We will not change this behavior as a part of this spec. Our changes will"},{"line_number":111,"context_line":"only apply, when the user activly wants to create an encrypted image from"},{"line_number":112,"context_line":"any volume."},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"The key management is handled differently than with encrypted volumes or"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9fb8cfa7_4db7123c","line":111,"range":{"start_line":111,"start_character":26,"end_line":111,"end_character":33},"updated":"2019-06-19 17:31:49.000000000","message":"s/activly/actively","commit_id":"8f7f1769c037ff0e8edc9e6e5129e4521e5325a0"},{"author":{"_account_id":4523,"name":"Eric Harney","email":"eharney@redhat.com","username":"eharney"},"change_message_id":"4f211679d6063d92655932619c504bb8c6de5ab2","unresolved":false,"context_lines":[{"line_number":80,"context_line":""},{"line_number":81,"context_line":"For Cinder we want to add support for encrypted image decryption when a"},{"line_number":82,"context_line":"volume is created from it. Cinder should select a suitable decryption"},{"line_number":83,"context_line":"mechanism according to the new image container_format and metadata. The"},{"line_number":84,"context_line":"symmetric key will be retrieved from the key manager (e.g. Barbican)"},{"line_number":85,"context_line":"according to the key id stored in the metadata. Additionally, Cinder should"},{"line_number":86,"context_line":"be able to encrypt volume data in a similar fashion if the user requests an"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9fb8cfa7_68903fee","line":83,"updated":"2019-06-27 17:14:06.000000000","message":"What format/metadata will be recorded?  Is it always gpg-encrypted raw, or also gpg-encrypted qcow2, etc.?\n\nHow do those appear in the Glance metadata?\n\nYou also need metadata to record that these are encrypted with gpg, so it\u0027s possible to transition to a different encryption method later if desired without causing problems.","commit_id":"9b13e76e17117ae6cfc5181469f405075379dd88"},{"author":{"_account_id":28271,"name":"Josephine Seifert","email":"josephine.seifert@cloudandheat.com","username":"josei"},"change_message_id":"4c080496207a75d1779417094e1b854f70856634","unresolved":false,"context_lines":[{"line_number":80,"context_line":""},{"line_number":81,"context_line":"For Cinder we want to add support for encrypted image decryption when a"},{"line_number":82,"context_line":"volume is created from it. Cinder should select a suitable decryption"},{"line_number":83,"context_line":"mechanism according to the new image container_format and metadata. The"},{"line_number":84,"context_line":"symmetric key will be retrieved from the key manager (e.g. Barbican)"},{"line_number":85,"context_line":"according to the key id stored in the metadata. Additionally, Cinder should"},{"line_number":86,"context_line":"be able to encrypt volume data in a similar fashion if the user requests an"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9fb8cfa7_8daa586e","line":83,"in_reply_to":"9fb8cfa7_68903fee","updated":"2019-06-28 10:37:04.000000000","message":"We specify metadata properties in glance. I will add them in this description. One example is \"os_decrypt_container_format\" which describes the format of the payload after the decryption. Handling these formats appropriately is up to the corresponding workflows.","commit_id":"9b13e76e17117ae6cfc5181469f405075379dd88"},{"author":{"_account_id":4523,"name":"Eric Harney","email":"eharney@redhat.com","username":"eharney"},"change_message_id":"4f211679d6063d92655932619c504bb8c6de5ab2","unresolved":false,"context_lines":[{"line_number":145,"context_line":"Secondly, in contrast to native LUKS used by LibVirt, the LUKS handling"},{"line_number":146,"context_line":"available via cryptsetup creates temporary device mapper endpoints where data"},{"line_number":147,"context_line":"is read from or written to. There is no direct reading/writing from/to an"},{"line_number":148,"context_line":"encrypted LUKS file and LUKS opening/closing needs to be handled accordingly."},{"line_number":149,"context_line":"Lastly, LUKS is a format primarily designed for disk encryption. Although it"},{"line_number":150,"context_line":"may be used for files as well (by formatting files as LUKS devices), the"},{"line_number":151,"context_line":"handling is rather inconvenient; for example, the size of the LUKS container"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9fb8cfa7_48c3fbed","line":148,"updated":"2019-06-27 17:14:06.000000000","message":"You can directly read from LUKS files w/ qemu-img convert -o encrypt.format\u003dluks etc.\n\nSee\n    https://review.opendev.org/#/c/597148/8/cinder/volume/drivers/remotefs.py\n\nfor an example","commit_id":"9b13e76e17117ae6cfc5181469f405075379dd88"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"07facb14e33710eabd6876e093cbf1b617571cd0","unresolved":false,"context_lines":[{"line_number":145,"context_line":"Secondly, in contrast to native LUKS used by LibVirt, the LUKS handling"},{"line_number":146,"context_line":"available via cryptsetup creates temporary device mapper endpoints where data"},{"line_number":147,"context_line":"is read from or written to. There is no direct reading/writing from/to an"},{"line_number":148,"context_line":"encrypted LUKS file and LUKS opening/closing needs to be handled accordingly."},{"line_number":149,"context_line":"Lastly, LUKS is a format primarily designed for disk encryption. Although it"},{"line_number":150,"context_line":"may be used for files as well (by formatting files as LUKS devices), the"},{"line_number":151,"context_line":"handling is rather inconvenient; for example, the size of the LUKS container"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9fb8cfa7_b75446ff","line":148,"in_reply_to":"9fb8cfa7_48c3fbed","updated":"2019-06-28 12:07:44.000000000","message":"Thanks for the hint!\nActually we\u0027ve encountered qemu-img before. However, it requires the passphrase to be supplied via a plain text file (see usage in cinder [1]). From our perspective, this is not a good start for a security related feature, so we chose not to go that route. With our proposed GPG approach, the passphrase can instead be directly passed to the library call.\n\nThe library to be introduced (in os.brick) for the encrypt/decrypt functions is supposed to define a generic architecture in a driver-like fashion that will allow other implementations besides the suggested GPG format to be added and used via the corresponding image encryption metadata. If we find a suitable solution involving qemu-img or other LUKS tools, a LUKS-based alternative could be added in the future.\n\n[1] https://github.com/openstack/cinder/blob/6077b3338903f6d82b43f7a2fa8de70f8fbe4ed8/cinder/image/image_utils.py#L178","commit_id":"9b13e76e17117ae6cfc5181469f405075379dd88"},{"author":{"_account_id":4523,"name":"Eric Harney","email":"eharney@redhat.com","username":"eharney"},"change_message_id":"4f211679d6063d92655932619c504bb8c6de5ab2","unresolved":false,"context_lines":[{"line_number":176,"context_line":""},{"line_number":177,"context_line":"* image encryption is introduced, thus additional cryptographic algorithms"},{"line_number":178,"context_line":"  will be used in Cinder to implement this functionality"},{"line_number":179,"context_line":""},{"line_number":180,"context_line":""},{"line_number":181,"context_line":"Notifications impact"},{"line_number":182,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9fb8cfa7_736110d3","line":179,"updated":"2019-06-27 17:14:06.000000000","message":"How does this interact w/ image signature verification in progress here?\n   https://review.opendev.org/#/c/585259/","commit_id":"9b13e76e17117ae6cfc5181469f405075379dd88"},{"author":{"_account_id":28271,"name":"Josephine Seifert","email":"josephine.seifert@cloudandheat.com","username":"josei"},"change_message_id":"4c080496207a75d1779417094e1b854f70856634","unresolved":false,"context_lines":[{"line_number":176,"context_line":""},{"line_number":177,"context_line":"* image encryption is introduced, thus additional cryptographic algorithms"},{"line_number":178,"context_line":"  will be used in Cinder to implement this functionality"},{"line_number":179,"context_line":""},{"line_number":180,"context_line":""},{"line_number":181,"context_line":"Notifications impact"},{"line_number":182,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9fb8cfa7_2dd24cd2","line":179,"in_reply_to":"9fb8cfa7_736110d3","updated":"2019-06-28 10:37:04.000000000","message":"The signature verification and the decryption of images proposed here should not interfere with each other. The signature is verified first and the decryption is happening afterwards.","commit_id":"9b13e76e17117ae6cfc5181469f405075379dd88"},{"author":{"_account_id":4523,"name":"Eric Harney","email":"eharney@redhat.com","username":"eharney"},"change_message_id":"4f211679d6063d92655932619c504bb8c6de5ab2","unresolved":false,"context_lines":[{"line_number":281,"context_line":"means that Tempest either needs to be provided with an image file that is"},{"line_number":282,"context_line":"already encrypted and its corresponding key or needs to be able to encrypt"},{"line_number":283,"context_line":"images itself. This point is still open for discussion."},{"line_number":284,"context_line":""},{"line_number":285,"context_line":""},{"line_number":286,"context_line":"Documentation Impact"},{"line_number":287,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9fb8cfa7_88001304","line":284,"updated":"2019-06-27 17:14:06.000000000","message":"Needs to be tested w/ iSCSI, RBD, and NFS, to ensure it works w/ different types of backends.","commit_id":"9b13e76e17117ae6cfc5181469f405075379dd88"},{"author":{"_account_id":28271,"name":"Josephine Seifert","email":"josephine.seifert@cloudandheat.com","username":"josei"},"change_message_id":"4c080496207a75d1779417094e1b854f70856634","unresolved":false,"context_lines":[{"line_number":281,"context_line":"means that Tempest either needs to be provided with an image file that is"},{"line_number":282,"context_line":"already encrypted and its corresponding key or needs to be able to encrypt"},{"line_number":283,"context_line":"images itself. This point is still open for discussion."},{"line_number":284,"context_line":""},{"line_number":285,"context_line":""},{"line_number":286,"context_line":"Documentation Impact"},{"line_number":287,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9fb8cfa7_117be28b","line":284,"in_reply_to":"9fb8cfa7_88001304","updated":"2019-06-28 10:37:04.000000000","message":"We use Ceph (RBD) as backend. Our systems are limited to this, so we would appreciate help with testing other backends.","commit_id":"9b13e76e17117ae6cfc5181469f405075379dd88"},{"author":{"_account_id":4523,"name":"Eric Harney","email":"eharney@redhat.com","username":"eharney"},"change_message_id":"4f211679d6063d92655932619c504bb8c6de5ab2","unresolved":false,"context_lines":[{"line_number":302,"context_line":"Nova-Spec: https://review.openstack.org/#/c/608696/"},{"line_number":303,"context_line":""},{"line_number":304,"context_line":"Glance-Spec: https://review.openstack.org/#/c/609667/"},{"line_number":305,"context_line":""},{"line_number":306,"context_line":""},{"line_number":307,"context_line":"History"},{"line_number":308,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9fb8cfa7_935cc419","line":305,"updated":"2019-06-27 17:14:06.000000000","message":"specs/rocky/support-image-signature-verification.rst","commit_id":"9b13e76e17117ae6cfc5181469f405075379dd88"}]}