)]}'
{"specs/train/volume-rekey.rst":[{"author":{"_account_id":4523,"name":"Eric Harney","email":"eharney@redhat.com","username":"eharney"},"change_message_id":"ea228191c5a04491a0aa26c977ce0d0e99653802","unresolved":false,"context_lines":[{"line_number":43,"context_line":"The rest of the clone process continues as normal afterward."},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"My current implementation does this by calling a new"},{"line_number":46,"context_line":"rekey_volume() driver method from the create_volume flow, with"},{"line_number":47,"context_line":"\"cryptsetup luksChangeKey\".  This should work for any iSCSI/FC"},{"line_number":48,"context_line":"drivers, which already must perform a similar attachment when"},{"line_number":49,"context_line":"creating a volume from an image."}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fb8cfa7_338dd831","line":46,"range":{"start_line":46,"start_character":0,"end_line":46,"end_character":28},"updated":"2019-06-12 16:44:28.000000000","message":"This isn\u0027t correct, I started w/ a driver method but it\u0027s actually done just from the create_volume flow in the manager/flow, not the driver.","commit_id":"212e0c907960eac8c50873ca14d7edf541fbb90a"},{"author":{"_account_id":4523,"name":"Eric Harney","email":"eharney@redhat.com","username":"eharney"},"change_message_id":"4e8c561a0d5595354e7a9164d6d19187729289fb","unresolved":false,"context_lines":[{"line_number":48,"context_line":"drivers, which already must perform a similar attachment when"},{"line_number":49,"context_line":"creating a volume from an image."},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"Some work is still needed to make this work for RBD, because"},{"line_number":52,"context_line":"there does not seem to be a qemu-img tool that can change"},{"line_number":53,"context_line":"encryption keys, and cryptsetup requires a local block device."},{"line_number":54,"context_line":"This likely means that implementing this for the RBD driver"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7faddb67_86768a3e","line":51,"updated":"2019-07-03 16:20:04.000000000","message":"I\u0027m going to punt on RBD for Train and just cover iSCSI/FC.","commit_id":"212e0c907960eac8c50873ca14d7edf541fbb90a"},{"author":{"_account_id":7198,"name":"Jay Bryant","email":"jungleboyj@electronicjungle.net","username":"jsbryant"},"change_message_id":"e7c7810e091fce0f4b9f05fae337a65026f80fd0","unresolved":false,"context_lines":[{"line_number":57,"context_line":""},{"line_number":58,"context_line":"NBD is not widely supported in relevant OSes, so krbd looks like"},{"line_number":59,"context_line":"the choice there."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"Alternatives"},{"line_number":62,"context_line":"------------"},{"line_number":63,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"7faddb67_495f45e5","line":60,"updated":"2019-07-03 17:05:12.000000000","message":"Playing devil\u0027s advocate, is it possible that users would not want to rekey?  Do we need an option to not do that?","commit_id":"7a1e9f33dc23a76c1b9f9bdadad3438f0fbeef8a"},{"author":{"_account_id":4523,"name":"Eric Harney","email":"eharney@redhat.com","username":"eharney"},"change_message_id":"ced04801972671aa2b18d6f0fb4768e15362a424","unresolved":false,"context_lines":[{"line_number":57,"context_line":""},{"line_number":58,"context_line":"NBD is not widely supported in relevant OSes, so krbd looks like"},{"line_number":59,"context_line":"the choice there."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"Alternatives"},{"line_number":62,"context_line":"------------"},{"line_number":63,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"7faddb67_f0500261","line":60,"in_reply_to":"7faddb67_495f45e5","updated":"2019-07-09 20:14:35.000000000","message":"It\u0027s possible, but I\u0027m not sure whether the perf benefit (which I assume is the only argument) of avoiding rekeying is worth the security impact.\n\nIt might be better to just tell those folks to not use encrypted volumes.\n\n(We could add an option if we think there\u0027s a good case for it, though.)","commit_id":"7a1e9f33dc23a76c1b9f9bdadad3438f0fbeef8a"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"b7e82cc4e0fb2d7553bc75a7a9cb5988526e0016","unresolved":false,"context_lines":[{"line_number":57,"context_line":""},{"line_number":58,"context_line":"NBD is not widely supported in relevant OSes, so krbd looks like"},{"line_number":59,"context_line":"the choice there."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"Alternatives"},{"line_number":62,"context_line":"------------"},{"line_number":63,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"7faddb67_0d4a4e7f","line":60,"in_reply_to":"7faddb67_bb981fc0","updated":"2019-07-10 21:09:21.000000000","message":"I just learned that Barbican is implementing a spec in Train that implements a \u0027Consumers API\u0027 on secrets.  This basically allows you to \"protect\" secrets (Cinder would register as a consumer of the secrets it creates, and until it un-registers (say, when an encrypted volume is deleted), a Barbican user has to use a \"force\" flag to delete the secret.\n\nThe Barbican spec is https://review.opendev.org/#/c/662013/\n\nI don\u0027t know that we can use it in Train, but it would definitely be worth a follow-up in U.","commit_id":"7a1e9f33dc23a76c1b9f9bdadad3438f0fbeef8a"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"53d6de7ada5ffc05473ac407a79c8c51a1acf4c8","unresolved":false,"context_lines":[{"line_number":57,"context_line":""},{"line_number":58,"context_line":"NBD is not widely supported in relevant OSes, so krbd looks like"},{"line_number":59,"context_line":"the choice there."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"Alternatives"},{"line_number":62,"context_line":"------------"},{"line_number":63,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"7faddb67_bb981fc0","line":60,"in_reply_to":"7faddb67_f0500261","updated":"2019-07-10 14:43:35.000000000","message":"Right now, when you clone a volume, you get a new secret in Barbican in a 1-1 relation to that volume.  (It\u0027s just that the value of the secret is the same for both the original volume and the clone.)  So I imagine that most people think Cinder is already implementing the more robust security feature described in this spec.\n\nMy point is that if what Jay\u0027s devil\u0027s-advocating was something users might want, we\u0027d already have heard about it.  So I don\u0027t think we need to add this as an option.\n\nOn the other hand ... the current implementation does allow you to recover from a mistaken deletion of Barbican secret that\u0027s associated with a non-deleted volume.  I looked at the Barbican API and it doesn\u0027t look like there\u0027s a way to set a \u0027protected\u0027 field on a secret (like you can on a Glance image) so that it can\u0027t be deleted until the \u0027protected\u0027 field is cleared.  I don\u0027t think we currently set any metadata on the secret saying that it\u0027s been created by Cinder?  That wouldn\u0027t prevent inadvertent deletion, but it might be helpful for key maintenance.\n\nI still think that most users and operators aren\u0027t aware that recovery from a prematurely-deleted Barbican secret for a volume is currently possible.  But it is, and it feels kind of icky to take that away.  (Which I know is inconsistent with everything I\u0027ve said up to this point!)  Maybe the thing to do here is what Eric mentioned above, namely, to tell people not to use encrypted volumes if they\u0027re worried about data loss.  This way, a user has a clear choice: (A) good security, but possible data loss if some bozo in your project deletes the secret out of Barbican, vs. (B) using non-encrypted images.  I don\u0027t like offering a third choice of encrypted images that can all be compromised by one leaked key.  And even with the current scheme, you could have total data loss if some joker deleted *all* the barbican secrets owned by a project.\n\nSo I\u0027m back to fully endorsing this spec.  I\u0027d feel better if Barbican offered \u0027protected\u0027 secrets, but that\u0027s a separate issue.  I think adding some kind of secret metadata (\u0027created-by\u0027: \u0027cinder\u0027) would be a good improvement, though.","commit_id":"7a1e9f33dc23a76c1b9f9bdadad3438f0fbeef8a"},{"author":{"_account_id":7198,"name":"Jay Bryant","email":"jungleboyj@electronicjungle.net","username":"jsbryant"},"change_message_id":"e7c7810e091fce0f4b9f05fae337a65026f80fd0","unresolved":false,"context_lines":[{"line_number":123,"context_line":"Work Items"},{"line_number":124,"context_line":"----------"},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"* Implement this for iSCSI drivers"},{"line_number":127,"context_line":"* Test with the LVM driver"},{"line_number":128,"context_line":"* Implement this for RBD"},{"line_number":129,"context_line":"  - Requires some additional effort"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7faddb67_a9bb590c","line":126,"range":{"start_line":126,"start_character":0,"end_line":126,"end_character":34},"updated":"2019-07-03 17:05:12.000000000","message":"What about FC?","commit_id":"7a1e9f33dc23a76c1b9f9bdadad3438f0fbeef8a"},{"author":{"_account_id":4523,"name":"Eric Harney","email":"eharney@redhat.com","username":"eharney"},"change_message_id":"ced04801972671aa2b18d6f0fb4768e15362a424","unresolved":false,"context_lines":[{"line_number":123,"context_line":"Work Items"},{"line_number":124,"context_line":"----------"},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"* Implement this for iSCSI drivers"},{"line_number":127,"context_line":"* Test with the LVM driver"},{"line_number":128,"context_line":"* Implement this for RBD"},{"line_number":129,"context_line":"  - Requires some additional effort"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7faddb67_30d45abd","line":126,"range":{"start_line":126,"start_character":0,"end_line":126,"end_character":34},"in_reply_to":"7faddb67_a9bb590c","updated":"2019-07-09 20:14:35.000000000","message":"What I am implementing currently should work on iSCSI and FC.","commit_id":"7a1e9f33dc23a76c1b9f9bdadad3438f0fbeef8a"},{"author":{"_account_id":7198,"name":"Jay Bryant","email":"jungleboyj@electronicjungle.net","username":"jsbryant"},"change_message_id":"e7c7810e091fce0f4b9f05fae337a65026f80fd0","unresolved":false,"context_lines":[{"line_number":125,"context_line":""},{"line_number":126,"context_line":"* Implement this for iSCSI drivers"},{"line_number":127,"context_line":"* Test with the LVM driver"},{"line_number":128,"context_line":"* Implement this for RBD"},{"line_number":129,"context_line":"  - Requires some additional effort"},{"line_number":130,"context_line":"* Consider additional cases where this concept would be useful"},{"line_number":131,"context_line":"  - Volume transfer"},{"line_number":132,"context_line":"  - Backup restoration (?)"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7faddb67_c9c49595","line":129,"range":{"start_line":128,"start_character":0,"end_line":129,"end_character":35},"updated":"2019-07-03 17:05:12.000000000","message":"Do we want to remove this since you are planning to do this after Train?","commit_id":"7a1e9f33dc23a76c1b9f9bdadad3438f0fbeef8a"},{"author":{"_account_id":4523,"name":"Eric Harney","email":"eharney@redhat.com","username":"eharney"},"change_message_id":"ced04801972671aa2b18d6f0fb4768e15362a424","unresolved":false,"context_lines":[{"line_number":125,"context_line":""},{"line_number":126,"context_line":"* Implement this for iSCSI drivers"},{"line_number":127,"context_line":"* Test with the LVM driver"},{"line_number":128,"context_line":"* Implement this for RBD"},{"line_number":129,"context_line":"  - Requires some additional effort"},{"line_number":130,"context_line":"* Consider additional cases where this concept would be useful"},{"line_number":131,"context_line":"  - Volume transfer"},{"line_number":132,"context_line":"  - Backup restoration (?)"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7faddb67_d0daa6e7","line":129,"range":{"start_line":128,"start_character":0,"end_line":129,"end_character":35},"in_reply_to":"7faddb67_c9c49595","updated":"2019-07-09 20:14:35.000000000","message":"Yes","commit_id":"7a1e9f33dc23a76c1b9f9bdadad3438f0fbeef8a"}]}