)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"aaf8a8a6eac6124f735263b4ba3656d12619b1f1","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"52ae5483_851181e4","updated":"2024-12-10 15:50:15.000000000","message":"It is a well written spec. Thanks Artom! I think I don\u0027t have any serious issues with the spec just a bunch of clarifications inline.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ec23316314f01a981e73ee16d26d16b3e7c07020","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":9,"id":"06090ace_53d7d566","updated":"2025-01-06 18:03:20.000000000","message":"I guess I\u0027m the odd person out here, but I think we need to seriously consider why adding these easily-surmountable hurdles make the system *actually* more secure and not just more of a pain for the operators. If no operator ever lets there be a flavor with vTPM and without the \"can manage this when I need to flag\" then we\u0027ve added a bunch of complexity and process for no reason.","commit_id":"d718f140c91639698e433885c4286dba8da12887"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"d4be66605e411336c9583ceaffbbe2bbf57a4f8c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":9,"id":"719dd04f_40e1172d","updated":"2025-01-06 20:13:36.000000000","message":"Not sure if I\u0027ve missed anything due to PTO brain, but I have tried to add my thoughts regarding the handling of the secrets.","commit_id":"d718f140c91639698e433885c4286dba8da12887"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"47ce09ee6fe121aa42f497923c44ac5407351892","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":9,"id":"7a67cea7_e8d6f968","updated":"2025-01-06 21:00:56.000000000","message":"Sorry, we raced for the last comment and I didn\u0027t see that you had added comments.","commit_id":"d718f140c91639698e433885c4286dba8da12887"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4fc47bd7b1a34432e1becad8380a717f55d01c39","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":11,"id":"7bd520bc_17af5ae7","updated":"2025-01-09 20:18:23.000000000","message":"+1 becausie this is close but we are still tring to finalise a few detials.","commit_id":"ffca3fe48dd2aa8ef4b4bf1fc953b695586c294c"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d46d7072f7448bd30f917ba1f1b6d8afba11fa6c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":11,"id":"4f44ea4d_036dbd3b","updated":"2025-01-09 17:58:31.000000000","message":"Comments, but looks pretty much like what we discussed!","commit_id":"ffca3fe48dd2aa8ef4b4bf1fc953b695586c294c"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"7758776f6a19d3e1e8e732f8ae4008e098064f53","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":11,"id":"b79a3c7d_c97fccfa","updated":"2025-01-10 01:46:17.000000000","message":"I like the general direction here with the latest updates. I had one minor thought inline regarding the API block -- I\u0027m not sure how much I care about it really but it\u0027s something that is reminiscent of the local disk encryption series.","commit_id":"ffca3fe48dd2aa8ef4b4bf1fc953b695586c294c"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"7a8ea6322b2e4ae2ea0040a7515d5382ab22b2ed","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":11,"id":"ada5cb79_266ccbb0","updated":"2025-01-09 18:04:38.000000000","message":"Mass resolving open comments on previous versions, since PS11 changed things pretty drastically.","commit_id":"ffca3fe48dd2aa8ef4b4bf1fc953b695586c294c"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"9c9857ea08e63013d0fc5b4dc7e3a6f55103f3cb","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":12,"id":"412442da_d78a2102","updated":"2025-01-10 16:32:25.000000000","message":"Looks good to me.","commit_id":"d998ffd9cd10b29768bfd98ded0412ea5fc396ef"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"1cd6ce5d68a2ac757f01fa82895f2dfaee794c24","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":12,"id":"fb4a8f62_113d53e7","updated":"2025-01-10 16:18:58.000000000","message":"Some grammar nits, but not worth holding up.","commit_id":"d998ffd9cd10b29768bfd98ded0412ea5fc396ef"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"76f092ab97f8cb73884d00f3896a9ca7309f2c27","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":12,"id":"39a85325_e2ee0f77","updated":"2025-01-10 20:38:12.000000000","message":"This all looks good, sending it","commit_id":"d998ffd9cd10b29768bfd98ded0412ea5fc396ef"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"ca54e0efbe96c30f0272cca7de3e01c1dfacaf9d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":12,"id":"beb2c359_7758cf1e","updated":"2025-01-13 12:59:52.000000000","message":"recheck dependency merged","commit_id":"d998ffd9cd10b29768bfd98ded0412ea5fc396ef"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"470ba7e79e1fc992d681d97af1c5cdda348a8dcb","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":12,"id":"8ffa1db2_23215e10","updated":"2025-01-10 15:52:08.000000000","message":"there are still a few typos in this revision but i agree with the logic of the change\n\nso im ok to resolve those with a follow up patch or for others to proxy my +2 if you fell like re spinning to address them.","commit_id":"d998ffd9cd10b29768bfd98ded0412ea5fc396ef"}],"specs/2025.1/approved/vtpm-live-migration.rst":[{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"aaf8a8a6eac6124f735263b4ba3656d12619b1f1","unresolved":true,"context_lines":[{"line_number":12,"context_line":""},{"line_number":13,"context_line":"When Nova first added vTPM support, all non-spawn operations were `rejected"},{"line_number":14,"context_line":"\u003chttps://review.opendev.org/c/openstack/nova/+/741500\u003e`_ at the API level. Extra"},{"line_number":15,"context_line":"work was necessary to manage the vTPM state when moving an instance. This work"},{"line_number":16,"context_line":"was eventually completed for resize and cold migration, and those operations"},{"line_number":17,"context_line":"were `unblocked \u003chttps://review.opendev.org/c/openstack/nova/+/639934/52\u003e`_. The"},{"line_number":18,"context_line":"live migration block has remained in place to this day."},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"A TPM device is `required for certain features"},{"line_number":21,"context_line":"\u003chttps://learn.microsoft.com/en-us/windows-server/get-started/hardware-requirements\u003e`_"}],"source_content_type":"text/x-rst","patch_set":5,"id":"e2324e33_5e4716c4","line":18,"range":{"start_line":15,"start_character":69,"end_line":18,"end_character":55},"updated":"2024-12-10 15:50:15.000000000","message":"What about evacuation, shelve_offload and unshelve, and cross cell migration? Are those working already? Or does no work but out of scope of this spec? (Just want to have a clear picture not pushing to increase the scope)","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"cf7fac0a51df8a0fd2545da861eabd9526006d6d","unresolved":false,"context_lines":[{"line_number":12,"context_line":""},{"line_number":13,"context_line":"When Nova first added vTPM support, all non-spawn operations were `rejected"},{"line_number":14,"context_line":"\u003chttps://review.opendev.org/c/openstack/nova/+/741500\u003e`_ at the API level. Extra"},{"line_number":15,"context_line":"work was necessary to manage the vTPM state when moving an instance. This work"},{"line_number":16,"context_line":"was eventually completed for resize and cold migration, and those operations"},{"line_number":17,"context_line":"were `unblocked \u003chttps://review.opendev.org/c/openstack/nova/+/639934/52\u003e`_. The"},{"line_number":18,"context_line":"live migration block has remained in place to this day."},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"A TPM device is `required for certain features"},{"line_number":21,"context_line":"\u003chttps://learn.microsoft.com/en-us/windows-server/get-started/hardware-requirements\u003e`_"}],"source_content_type":"text/x-rst","patch_set":5,"id":"6209a210_4571e4b7","line":18,"range":{"start_line":15,"start_character":69,"end_line":18,"end_character":55},"in_reply_to":"3d38eb36_c0c4240a","updated":"2025-01-07 14:22:19.000000000","message":"Done","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"f067fb8042d1ac33ee88a35fd8608e018c68911a","unresolved":true,"context_lines":[{"line_number":12,"context_line":""},{"line_number":13,"context_line":"When Nova first added vTPM support, all non-spawn operations were `rejected"},{"line_number":14,"context_line":"\u003chttps://review.opendev.org/c/openstack/nova/+/741500\u003e`_ at the API level. Extra"},{"line_number":15,"context_line":"work was necessary to manage the vTPM state when moving an instance. This work"},{"line_number":16,"context_line":"was eventually completed for resize and cold migration, and those operations"},{"line_number":17,"context_line":"were `unblocked \u003chttps://review.opendev.org/c/openstack/nova/+/639934/52\u003e`_. The"},{"line_number":18,"context_line":"live migration block has remained in place to this day."},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"A TPM device is `required for certain features"},{"line_number":21,"context_line":"\u003chttps://learn.microsoft.com/en-us/windows-server/get-started/hardware-requirements\u003e`_"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3d38eb36_c0c4240a","line":18,"range":{"start_line":15,"start_character":69,"end_line":18,"end_character":55},"in_reply_to":"e2324e33_5e4716c4","updated":"2024-12-20 22:21:32.000000000","message":"Still blocked, I\u0027ve added that to the spec.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a337a2caf06f24d6d842ffd012a6c8280b9ccfd4","unresolved":true,"context_lines":[{"line_number":21,"context_line":"\u003chttps://learn.microsoft.com/en-us/windows-server/get-started/hardware-requirements\u003e`_"},{"line_number":22,"context_line":"of Windows Server 2022 and 2025, notably BitLocker Drive Encryption. The"},{"line_number":23,"context_line":"inability to live migrate instances with vTPM is a major roadblock for anyone"},{"line_number":24,"context_line":"operating Windows guests in an OpenStack cloud."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"Libvirt support for vTPM live migration now exists (more details in"},{"line_number":27,"context_line":":ref:`problem-description`), but Nova changes are necessary before being able"}],"source_content_type":"text/x-rst","patch_set":5,"id":"da18113d_67568865","line":24,"updated":"2024-12-09 19:48:58.000000000","message":"note that the 2024h2 update or windows 11 i belive also makes it a hard requirement and i belive the intent is to make it a hard requriement for all version of windows going forward.\n\nso evauentlly the impact of not having live migration with vtpm will be window guests (server and clinet) will not be live migratable.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4fc47bd7b1a34432e1becad8380a717f55d01c39","unresolved":false,"context_lines":[{"line_number":21,"context_line":"\u003chttps://learn.microsoft.com/en-us/windows-server/get-started/hardware-requirements\u003e`_"},{"line_number":22,"context_line":"of Windows Server 2022 and 2025, notably BitLocker Drive Encryption. The"},{"line_number":23,"context_line":"inability to live migrate instances with vTPM is a major roadblock for anyone"},{"line_number":24,"context_line":"operating Windows guests in an OpenStack cloud."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"Libvirt support for vTPM live migration now exists (more details in"},{"line_number":27,"context_line":":ref:`problem-description`), but Nova changes are necessary before being able"}],"source_content_type":"text/x-rst","patch_set":5,"id":"362026f3_cba9b614","line":24,"in_reply_to":"0a14b967_1fb770c4","updated":"2025-01-09 20:18:23.000000000","message":"Acknowledged","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d46d7072f7448bd30f917ba1f1b6d8afba11fa6c","unresolved":false,"context_lines":[{"line_number":21,"context_line":"\u003chttps://learn.microsoft.com/en-us/windows-server/get-started/hardware-requirements\u003e`_"},{"line_number":22,"context_line":"of Windows Server 2022 and 2025, notably BitLocker Drive Encryption. The"},{"line_number":23,"context_line":"inability to live migrate instances with vTPM is a major roadblock for anyone"},{"line_number":24,"context_line":"operating Windows guests in an OpenStack cloud."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"Libvirt support for vTPM live migration now exists (more details in"},{"line_number":27,"context_line":":ref:`problem-description`), but Nova changes are necessary before being able"}],"source_content_type":"text/x-rst","patch_set":5,"id":"ccb36353_484806f0","line":24,"in_reply_to":"0a14b967_1fb770c4","updated":"2025-01-09 17:58:31.000000000","message":"Done","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"f067fb8042d1ac33ee88a35fd8608e018c68911a","unresolved":true,"context_lines":[{"line_number":21,"context_line":"\u003chttps://learn.microsoft.com/en-us/windows-server/get-started/hardware-requirements\u003e`_"},{"line_number":22,"context_line":"of Windows Server 2022 and 2025, notably BitLocker Drive Encryption. The"},{"line_number":23,"context_line":"inability to live migrate instances with vTPM is a major roadblock for anyone"},{"line_number":24,"context_line":"operating Windows guests in an OpenStack cloud."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"Libvirt support for vTPM live migration now exists (more details in"},{"line_number":27,"context_line":":ref:`problem-description`), but Nova changes are necessary before being able"}],"source_content_type":"text/x-rst","patch_set":5,"id":"0a14b967_1fb770c4","line":24,"in_reply_to":"da18113d_67568865","updated":"2024-12-20 22:21:32.000000000","message":"Yep, added a mention of the Windows 11 TPM requirement.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a337a2caf06f24d6d842ffd012a6c8280b9ccfd4","unresolved":true,"context_lines":[{"line_number":34,"context_line":""},{"line_number":35,"context_line":"There are four aspects to vTPM live migration: shared vs non-shared vTPM state"},{"line_number":36,"context_line":"storage, Libvirt support, secret management, and upgrading pre-existing"},{"line_number":37,"context_line":"instances."},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"vTPM state storage"},{"line_number":40,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"4d1ab53d_30b80d21","line":37,"updated":"2024-12-09 19:48:58.000000000","message":"so one of the things i asked yo to include in this spec was supprot for encypted volume live migration.\n\nwe coudl technially do both seperatly but the solution proposed in this spec need to be extensibalve to that.\n\nif its not hten we sboudl not proceed with this spec.\n\nthere will be a non zero overlapp between instnace with encypted cinder volume and instnace with vTPM\n\nsince the problem statemnt is the same between both, the migration request is made by the admin and the secreate in barbaican is own by the user, i want this spec to at least acckoalge that and declare it out scope explictly.\n\nideally you woudl supprot both in the same spec but if we are doing this for scope contole i would perfer to make sure the design can be extended to cover the volume use canse when reviewing this.\n\nOrignally in the PTG i was leanign towards making a hard reqruiement but im a little more open to making it a incremental.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"f067fb8042d1ac33ee88a35fd8608e018c68911a","unresolved":true,"context_lines":[{"line_number":34,"context_line":""},{"line_number":35,"context_line":"There are four aspects to vTPM live migration: shared vs non-shared vTPM state"},{"line_number":36,"context_line":"storage, Libvirt support, secret management, and upgrading pre-existing"},{"line_number":37,"context_line":"instances."},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"vTPM state storage"},{"line_number":40,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"bfe8cf01_5501b080","line":37,"in_reply_to":"4d1ab53d_30b80d21","updated":"2024-12-20 22:21:32.000000000","message":"I kinda mention this further down, but I can add this to the problem description.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"7a8ea6322b2e4ae2ea0040a7515d5382ab22b2ed","unresolved":false,"context_lines":[{"line_number":34,"context_line":""},{"line_number":35,"context_line":"There are four aspects to vTPM live migration: shared vs non-shared vTPM state"},{"line_number":36,"context_line":"storage, Libvirt support, secret management, and upgrading pre-existing"},{"line_number":37,"context_line":"instances."},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"vTPM state storage"},{"line_number":40,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"2a58ab5a_33fd2e08","line":37,"in_reply_to":"bfe8cf01_5501b080","updated":"2025-01-09 18:04:38.000000000","message":"Done","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"2a535b5f38d0cd02c13961c03fb34084dbe80280","unresolved":true,"context_lines":[{"line_number":46,"context_line":"`does not support"},{"line_number":47,"context_line":"\u003chttps://opendev.org/openstack/nova/src/commit/c79bec0f2257967da1dcccc9f562253d6ede535d/nova/virt/libvirt/config.py#L1146-L1153\u003e`_."},{"line_number":48,"context_line":"Nova deployments use the Libvirt default vTPM state path. On both Ubuntu and"},{"line_number":49,"context_line":"Red Hat operating sytems, this path is ``/var/lib/libvirt/swtpm/\u003cinstance"},{"line_number":50,"context_line":"UUID\u003e``. This path is distinct from the instance state path and can be expected"},{"line_number":51,"context_line":"to never be on shared storage."},{"line_number":52,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"bae76241_07137c99","line":49,"range":{"start_line":49,"start_character":18,"end_line":49,"end_character":24},"updated":"2024-12-13 04:06:17.000000000","message":"systems","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"f067fb8042d1ac33ee88a35fd8608e018c68911a","unresolved":false,"context_lines":[{"line_number":46,"context_line":"`does not support"},{"line_number":47,"context_line":"\u003chttps://opendev.org/openstack/nova/src/commit/c79bec0f2257967da1dcccc9f562253d6ede535d/nova/virt/libvirt/config.py#L1146-L1153\u003e`_."},{"line_number":48,"context_line":"Nova deployments use the Libvirt default vTPM state path. On both Ubuntu and"},{"line_number":49,"context_line":"Red Hat operating sytems, this path is ``/var/lib/libvirt/swtpm/\u003cinstance"},{"line_number":50,"context_line":"UUID\u003e``. This path is distinct from the instance state path and can be expected"},{"line_number":51,"context_line":"to never be on shared storage."},{"line_number":52,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"082e8216_f3b7a8cf","line":49,"range":{"start_line":49,"start_character":18,"end_line":49,"end_character":24},"in_reply_to":"bae76241_07137c99","updated":"2024-12-20 22:21:32.000000000","message":"Done","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"aaf8a8a6eac6124f735263b4ba3656d12619b1f1","unresolved":true,"context_lines":[{"line_number":47,"context_line":"\u003chttps://opendev.org/openstack/nova/src/commit/c79bec0f2257967da1dcccc9f562253d6ede535d/nova/virt/libvirt/config.py#L1146-L1153\u003e`_."},{"line_number":48,"context_line":"Nova deployments use the Libvirt default vTPM state path. On both Ubuntu and"},{"line_number":49,"context_line":"Red Hat operating sytems, this path is ``/var/lib/libvirt/swtpm/\u003cinstance"},{"line_number":50,"context_line":"UUID\u003e``. This path is distinct from the instance state path and can be expected"},{"line_number":51,"context_line":"to never be on shared storage."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"Thus, this spec leaves shared storage vTPM live migration out of its scope, and"},{"line_number":54,"context_line":"assumes Libvirt will copy the vTPM state during the live migration."}],"source_content_type":"text/x-rst","patch_set":5,"id":"c1d65a38_c4c64251","line":51,"range":{"start_line":50,"start_character":9,"end_line":51,"end_character":30},"updated":"2024-12-10 15:50:15.000000000","message":"Hehe. In the other hand nothing prevents existing deployments to put this under NFS too. But the message below that it is out of scope is OK.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"f067fb8042d1ac33ee88a35fd8608e018c68911a","unresolved":true,"context_lines":[{"line_number":47,"context_line":"\u003chttps://opendev.org/openstack/nova/src/commit/c79bec0f2257967da1dcccc9f562253d6ede535d/nova/virt/libvirt/config.py#L1146-L1153\u003e`_."},{"line_number":48,"context_line":"Nova deployments use the Libvirt default vTPM state path. On both Ubuntu and"},{"line_number":49,"context_line":"Red Hat operating sytems, this path is ``/var/lib/libvirt/swtpm/\u003cinstance"},{"line_number":50,"context_line":"UUID\u003e``. This path is distinct from the instance state path and can be expected"},{"line_number":51,"context_line":"to never be on shared storage."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"Thus, this spec leaves shared storage vTPM live migration out of its scope, and"},{"line_number":54,"context_line":"assumes Libvirt will copy the vTPM state during the live migration."}],"source_content_type":"text/x-rst","patch_set":5,"id":"c7cbf241_f3b3f22f","line":51,"range":{"start_line":50,"start_character":9,"end_line":51,"end_character":30},"in_reply_to":"c1d65a38_c4c64251","updated":"2024-12-20 22:21:32.000000000","message":"I\u0027ll add a blurb to the documentation section to make sure we include this assumption.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"cf7fac0a51df8a0fd2545da861eabd9526006d6d","unresolved":false,"context_lines":[{"line_number":47,"context_line":"\u003chttps://opendev.org/openstack/nova/src/commit/c79bec0f2257967da1dcccc9f562253d6ede535d/nova/virt/libvirt/config.py#L1146-L1153\u003e`_."},{"line_number":48,"context_line":"Nova deployments use the Libvirt default vTPM state path. On both Ubuntu and"},{"line_number":49,"context_line":"Red Hat operating sytems, this path is ``/var/lib/libvirt/swtpm/\u003cinstance"},{"line_number":50,"context_line":"UUID\u003e``. This path is distinct from the instance state path and can be expected"},{"line_number":51,"context_line":"to never be on shared storage."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"Thus, this spec leaves shared storage vTPM live migration out of its scope, and"},{"line_number":54,"context_line":"assumes Libvirt will copy the vTPM state during the live migration."}],"source_content_type":"text/x-rst","patch_set":5,"id":"a4941fee_c0a85f0d","line":51,"range":{"start_line":50,"start_character":9,"end_line":51,"end_character":30},"in_reply_to":"c7cbf241_f3b3f22f","updated":"2025-01-07 14:22:19.000000000","message":"Done","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"aaf8a8a6eac6124f735263b4ba3656d12619b1f1","unresolved":true,"context_lines":[{"line_number":51,"context_line":"to never be on shared storage."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"Thus, this spec leaves shared storage vTPM live migration out of its scope, and"},{"line_number":54,"context_line":"assumes Libvirt will copy the vTPM state during the live migration."},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"Libvirt support"},{"line_number":57,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"a1381019_695f8654","line":54,"updated":"2024-12-10 15:50:15.000000000","message":"What will happen if the vTPM storage shared, will that corrupt the vTPM state? If so then we need to be very loud in our documentation that do not try to live migrate if the vTPM is shared.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"f067fb8042d1ac33ee88a35fd8608e018c68911a","unresolved":true,"context_lines":[{"line_number":51,"context_line":"to never be on shared storage."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"Thus, this spec leaves shared storage vTPM live migration out of its scope, and"},{"line_number":54,"context_line":"assumes Libvirt will copy the vTPM state during the live migration."},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"Libvirt support"},{"line_number":57,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"db1a1227_cb0fe875","line":54,"in_reply_to":"1baa20f6_d18d1ecb","updated":"2024-12-20 22:21:32.000000000","message":"So, I _think_ libvirt will just do the correct thing, namely pass --migration to swtpm (https://www.libvirt.org/news.html#v8-10-0-2022-12-01) if the state storage is shared? That being said, unless we want to invest effort into making devstack deploy a shared vTPM state storage environment to specifically test this one case, I think we can leave it out of scope and be really clear that it\u0027s untested in our docs.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"7a8ea6322b2e4ae2ea0040a7515d5382ab22b2ed","unresolved":false,"context_lines":[{"line_number":51,"context_line":"to never be on shared storage."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"Thus, this spec leaves shared storage vTPM live migration out of its scope, and"},{"line_number":54,"context_line":"assumes Libvirt will copy the vTPM state during the live migration."},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"Libvirt support"},{"line_number":57,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"961a677d_c00c260f","line":54,"in_reply_to":"2c085b03_149f41ee","updated":"2025-01-09 18:04:38.000000000","message":"Done","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"2a535b5f38d0cd02c13961c03fb34084dbe80280","unresolved":true,"context_lines":[{"line_number":51,"context_line":"to never be on shared storage."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"Thus, this spec leaves shared storage vTPM live migration out of its scope, and"},{"line_number":54,"context_line":"assumes Libvirt will copy the vTPM state during the live migration."},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"Libvirt support"},{"line_number":57,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1baa20f6_d18d1ecb","line":54,"in_reply_to":"a1381019_695f8654","updated":"2024-12-13 04:06:17.000000000","message":"If it is shared, I wonder could we not just reuse the existing \"is shared storage\" logic to skip copying for that case to avoid issues? Or would that somehow not work right for the vTPM..","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"cf7fac0a51df8a0fd2545da861eabd9526006d6d","unresolved":true,"context_lines":[{"line_number":51,"context_line":"to never be on shared storage."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"Thus, this spec leaves shared storage vTPM live migration out of its scope, and"},{"line_number":54,"context_line":"assumes Libvirt will copy the vTPM state during the live migration."},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"Libvirt support"},{"line_number":57,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"2c085b03_149f41ee","line":54,"in_reply_to":"db1a1227_cb0fe875","updated":"2025-01-07 14:22:19.000000000","message":"Yeah, I\u0027m OK to be explicit that this is not tested and not supported (and unknown if it works or not) in our doc and keep the scope limited.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"aaf8a8a6eac6124f735263b4ba3656d12619b1f1","unresolved":true,"context_lines":[{"line_number":56,"context_line":"Libvirt support"},{"line_number":57,"context_line":"---------------"},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"Though it was impossible to find Libvirt artifacts explicitly demonstrating"},{"line_number":60,"context_line":"vTPM live migration support for non-shared storage, as of `version 8.10"},{"line_number":61,"context_line":"\u003chttps://www.libvirt.org/news.html#v8-10-0-2022-12-01\u003e`_, vTPM live migration on"},{"line_number":62,"context_line":"shared storage is supported, and `this comment"},{"line_number":63,"context_line":"\u003chttps://github.com/stefanberger/swtpm/issues/525#issuecomment-914542936\u003e`_"},{"line_number":64,"context_line":"suggests that for non-shared storage, vTPM live migration has been supported"},{"line_number":65,"context_line":"since version 7.1.0."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"Therefore, this spec requires Libvirt 7.1.0."},{"line_number":68,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"378d2bad_b56062b2","line":65,"range":{"start_line":59,"start_character":0,"end_line":65,"end_character":20},"updated":"2024-12-10 15:50:15.000000000","message":"here shared storage means the instance state on shared storage not the vtpm on shared storage, right?","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"2a535b5f38d0cd02c13961c03fb34084dbe80280","unresolved":true,"context_lines":[{"line_number":56,"context_line":"Libvirt support"},{"line_number":57,"context_line":"---------------"},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"Though it was impossible to find Libvirt artifacts explicitly demonstrating"},{"line_number":60,"context_line":"vTPM live migration support for non-shared storage, as of `version 8.10"},{"line_number":61,"context_line":"\u003chttps://www.libvirt.org/news.html#v8-10-0-2022-12-01\u003e`_, vTPM live migration on"},{"line_number":62,"context_line":"shared storage is supported, and `this comment"},{"line_number":63,"context_line":"\u003chttps://github.com/stefanberger/swtpm/issues/525#issuecomment-914542936\u003e`_"},{"line_number":64,"context_line":"suggests that for non-shared storage, vTPM live migration has been supported"},{"line_number":65,"context_line":"since version 7.1.0."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"Therefore, this spec requires Libvirt 7.1.0."},{"line_number":68,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"d91774ff_59f1e4e0","line":65,"range":{"start_line":59,"start_character":0,"end_line":65,"end_character":20},"in_reply_to":"378d2bad_b56062b2","updated":"2024-12-13 04:06:17.000000000","message":"I assumed this also, so clarification would be good.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"7a8ea6322b2e4ae2ea0040a7515d5382ab22b2ed","unresolved":false,"context_lines":[{"line_number":56,"context_line":"Libvirt support"},{"line_number":57,"context_line":"---------------"},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"Though it was impossible to find Libvirt artifacts explicitly demonstrating"},{"line_number":60,"context_line":"vTPM live migration support for non-shared storage, as of `version 8.10"},{"line_number":61,"context_line":"\u003chttps://www.libvirt.org/news.html#v8-10-0-2022-12-01\u003e`_, vTPM live migration on"},{"line_number":62,"context_line":"shared storage is supported, and `this comment"},{"line_number":63,"context_line":"\u003chttps://github.com/stefanberger/swtpm/issues/525#issuecomment-914542936\u003e`_"},{"line_number":64,"context_line":"suggests that for non-shared storage, vTPM live migration has been supported"},{"line_number":65,"context_line":"since version 7.1.0."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"Therefore, this spec requires Libvirt 7.1.0."},{"line_number":68,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ddfbb32_ec6dec42","line":65,"range":{"start_line":59,"start_character":0,"end_line":65,"end_character":20},"in_reply_to":"5106373a_699044a5","updated":"2025-01-09 18:04:38.000000000","message":"Done","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"f067fb8042d1ac33ee88a35fd8608e018c68911a","unresolved":true,"context_lines":[{"line_number":56,"context_line":"Libvirt support"},{"line_number":57,"context_line":"---------------"},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"Though it was impossible to find Libvirt artifacts explicitly demonstrating"},{"line_number":60,"context_line":"vTPM live migration support for non-shared storage, as of `version 8.10"},{"line_number":61,"context_line":"\u003chttps://www.libvirt.org/news.html#v8-10-0-2022-12-01\u003e`_, vTPM live migration on"},{"line_number":62,"context_line":"shared storage is supported, and `this comment"},{"line_number":63,"context_line":"\u003chttps://github.com/stefanberger/swtpm/issues/525#issuecomment-914542936\u003e`_"},{"line_number":64,"context_line":"suggests that for non-shared storage, vTPM live migration has been supported"},{"line_number":65,"context_line":"since version 7.1.0."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"Therefore, this spec requires Libvirt 7.1.0."},{"line_number":68,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"feb97ee9_10cb7c94","line":65,"range":{"start_line":59,"start_character":0,"end_line":65,"end_character":20},"in_reply_to":"d91774ff_59f1e4e0","updated":"2024-12-20 22:21:32.000000000","message":"No, this is specifically talking about vTPM state storage. I thought I was being clear with the previous paragraph, clearly I was mistaken :) Instance state storage is irrelevant.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"cf7fac0a51df8a0fd2545da861eabd9526006d6d","unresolved":true,"context_lines":[{"line_number":56,"context_line":"Libvirt support"},{"line_number":57,"context_line":"---------------"},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"Though it was impossible to find Libvirt artifacts explicitly demonstrating"},{"line_number":60,"context_line":"vTPM live migration support for non-shared storage, as of `version 8.10"},{"line_number":61,"context_line":"\u003chttps://www.libvirt.org/news.html#v8-10-0-2022-12-01\u003e`_, vTPM live migration on"},{"line_number":62,"context_line":"shared storage is supported, and `this comment"},{"line_number":63,"context_line":"\u003chttps://github.com/stefanberger/swtpm/issues/525#issuecomment-914542936\u003e`_"},{"line_number":64,"context_line":"suggests that for non-shared storage, vTPM live migration has been supported"},{"line_number":65,"context_line":"since version 7.1.0."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"Therefore, this spec requires Libvirt 7.1.0."},{"line_number":68,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"5106373a_699044a5","line":65,"range":{"start_line":59,"start_character":0,"end_line":65,"end_character":20},"in_reply_to":"feb97ee9_10cb7c94","updated":"2025-01-07 14:22:19.000000000","message":"thanks for the clarification","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a337a2caf06f24d6d842ffd012a6c8280b9ccfd4","unresolved":true,"context_lines":[{"line_number":80,"context_line":"once the Libvirt domain spawns successfully."},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"For vTPM live migration to work, the vTPM secret needs to be defined on the"},{"line_number":83,"context_line":"destination host so that Libvirt can decrypt the vTPM state.  To define it,"},{"line_number":84,"context_line":"Nova would need to retrieve it from Barbican. A live migration is an admin"},{"line_number":85,"context_line":"operation, so Nova would attempt the retrieval with either admin\u0027s token, or"},{"line_number":86,"context_line":"Nova\u0027s service token. Since the vTPM secret is owned by the user and is not"}],"source_content_type":"text/x-rst","patch_set":5,"id":"fcff9b12_be5ee529","line":83,"range":{"start_line":83,"start_character":0,"end_line":83,"end_character":16},"updated":"2024-12-09 19:48:58.000000000","message":"does it need to be on the dest or both. i guess qemu on the souce still has the key in memory so the reaon you say on the dest is so that the dest qemu will also have the encyuption key correct?","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"7a8ea6322b2e4ae2ea0040a7515d5382ab22b2ed","unresolved":false,"context_lines":[{"line_number":80,"context_line":"once the Libvirt domain spawns successfully."},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"For vTPM live migration to work, the vTPM secret needs to be defined on the"},{"line_number":83,"context_line":"destination host so that Libvirt can decrypt the vTPM state.  To define it,"},{"line_number":84,"context_line":"Nova would need to retrieve it from Barbican. A live migration is an admin"},{"line_number":85,"context_line":"operation, so Nova would attempt the retrieval with either admin\u0027s token, or"},{"line_number":86,"context_line":"Nova\u0027s service token. Since the vTPM secret is owned by the user and is not"}],"source_content_type":"text/x-rst","patch_set":5,"id":"a2692339_e6ed55d7","line":83,"range":{"start_line":83,"start_character":0,"end_line":83,"end_character":16},"in_reply_to":"cae558ad_cb103c7c","updated":"2025-01-09 18:04:38.000000000","message":"Done","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"f067fb8042d1ac33ee88a35fd8608e018c68911a","unresolved":true,"context_lines":[{"line_number":80,"context_line":"once the Libvirt domain spawns successfully."},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"For vTPM live migration to work, the vTPM secret needs to be defined on the"},{"line_number":83,"context_line":"destination host so that Libvirt can decrypt the vTPM state.  To define it,"},{"line_number":84,"context_line":"Nova would need to retrieve it from Barbican. A live migration is an admin"},{"line_number":85,"context_line":"operation, so Nova would attempt the retrieval with either admin\u0027s token, or"},{"line_number":86,"context_line":"Nova\u0027s service token. Since the vTPM secret is owned by the user and is not"}],"source_content_type":"text/x-rst","patch_set":5,"id":"cae558ad_cb103c7c","line":83,"range":{"start_line":83,"start_character":0,"end_line":83,"end_character":16},"in_reply_to":"fcff9b12_be5ee529","updated":"2024-12-20 22:21:32.000000000","message":"Both - the XML references it, so it needs to have the same UUID and value on source and dest.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a337a2caf06f24d6d842ffd012a6c8280b9ccfd4","unresolved":true,"context_lines":[{"line_number":82,"context_line":"For vTPM live migration to work, the vTPM secret needs to be defined on the"},{"line_number":83,"context_line":"destination host so that Libvirt can decrypt the vTPM state.  To define it,"},{"line_number":84,"context_line":"Nova would need to retrieve it from Barbican. A live migration is an admin"},{"line_number":85,"context_line":"operation, so Nova would attempt the retrieval with either admin\u0027s token, or"},{"line_number":86,"context_line":"Nova\u0027s service token. Since the vTPM secret is owned by the user and is not"},{"line_number":87,"context_line":"readable by anyone else, such a retrieval would be forbidden."},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"For privacy and transparency reasons, granting access to the vTPM secret to the"}],"source_content_type":"text/x-rst","patch_set":5,"id":"a43b434f_4dacd1f3","line":86,"range":{"start_line":85,"start_character":11,"end_line":86,"end_character":20},"updated":"2024-12-09 19:48:58.000000000","message":"ideally we woudl do this in a signle request which is the user token (in this case the admin user) + a service token header.\nbut if we need to do this with two reuqest wehre we use the service token as an admin token that might be ok\n\ni feel like we shoudl avoid the inital query with the admin users token if we expect that to never work using default policy however and alwasy just call using the nova serivce creds from our config.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"7a8ea6322b2e4ae2ea0040a7515d5382ab22b2ed","unresolved":false,"context_lines":[{"line_number":82,"context_line":"For vTPM live migration to work, the vTPM secret needs to be defined on the"},{"line_number":83,"context_line":"destination host so that Libvirt can decrypt the vTPM state.  To define it,"},{"line_number":84,"context_line":"Nova would need to retrieve it from Barbican. A live migration is an admin"},{"line_number":85,"context_line":"operation, so Nova would attempt the retrieval with either admin\u0027s token, or"},{"line_number":86,"context_line":"Nova\u0027s service token. Since the vTPM secret is owned by the user and is not"},{"line_number":87,"context_line":"readable by anyone else, such a retrieval would be forbidden."},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"For privacy and transparency reasons, granting access to the vTPM secret to the"}],"source_content_type":"text/x-rst","patch_set":5,"id":"482acb9a_9aabf8e5","line":86,"range":{"start_line":85,"start_character":11,"end_line":86,"end_character":20},"in_reply_to":"18f29940_5654712e","updated":"2025-01-09 18:04:38.000000000","message":"Done","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"f067fb8042d1ac33ee88a35fd8608e018c68911a","unresolved":true,"context_lines":[{"line_number":82,"context_line":"For vTPM live migration to work, the vTPM secret needs to be defined on the"},{"line_number":83,"context_line":"destination host so that Libvirt can decrypt the vTPM state.  To define it,"},{"line_number":84,"context_line":"Nova would need to retrieve it from Barbican. A live migration is an admin"},{"line_number":85,"context_line":"operation, so Nova would attempt the retrieval with either admin\u0027s token, or"},{"line_number":86,"context_line":"Nova\u0027s service token. Since the vTPM secret is owned by the user and is not"},{"line_number":87,"context_line":"readable by anyone else, such a retrieval would be forbidden."},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"For privacy and transparency reasons, granting access to the vTPM secret to the"}],"source_content_type":"text/x-rst","patch_set":5,"id":"18f29940_5654712e","line":86,"range":{"start_line":85,"start_character":11,"end_line":86,"end_character":20},"in_reply_to":"a43b434f_4dacd1f3","updated":"2024-12-20 22:21:32.000000000","message":"I meant either or, not try one then fall back on the other. I can clarify.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a337a2caf06f24d6d842ffd012a6c8280b9ccfd4","unresolved":true,"context_lines":[{"line_number":89,"context_line":"For privacy and transparency reasons, granting access to the vTPM secret to the"},{"line_number":90,"context_line":"Nova service user for the purposes of live migration should be something the"},{"line_number":91,"context_line":"user does with full knowledge and consent. It cannot be something done by Nova"},{"line_number":92,"context_line":"silently. This spec proposes a flavor extra spec and image property - the"},{"line_number":93,"context_line":"proposed key:value is ``secret_access\u003dnova`` - that can be knowingly opted"},{"line_number":94,"context_line":"into or set on an image by the user. This piece of metadata tells Nova that,"},{"line_number":95,"context_line":"when creating the secret in Barbican, an `ACL"}],"source_content_type":"text/x-rst","patch_set":5,"id":"2efa3605_9a521f64","line":92,"updated":"2024-12-09 19:48:58.000000000","message":"i would argue it totablly coudl be something done by nova silenetly but we woudl need to document that in our api either way. its a design choice we get to make as part of our api contect but it obvilsly has an upgrade impact if we stated doing that in exisitng installs.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e492b65407fd0e2cb5fc09aed07329d82acd801d","unresolved":true,"context_lines":[{"line_number":89,"context_line":"For privacy and transparency reasons, granting access to the vTPM secret to the"},{"line_number":90,"context_line":"Nova service user for the purposes of live migration should be something the"},{"line_number":91,"context_line":"user does with full knowledge and consent. It cannot be something done by Nova"},{"line_number":92,"context_line":"silently. This spec proposes a flavor extra spec and image property - the"},{"line_number":93,"context_line":"proposed key:value is ``secret_access\u003dnova`` - that can be knowingly opted"},{"line_number":94,"context_line":"into or set on an image by the user. This piece of metadata tells Nova that,"},{"line_number":95,"context_line":"when creating the secret in Barbican, an `ACL"}],"source_content_type":"text/x-rst","patch_set":5,"id":"b20d9dc1_1cd968cc","line":92,"in_reply_to":"1e6fce61_a7b2d2d7","updated":"2024-12-10 17:40:21.000000000","message":"oh im aware im just pointing out we had the option to choose who owned the secret when we first added vtpm support.\n\nnow that its released and in the wiled we dont really have the option so say the encyption key is nova internal state.\n\nit would have been a valid security paradigm initially but not now.\n\nits incorrect to imply that the only valid way was for the user\u0027s project to own the key. because of hte upgrade impact however that is the only vaild option now.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"aaf8a8a6eac6124f735263b4ba3656d12619b1f1","unresolved":true,"context_lines":[{"line_number":89,"context_line":"For privacy and transparency reasons, granting access to the vTPM secret to the"},{"line_number":90,"context_line":"Nova service user for the purposes of live migration should be something the"},{"line_number":91,"context_line":"user does with full knowledge and consent. It cannot be something done by Nova"},{"line_number":92,"context_line":"silently. This spec proposes a flavor extra spec and image property - the"},{"line_number":93,"context_line":"proposed key:value is ``secret_access\u003dnova`` - that can be knowingly opted"},{"line_number":94,"context_line":"into or set on an image by the user. This piece of metadata tells Nova that,"},{"line_number":95,"context_line":"when creating the secret in Barbican, an `ACL"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1e6fce61_a7b2d2d7","line":92,"in_reply_to":"2efa3605_9a521f64","updated":"2024-12-10 15:50:15.000000000","message":"There is a very good reason that barbican restricts the secret access to the user only. So nova should not arbitrarily circumvent such protection without the user\u0027s consent. There might be cases where it is better for the user to get their VM stopped in a hypervisor maintenance scenario than to get it live migrated by the admin, if this means that the admin suddenly has an unrestricted access to the content of the vTPM and therefore the content of the bitlocked windows drive.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"377dc653c8b3537cc4dacbf61d52a542bf4e8016","unresolved":true,"context_lines":[{"line_number":89,"context_line":"For privacy and transparency reasons, granting access to the vTPM secret to the"},{"line_number":90,"context_line":"Nova service user for the purposes of live migration should be something the"},{"line_number":91,"context_line":"user does with full knowledge and consent. It cannot be something done by Nova"},{"line_number":92,"context_line":"silently. This spec proposes a flavor extra spec and image property - the"},{"line_number":93,"context_line":"proposed key:value is ``secret_access\u003dnova`` - that can be knowingly opted"},{"line_number":94,"context_line":"into or set on an image by the user. This piece of metadata tells Nova that,"},{"line_number":95,"context_line":"when creating the secret in Barbican, an `ACL"}],"source_content_type":"text/x-rst","patch_set":5,"id":"e78ae870_89cdec85","line":92,"in_reply_to":"b20d9dc1_1cd968cc","updated":"2024-12-13 10:05:51.000000000","message":"I still strongly believe that our past decision to create the key as the user not as nova was the right decision to make.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"7a8ea6322b2e4ae2ea0040a7515d5382ab22b2ed","unresolved":false,"context_lines":[{"line_number":89,"context_line":"For privacy and transparency reasons, granting access to the vTPM secret to the"},{"line_number":90,"context_line":"Nova service user for the purposes of live migration should be something the"},{"line_number":91,"context_line":"user does with full knowledge and consent. It cannot be something done by Nova"},{"line_number":92,"context_line":"silently. This spec proposes a flavor extra spec and image property - the"},{"line_number":93,"context_line":"proposed key:value is ``secret_access\u003dnova`` - that can be knowingly opted"},{"line_number":94,"context_line":"into or set on an image by the user. This piece of metadata tells Nova that,"},{"line_number":95,"context_line":"when creating the secret in Barbican, an `ACL"}],"source_content_type":"text/x-rst","patch_set":5,"id":"d2d1ba65_c129b4cf","line":92,"in_reply_to":"e78ae870_89cdec85","updated":"2025-01-09 18:04:38.000000000","message":"Done","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a337a2caf06f24d6d842ffd012a6c8280b9ccfd4","unresolved":true,"context_lines":[{"line_number":91,"context_line":"user does with full knowledge and consent. It cannot be something done by Nova"},{"line_number":92,"context_line":"silently. This spec proposes a flavor extra spec and image property - the"},{"line_number":93,"context_line":"proposed key:value is ``secret_access\u003dnova`` - that can be knowingly opted"},{"line_number":94,"context_line":"into or set on an image by the user. This piece of metadata tells Nova that,"},{"line_number":95,"context_line":"when creating the secret in Barbican, an `ACL"},{"line_number":96,"context_line":"\u003chttps://docs.openstack.org/barbican/latest/api/reference/acls.html#patch-v1-secrets-uuid-acl\u003e`_"},{"line_number":97,"context_line":"should be added to grant the Nova service user read access. Secret creation"}],"source_content_type":"text/x-rst","patch_set":5,"id":"255db1b3_7d40d11c","line":94,"updated":"2024-12-09 19:48:58.000000000","message":"usign a flavor/image property for this i think is ok\n\nthis obviously has upgrade implication as it requires the admin to defien new flavor, the user to resize to them and new images to be defiend.\n\nso we may want to consider a `nova-mange flavor sync` command or similr to allow updating the embeded flavor form the current api defintion to easy that impact.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"d4be66605e411336c9583ceaffbbe2bbf57a4f8c","unresolved":true,"context_lines":[{"line_number":91,"context_line":"user does with full knowledge and consent. It cannot be something done by Nova"},{"line_number":92,"context_line":"silently. This spec proposes a flavor extra spec and image property - the"},{"line_number":93,"context_line":"proposed key:value is ``secret_access\u003dnova`` - that can be knowingly opted"},{"line_number":94,"context_line":"into or set on an image by the user. This piece of metadata tells Nova that,"},{"line_number":95,"context_line":"when creating the secret in Barbican, an `ACL"},{"line_number":96,"context_line":"\u003chttps://docs.openstack.org/barbican/latest/api/reference/acls.html#patch-v1-secrets-uuid-acl\u003e`_"},{"line_number":97,"context_line":"should be added to grant the Nova service user read access. Secret creation"}],"source_content_type":"text/x-rst","patch_set":5,"id":"8f6ef96d_99f6265a","line":94,"in_reply_to":"24d66d8d_616dbc81","updated":"2025-01-06 20:13:36.000000000","message":"\u003e TBH, I don\u0027t really understand the concern about whether or not the user has opted into this. The user doesn\u0027t opt into being able to be live migrated at all, nor do they have any control over whether we even use a secure channel to send their unencrypted memory contents over the network. The option you\u0027re providing to the user is basically \"do you want the admins to be able to move your instance if they need to, or would you rather them delete it?\" which seems a bit weird to me.\n\nMy interpretation is that the concern is about admin or service user Barbican secret access -- keyword being Barbican. IMHO because secret access is user-scoped, we don\u0027t want to be auto-granting decryption access to other Keystone users which includes admin user and service user. Service user is not *as* concerning as admin user IMHO because service means Nova the system, however I think it\u0027s fair to consider the possibility of someone (or an attacker) compromising the Nova service user password and then if so they will be able to decrypt all users Barbican secrets. So I think it\u0027s best to avoid that if possible and especially avoid it without user awareness what they are getting into.\n\n\u003e If we were to use the \"define it in libvirt and let libvirt move it\" approach, would we feel that the user needs to opt into that behavior as well?\n\nIMHO this is different and is something I would be comfortable with as it doesn\u0027t involve granting any Barbican secret API access to other users.\n\n\u003e TBH, defining it in libvirt so that we can just manually copy it without barbican seems the most admin-friendly to me and I don\u0027t think it really changes the trust model that much. Can someone articulate the attack vector they\u0027re concerned about? About the only one I can think of is someone physically steals a computer from a datacenter that doesn\u0027t have its own disk encrypted and then are able to start up the VMs that are left. Is that really worth the hassle we\u0027re putting on this process?\n\nI agree that this idea is in line with the trust model and IMHO is the only reasonable way mentioned so far to provide a seamless experience for the VM to be able to be live migrated by admin, which I acknowledge is a normal thing that users don\u0027t opt into. If libvirt could handle all of it automatically that would be the ideal but since it can\u0027t currently, I think copying it over SSH would be reasonable.\n\n\u003e But the question here is about the system being able to move the instance, on behalf of an admin, and thus be able to read the key right? So an API admin being allowed to push a migration is desirable. They don\u0027t need to be able to read the key directly if the service user can on their behalf, or if nova itself can on their behalf because it\u0027s stored in libvirt. Neither of those things are violations of user confidentiality requiring opt-in, IMHO.\n\nI agree API admin being allowed to push a migration is desirable. I disagree that the service user having decrypt permission to the user\u0027s secret in the Barbican API is on par with Nova itself copying the secret stored in libvirt. IMHO we should avoid doing the former in any invisible type of way -- if we want to do that it should be an installer configuration or Nova configuration that is plainly seen. The latter I think would be a reasonable thing for Nova to do automatically.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"aaf8a8a6eac6124f735263b4ba3656d12619b1f1","unresolved":true,"context_lines":[{"line_number":91,"context_line":"user does with full knowledge and consent. It cannot be something done by Nova"},{"line_number":92,"context_line":"silently. This spec proposes a flavor extra spec and image property - the"},{"line_number":93,"context_line":"proposed key:value is ``secret_access\u003dnova`` - that can be knowingly opted"},{"line_number":94,"context_line":"into or set on an image by the user. This piece of metadata tells Nova that,"},{"line_number":95,"context_line":"when creating the secret in Barbican, an `ACL"},{"line_number":96,"context_line":"\u003chttps://docs.openstack.org/barbican/latest/api/reference/acls.html#patch-v1-secrets-uuid-acl\u003e`_"},{"line_number":97,"context_line":"should be added to grant the Nova service user read access. Secret creation"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7ac240e8_1f0960c9","line":94,"in_reply_to":"255db1b3_7d40d11c","updated":"2024-12-10 15:50:15.000000000","message":"The consent should come from the user. For a new VM selecting an admin defined flavor with secret_access\u003dnova to opt in feels acceptable to me. Also using an image without secret_access\u003dnova with that flavor feels acceptable as the user saw the flavor they selected.\n\nBut having an admin CLI that generates that consent behind the users back is only acceptable for me if the generated change is visible to the user before the user decides to apply such administrative change. So the user can opt out of the admin initiated change by simply deleting the VM.\n\nThe second part seems to be OK as there is no way for nova to apply the effective ACL in barbican until the user sends its token to nova due to some lifecycle operation (i.e. reboot, resize, shelve/unshelve, etc.) \nSo if the CLI updates some flavors extra_specs embedded in the instance in a way that such change is visible to the user, then I can accept the CLI proposal.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"377dc653c8b3537cc4dacbf61d52a542bf4e8016","unresolved":true,"context_lines":[{"line_number":91,"context_line":"user does with full knowledge and consent. It cannot be something done by Nova"},{"line_number":92,"context_line":"silently. This spec proposes a flavor extra spec and image property - the"},{"line_number":93,"context_line":"proposed key:value is ``secret_access\u003dnova`` - that can be knowingly opted"},{"line_number":94,"context_line":"into or set on an image by the user. This piece of metadata tells Nova that,"},{"line_number":95,"context_line":"when creating the secret in Barbican, an `ACL"},{"line_number":96,"context_line":"\u003chttps://docs.openstack.org/barbican/latest/api/reference/acls.html#patch-v1-secrets-uuid-acl\u003e`_"},{"line_number":97,"context_line":"should be added to grant the Nova service user read access. Secret creation"}],"source_content_type":"text/x-rst","patch_set":5,"id":"456d013a_16ba8ec5","line":94,"in_reply_to":"30fd887a_1cb87b78","updated":"2024-12-13 10:05:51.000000000","message":"It is not just a protection against an actively hostile cloud admin. Obviously an admin with physical machine access there is not much safety guarantee. \n\nIt is a protection against exposing the encrypted data when the nova user/pass is compromised via the nova.conf file on a compromised compute host.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"f067fb8042d1ac33ee88a35fd8608e018c68911a","unresolved":true,"context_lines":[{"line_number":91,"context_line":"user does with full knowledge and consent. It cannot be something done by Nova"},{"line_number":92,"context_line":"silently. This spec proposes a flavor extra spec and image property - the"},{"line_number":93,"context_line":"proposed key:value is ``secret_access\u003dnova`` - that can be knowingly opted"},{"line_number":94,"context_line":"into or set on an image by the user. This piece of metadata tells Nova that,"},{"line_number":95,"context_line":"when creating the secret in Barbican, an `ACL"},{"line_number":96,"context_line":"\u003chttps://docs.openstack.org/barbican/latest/api/reference/acls.html#patch-v1-secrets-uuid-acl\u003e`_"},{"line_number":97,"context_line":"should be added to grant the Nova service user read access. Secret creation"}],"source_content_type":"text/x-rst","patch_set":5,"id":"e1bc1126_f23bee06","line":94,"in_reply_to":"456d013a_16ba8ec5","updated":"2024-12-20 22:21:32.000000000","message":"\u003e not that wether flavour extra specs are visible to normal users is configurable via policy and in the public cloud its often disabled.\n\nI think we have to assume default policy here. If we start branching off into potential custom policies, then half of this spec is pointless as the operator can just set custom Barbican policy to give everyone read access to all secrets.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"2a535b5f38d0cd02c13961c03fb34084dbe80280","unresolved":true,"context_lines":[{"line_number":91,"context_line":"user does with full knowledge and consent. It cannot be something done by Nova"},{"line_number":92,"context_line":"silently. This spec proposes a flavor extra spec and image property - the"},{"line_number":93,"context_line":"proposed key:value is ``secret_access\u003dnova`` - that can be knowingly opted"},{"line_number":94,"context_line":"into or set on an image by the user. This piece of metadata tells Nova that,"},{"line_number":95,"context_line":"when creating the secret in Barbican, an `ACL"},{"line_number":96,"context_line":"\u003chttps://docs.openstack.org/barbican/latest/api/reference/acls.html#patch-v1-secrets-uuid-acl\u003e`_"},{"line_number":97,"context_line":"should be added to grant the Nova service user read access. Secret creation"}],"source_content_type":"text/x-rst","patch_set":5,"id":"30fd887a_1cb87b78","line":94,"in_reply_to":"5772c79c_96e72123","updated":"2024-12-13 04:06:17.000000000","message":"Speaking from the perspective of local disk encryption, I also think auto syncing secret access without the user\u0027s consent is not cool... I don\u0027t think of it as hostile admin but rather there is user proprietary business data or their customer data in encrypted things and it\u0027s not supposed to be readable by a cloud admin. I\u0027m not sure how other clouds like AWS work but I think if something in my VM is encrypted, I expect no cloud user can read it but me.\n\nI do however expect operators would want a way to update existing VMs in bulk without going through any API actions 🫤 but ...\n\nIf we are going with the view that cloud admin should be trusted and able to read everything, then we can just instruct operators to modify their Barbican API policy to allow admin to read secrets (which is what I did for Tempest testing purposes) and everything will Just Work.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e492b65407fd0e2cb5fc09aed07329d82acd801d","unresolved":true,"context_lines":[{"line_number":91,"context_line":"user does with full knowledge and consent. It cannot be something done by Nova"},{"line_number":92,"context_line":"silently. This spec proposes a flavor extra spec and image property - the"},{"line_number":93,"context_line":"proposed key:value is ``secret_access\u003dnova`` - that can be knowingly opted"},{"line_number":94,"context_line":"into or set on an image by the user. This piece of metadata tells Nova that,"},{"line_number":95,"context_line":"when creating the secret in Barbican, an `ACL"},{"line_number":96,"context_line":"\u003chttps://docs.openstack.org/barbican/latest/api/reference/acls.html#patch-v1-secrets-uuid-acl\u003e`_"},{"line_number":97,"context_line":"should be added to grant the Nova service user read access. Secret creation"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5772c79c_96e72123","line":94,"in_reply_to":"7ac240e8_1f0960c9","updated":"2024-12-10 17:40:21.000000000","message":"well the cli is something opeators have asked for in teh past which is hwy i mentioned it.\n\nthe way nova-mange flavor sync would work is updating the current embedded flavor form the current definition in the API db so the side effect of that would be visible in the server show output to the end user.\n\nnot that wether flavour extra specs are visible to normal users is configurable via policy and in the public cloud its often disabled.\n\nbut the nova-mange command won\u0027t have the ability to grant the acl and would not try so without the user performing an action like hard reboot that would allow nova to grant the access the acl would not be created.\n\n\nas an aside if you don\u0027t trust the cloud admin you hosed anyway.\nthey can always override the Barbican policy or just go to its secret store and directly read the secret.\n\nso we can\u0027t fix that and should not try in this spec.\nwe have to assume that the admin is not hostile.\n\nif we assume a hostile admin we would need a different approach","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"47ce09ee6fe121aa42f497923c44ac5407351892","unresolved":true,"context_lines":[{"line_number":91,"context_line":"user does with full knowledge and consent. It cannot be something done by Nova"},{"line_number":92,"context_line":"silently. This spec proposes a flavor extra spec and image property - the"},{"line_number":93,"context_line":"proposed key:value is ``secret_access\u003dnova`` - that can be knowingly opted"},{"line_number":94,"context_line":"into or set on an image by the user. This piece of metadata tells Nova that,"},{"line_number":95,"context_line":"when creating the secret in Barbican, an `ACL"},{"line_number":96,"context_line":"\u003chttps://docs.openstack.org/barbican/latest/api/reference/acls.html#patch-v1-secrets-uuid-acl\u003e`_"},{"line_number":97,"context_line":"should be added to grant the Nova service user read access. Secret creation"}],"source_content_type":"text/x-rst","patch_set":5,"id":"f0925b28_280a4da5","line":94,"in_reply_to":"8f6ef96d_99f6265a","updated":"2025-01-06 21:00:56.000000000","message":"\u003e Service user is not *as* concerning as admin user IMHO because service means Nova the system, however I think it\u0027s fair to consider the possibility of someone (or an attacker) compromising the Nova service user password and then if so they will be able to decrypt all users Barbican secrets. So I think it\u0027s best to avoid that if possible and especially avoid it without user awareness what they are getting into.\n\nIf the service user is not an admin in barbican, then I understand that letting the service user read all the secrets of all the users is an increase in scope. However, if we get to the point of the service user being able to grant itself access for the purposes of the move, then I think it\u0027s *not* an increase.\n\nThat said, I will say that this secret is _not_ the user\u0027s secret, it\u0027s a secret we created for the user to encrypt something they can\u0027t see. If you get all those secrets *and* have access to all the TPM images, then you can get the user\u0027s secret(s).\n\nHaving the nova service user own the secret in the first place is not a reduced stop in terms of what can happen to the secrets if it is compromised, although it does mean that we get more usability without requiring the service user to be an admin.\n\n\u003e IMHO this is different and is something I would be comfortable with as it doesn\u0027t involve granting any Barbican secret API access to other users.\n\nThe benefit of storing it in libvirt is that if you compromise one host, you don\u0027t have access to anything other than that host. However, it does mean that the secret leaves the datacenter with a physical theft (which isn\u0027t the case with the service user being able to read the keys). It also practically means that if you get one host, you probably have the others as well, since nova can ssh passwordless-ly to the other hosts, and nova on those hosts can *also* read the keys (yes modulo what the ssh session is allowed to do).\n\n\u003e I agree that this idea is in line with the trust model and IMHO is the only reasonable way mentioned so far to provide a seamless experience for the VM to be able to be live migrated by admin, which I acknowledge is a normal thing that users don\u0027t opt into. If libvirt could handle all of it automatically that would be the ideal but since it can\u0027t currently, I think copying it over SSH would be reasonable.\n\nI think storing it in libvirt is not materially better than having all the secrets owned by the nova service user. I think both of them open the door for lateral movement at the expense of usability. I will say storing them in libvirt feels very much like \"the business of the hypervisor\" and thus more appropriate, although I think it\u0027s maybe more risk and less auditable.\n\n\u003e I agree API admin being allowed to push a migration is desirable. I disagree that the service user having decrypt permission to the user\u0027s secret in the Barbican API is on par with Nova itself copying the secret stored in libvirt. IMHO we should avoid doing the former in any invisible type of way -- if we want to do that it should be an installer configuration or Nova configuration that is plainly seen. The latter I think would be a reasonable thing for Nova to do automatically.\n\nWell, again I want to pedantically point out that it\u0027s not the user\u0027s secret. I don\u0027t think I understand the difference between the two that you see as so striking, Can you articulate it in terms of things that would be possible in one scenario without the other?\n\nEven though I think either option is better than nothing, I\u0027d point out that in your preferred libvirt-centric approach, secrets are spread all over the disks of hosts you\u0027re on, you\u0027ve been on where no cleanup has been done, and hosts you\u0027re migrating to. Access to those secrets are basically unchecked. In the service-user case, they\u0027re still only in barbican, access to them can be audit-logged on the barbican side for each use, from each host, and the tap can be turned off with a single command to limit further access if something happens.\n\nI\u0027m not really arguing for one over the other, I just think we should be clear about which is better (if one is) or at least, why we are picking one over the other.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"105312a2ffef247ea4b5d54f874141f29ac66f08","unresolved":true,"context_lines":[{"line_number":91,"context_line":"user does with full knowledge and consent. It cannot be something done by Nova"},{"line_number":92,"context_line":"silently. This spec proposes a flavor extra spec and image property - the"},{"line_number":93,"context_line":"proposed key:value is ``secret_access\u003dnova`` - that can be knowingly opted"},{"line_number":94,"context_line":"into or set on an image by the user. This piece of metadata tells Nova that,"},{"line_number":95,"context_line":"when creating the secret in Barbican, an `ACL"},{"line_number":96,"context_line":"\u003chttps://docs.openstack.org/barbican/latest/api/reference/acls.html#patch-v1-secrets-uuid-acl\u003e`_"},{"line_number":97,"context_line":"should be added to grant the Nova service user read access. Secret creation"}],"source_content_type":"text/x-rst","patch_set":5,"id":"24d66d8d_616dbc81","line":94,"in_reply_to":"b320d4c6_8748d869","updated":"2025-01-06 19:01:55.000000000","message":"But the question here is about the _system_ being able to move the instance, on behalf of an admin, and thus be able to read the key right? So an API admin being allowed to push a migration is desirable. They don\u0027t need to be able to read the key directly if the service user can on their behalf, or if nova itself can on their behalf because it\u0027s stored in libvirt. Neither of those things are violations of user confidentiality requiring opt-in, IMHO.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"382653408b93f5887579349627043a3850bb3ecf","unresolved":true,"context_lines":[{"line_number":91,"context_line":"user does with full knowledge and consent. It cannot be something done by Nova"},{"line_number":92,"context_line":"silently. This spec proposes a flavor extra spec and image property - the"},{"line_number":93,"context_line":"proposed key:value is ``secret_access\u003dnova`` - that can be knowingly opted"},{"line_number":94,"context_line":"into or set on an image by the user. This piece of metadata tells Nova that,"},{"line_number":95,"context_line":"when creating the secret in Barbican, an `ACL"},{"line_number":96,"context_line":"\u003chttps://docs.openstack.org/barbican/latest/api/reference/acls.html#patch-v1-secrets-uuid-acl\u003e`_"},{"line_number":97,"context_line":"should be added to grant the Nova service user read access. Secret creation"}],"source_content_type":"text/x-rst","patch_set":5,"id":"b320d4c6_8748d869","line":94,"in_reply_to":"ba21979b_fd64fc5c","updated":"2025-01-06 18:47:33.000000000","message":"I think there\u0027s a difference between admin live migration and admin access to vTPM secrets. The former doesn\u0027t break confidentiality, the latter does. While users can understand admins doing stuff on their instances to help maintenance/recovery, said \"stuff\" is limited to changed to the VM, not its contents. This is different than basically snooping on the VM\u0027s BitLocker-encrypted disk.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ec23316314f01a981e73ee16d26d16b3e7c07020","unresolved":true,"context_lines":[{"line_number":91,"context_line":"user does with full knowledge and consent. It cannot be something done by Nova"},{"line_number":92,"context_line":"silently. This spec proposes a flavor extra spec and image property - the"},{"line_number":93,"context_line":"proposed key:value is ``secret_access\u003dnova`` - that can be knowingly opted"},{"line_number":94,"context_line":"into or set on an image by the user. This piece of metadata tells Nova that,"},{"line_number":95,"context_line":"when creating the secret in Barbican, an `ACL"},{"line_number":96,"context_line":"\u003chttps://docs.openstack.org/barbican/latest/api/reference/acls.html#patch-v1-secrets-uuid-acl\u003e`_"},{"line_number":97,"context_line":"should be added to grant the Nova service user read access. Secret creation"}],"source_content_type":"text/x-rst","patch_set":5,"id":"ba21979b_fd64fc5c","line":94,"in_reply_to":"e1bc1126_f23bee06","updated":"2025-01-06 18:03:20.000000000","message":"TBH, I don\u0027t really understand the concern about whether or not the user has opted into this. The user doesn\u0027t opt into being able to be live migrated at all, nor do they have any control over whether we even use a secure channel to send their unencrypted memory contents over the network. The option you\u0027re providing to the user is basically \"do you want the admins to be able to move your instance if they need to, or would you rather them delete it?\" which seems a bit weird to me.\n\nIf we were to use the \"define it in libvirt and let libvirt move it\" approach, would we feel that the user needs to opt into that behavior as well?\n\nTBH, defining it in libvirt so that we can just manually copy it without barbican seems the most admin-friendly to me and I don\u0027t think it really changes the trust model that much. Can someone articulate the attack vector they\u0027re concerned about? About the only one I can think of is someone physically steals a computer from a datacenter that doesn\u0027t have its own disk encrypted and then are able to start up the VMs that are left. Is that really worth the hassle we\u0027re putting on this process?","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"7a8ea6322b2e4ae2ea0040a7515d5382ab22b2ed","unresolved":false,"context_lines":[{"line_number":91,"context_line":"user does with full knowledge and consent. It cannot be something done by Nova"},{"line_number":92,"context_line":"silently. This spec proposes a flavor extra spec and image property - the"},{"line_number":93,"context_line":"proposed key:value is ``secret_access\u003dnova`` - that can be knowingly opted"},{"line_number":94,"context_line":"into or set on an image by the user. This piece of metadata tells Nova that,"},{"line_number":95,"context_line":"when creating the secret in Barbican, an `ACL"},{"line_number":96,"context_line":"\u003chttps://docs.openstack.org/barbican/latest/api/reference/acls.html#patch-v1-secrets-uuid-acl\u003e`_"},{"line_number":97,"context_line":"should be added to grant the Nova service user read access. Secret creation"}],"source_content_type":"text/x-rst","patch_set":5,"id":"23ebd567_2c7a6e2d","line":94,"in_reply_to":"f0925b28_280a4da5","updated":"2025-01-09 18:04:38.000000000","message":"Done","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a337a2caf06f24d6d842ffd012a6c8280b9ccfd4","unresolved":true,"context_lines":[{"line_number":97,"context_line":"should be added to grant the Nova service user read access. Secret creation"},{"line_number":98,"context_line":"happens during the instance creation process using the user\u0027s token, so adding"},{"line_number":99,"context_line":"an ACL to the secret is possible with the same token."},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"Pre-existing instances"},{"line_number":102,"context_line":"----------------------"},{"line_number":103,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"6fa79141_a3b005a5","line":100,"updated":"2024-12-09 19:48:58.000000000","message":"ack i think form a mental model point of view this is the correct way to enable the addtional access to the secrete in a user visiable way.\n\n\nthe one thing i will say is the tpm data is never directly retirviabel by the user and could be consider hypervior internal state.\n\nit is aviabel to the end user via the vTPM in the guest which is why its not purly hypervior internal state but its one of the things that in a gray area.\n\nto me it woudl have been valid when we first addted this to have created the barbican secrte as the nova user not the end user but we dont really have that option now becuase of pre-exisitng istances.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ec23316314f01a981e73ee16d26d16b3e7c07020","unresolved":true,"context_lines":[{"line_number":97,"context_line":"should be added to grant the Nova service user read access. Secret creation"},{"line_number":98,"context_line":"happens during the instance creation process using the user\u0027s token, so adding"},{"line_number":99,"context_line":"an ACL to the secret is possible with the same token."},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"Pre-existing instances"},{"line_number":102,"context_line":"----------------------"},{"line_number":103,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"e166dcc3_d64841c7","line":100,"in_reply_to":"1e7df5ed_ffbec1c1","updated":"2025-01-06 18:03:20.000000000","message":"Right, I agree that the TPM is internal hypervisor state and to me, that means the user does not need to own the key. That also means to me that it would be fine to define the key in libvirt and use that copy to manually define it on the remote side (or have libvirt do it in the future). I think acting like the admin can\u0027t see the key if they want is a kind of theater that comes at the expense of admins. being able to admin things.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e492b65407fd0e2cb5fc09aed07329d82acd801d","unresolved":true,"context_lines":[{"line_number":97,"context_line":"should be added to grant the Nova service user read access. Secret creation"},{"line_number":98,"context_line":"happens during the instance creation process using the user\u0027s token, so adding"},{"line_number":99,"context_line":"an ACL to the secret is possible with the same token."},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"Pre-existing instances"},{"line_number":102,"context_line":"----------------------"},{"line_number":103,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"1e7df5ed_ffbec1c1","line":100,"in_reply_to":"6480e057_0ed4aa0b","updated":"2024-12-10 17:40:21.000000000","message":"yep that is the current trade-off.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"aaf8a8a6eac6124f735263b4ba3656d12619b1f1","unresolved":true,"context_lines":[{"line_number":97,"context_line":"should be added to grant the Nova service user read access. Secret creation"},{"line_number":98,"context_line":"happens during the instance creation process using the user\u0027s token, so adding"},{"line_number":99,"context_line":"an ACL to the secret is possible with the same token."},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"Pre-existing instances"},{"line_number":102,"context_line":"----------------------"},{"line_number":103,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"6480e057_0ed4aa0b","line":100,"in_reply_to":"6fa79141_a3b005a5","updated":"2024-12-10 15:50:15.000000000","message":"My problem with that is the data in the vTPM is used to decrypt the VM\u0027s disk. So giving access to this to the nova service user unconditionally is a privacy concern of the user storing sensitive files on the disk. So we need to formulate this as a trade off. Either the VM\u0027s vTPM is private and only decryptable by nova/libvirt when the user requests it by giving the user token to nova. Or the VM is live migratable by the admin.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"382653408b93f5887579349627043a3850bb3ecf","unresolved":true,"context_lines":[{"line_number":97,"context_line":"should be added to grant the Nova service user read access. Secret creation"},{"line_number":98,"context_line":"happens during the instance creation process using the user\u0027s token, so adding"},{"line_number":99,"context_line":"an ACL to the secret is possible with the same token."},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"Pre-existing instances"},{"line_number":102,"context_line":"----------------------"},{"line_number":103,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"14123d06_9d4509e1","line":100,"in_reply_to":"e166dcc3_d64841c7","updated":"2025-01-06 18:47:33.000000000","message":"Well, there are different levels of \"admin\", no? There\u0027s API-admin who can live migrate instances, there\u0027s infra-admin who can SSH to the compute hosts, and maybe there\u0027s a root-admin who has root on the compute hosts. You definitely can\u0027t do anything about the third, but allowing the user to hide confidential stuff from the first two seems sensible to me.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a337a2caf06f24d6d842ffd012a6c8280b9ccfd4","unresolved":true,"context_lines":[{"line_number":111,"context_line":"then perform any kind of instance operation that goes through the"},{"line_number":112,"context_line":"`_create_guest()"},{"line_number":113,"context_line":"\u003chttps://opendev.org/openstack/nova/src/commit/c79bec0f2257967da1dcccc9f562253d6ede535d/nova/virt/libvirt/driver.py#L8038-L8063\u003e`_"},{"line_number":114,"context_line":"code flow."},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"Operators too can set image properties (if they have access), or they can"},{"line_number":117,"context_line":"leverage the existing `nova-manage image_property set command"}],"source_content_type":"text/x-rst","patch_set":5,"id":"641f390f_01f8c081","line":114,"updated":"2024-12-09 19:48:58.000000000","message":"so this wont work\n\nwe create an embede copy of the image metadata in the instance_system_metadata able\n\nif the iamge is updated to ahve `secret_access\u003dnova` that will not take effect on any existing instance\n\n\nby the way we have a standing policy of not using the project names i.e. nova ciner ectra in image properties or extra specs\n\nthis would have to be `secret_access\u003dcompute`\n\nthe only way for a normal user to opt into this for an existing vm would be to resize or rebuild. the latter would destroy data so resizing is really the only option.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"aaf8a8a6eac6124f735263b4ba3656d12619b1f1","unresolved":true,"context_lines":[{"line_number":111,"context_line":"then perform any kind of instance operation that goes through the"},{"line_number":112,"context_line":"`_create_guest()"},{"line_number":113,"context_line":"\u003chttps://opendev.org/openstack/nova/src/commit/c79bec0f2257967da1dcccc9f562253d6ede535d/nova/virt/libvirt/driver.py#L8038-L8063\u003e`_"},{"line_number":114,"context_line":"code flow."},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"Operators too can set image properties (if they have access), or they can"},{"line_number":117,"context_line":"leverage the existing `nova-manage image_property set command"}],"source_content_type":"text/x-rst","patch_set":5,"id":"c6306b2b_a106b301","line":114,"in_reply_to":"641f390f_01f8c081","updated":"2024-12-10 15:50:15.000000000","message":"here \"nova\" might not mean the name of the component but the name of the keystone user that will get access to the user\u0027s token. However I think we allow to configure any username for the service user of nova. So we cannot simply use the name of the service user the value of this field :/","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"2a535b5f38d0cd02c13961c03fb34084dbe80280","unresolved":true,"context_lines":[{"line_number":111,"context_line":"then perform any kind of instance operation that goes through the"},{"line_number":112,"context_line":"`_create_guest()"},{"line_number":113,"context_line":"\u003chttps://opendev.org/openstack/nova/src/commit/c79bec0f2257967da1dcccc9f562253d6ede535d/nova/virt/libvirt/driver.py#L8038-L8063\u003e`_"},{"line_number":114,"context_line":"code flow."},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"Operators too can set image properties (if they have access), or they can"},{"line_number":117,"context_line":"leverage the existing `nova-manage image_property set command"}],"source_content_type":"text/x-rst","patch_set":5,"id":"ef84185e_644d3abf","line":114,"in_reply_to":"93ea9745_ac8d8deb","updated":"2024-12-13 04:06:17.000000000","message":"I think this may be referring to the `nova-manage image_property set` command if adding the secret_access to an existing VM. Because in that case it would work as described. (later) OK I see it says \"set on the image\" so nevermind I think it wasn\u0027t talking about nova-manage.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e492b65407fd0e2cb5fc09aed07329d82acd801d","unresolved":true,"context_lines":[{"line_number":111,"context_line":"then perform any kind of instance operation that goes through the"},{"line_number":112,"context_line":"`_create_guest()"},{"line_number":113,"context_line":"\u003chttps://opendev.org/openstack/nova/src/commit/c79bec0f2257967da1dcccc9f562253d6ede535d/nova/virt/libvirt/driver.py#L8038-L8063\u003e`_"},{"line_number":114,"context_line":"code flow."},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"Operators too can set image properties (if they have access), or they can"},{"line_number":117,"context_line":"leverage the existing `nova-manage image_property set command"}],"source_content_type":"text/x-rst","patch_set":5,"id":"93ea9745_ac8d8deb","line":114,"in_reply_to":"c6306b2b_a106b301","updated":"2024-12-10 17:40:21.000000000","message":"so this shoudl not be related to the user/project used by nova\n\nit can be any username/project in oru config\n\n\nhere i want this to be be the offical name of the nova software proejct wihc is the openstack compute service in our docs.\n\nhence secret_access\u003dcompute not secret_access\u003dnova.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"7a8ea6322b2e4ae2ea0040a7515d5382ab22b2ed","unresolved":false,"context_lines":[{"line_number":111,"context_line":"then perform any kind of instance operation that goes through the"},{"line_number":112,"context_line":"`_create_guest()"},{"line_number":113,"context_line":"\u003chttps://opendev.org/openstack/nova/src/commit/c79bec0f2257967da1dcccc9f562253d6ede535d/nova/virt/libvirt/driver.py#L8038-L8063\u003e`_"},{"line_number":114,"context_line":"code flow."},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"Operators too can set image properties (if they have access), or they can"},{"line_number":117,"context_line":"leverage the existing `nova-manage image_property set command"}],"source_content_type":"text/x-rst","patch_set":5,"id":"09fa2ada_3c8af1d2","line":114,"in_reply_to":"ef84185e_644d3abf","updated":"2025-01-09 18:04:38.000000000","message":"Done","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"aaf8a8a6eac6124f735263b4ba3656d12619b1f1","unresolved":true,"context_lines":[{"line_number":117,"context_line":"leverage the existing `nova-manage image_property set command"},{"line_number":118,"context_line":"\u003chttps://docs.openstack.org/nova/latest/cli/nova-manage.html#image-property-set\u003e`_."},{"line_number":119,"context_line":"This goes against the privacy and transparency argument made in the previous"},{"line_number":120,"context_line":"paragraphs, but this tooling already exists, and operators have a"},{"line_number":121,"context_line":"legitimate need to live migrate vTPM instances. What operators cannot do is"},{"line_number":122,"context_line":"perform an instance operation with the user\u0027s token. Thus, after an operator"},{"line_number":123,"context_line":"modifies an instance\u0027s image properties, the instance will be \"dirty\" and live"},{"line_number":124,"context_line":"migration will not work until the user performs an action on the instance with"}],"source_content_type":"text/x-rst","patch_set":5,"id":"85703785_78ca3b15","line":121,"range":{"start_line":120,"start_character":49,"end_line":121,"end_character":46},"updated":"2024-12-10 15:50:15.000000000","message":"operators can always simply shut down the VM that is not live migratable instead forcing the user to reveal the key for the vTPM.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"7a8ea6322b2e4ae2ea0040a7515d5382ab22b2ed","unresolved":false,"context_lines":[{"line_number":117,"context_line":"leverage the existing `nova-manage image_property set command"},{"line_number":118,"context_line":"\u003chttps://docs.openstack.org/nova/latest/cli/nova-manage.html#image-property-set\u003e`_."},{"line_number":119,"context_line":"This goes against the privacy and transparency argument made in the previous"},{"line_number":120,"context_line":"paragraphs, but this tooling already exists, and operators have a"},{"line_number":121,"context_line":"legitimate need to live migrate vTPM instances. What operators cannot do is"},{"line_number":122,"context_line":"perform an instance operation with the user\u0027s token. Thus, after an operator"},{"line_number":123,"context_line":"modifies an instance\u0027s image properties, the instance will be \"dirty\" and live"},{"line_number":124,"context_line":"migration will not work until the user performs an action on the instance with"}],"source_content_type":"text/x-rst","patch_set":5,"id":"0ebc79a4_4209818a","line":121,"range":{"start_line":120,"start_character":49,"end_line":121,"end_character":46},"in_reply_to":"24baeede_e5078674","updated":"2025-01-09 18:04:38.000000000","message":"Done","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e492b65407fd0e2cb5fc09aed07329d82acd801d","unresolved":true,"context_lines":[{"line_number":117,"context_line":"leverage the existing `nova-manage image_property set command"},{"line_number":118,"context_line":"\u003chttps://docs.openstack.org/nova/latest/cli/nova-manage.html#image-property-set\u003e`_."},{"line_number":119,"context_line":"This goes against the privacy and transparency argument made in the previous"},{"line_number":120,"context_line":"paragraphs, but this tooling already exists, and operators have a"},{"line_number":121,"context_line":"legitimate need to live migrate vTPM instances. What operators cannot do is"},{"line_number":122,"context_line":"perform an instance operation with the user\u0027s token. Thus, after an operator"},{"line_number":123,"context_line":"modifies an instance\u0027s image properties, the instance will be \"dirty\" and live"},{"line_number":124,"context_line":"migration will not work until the user performs an action on the instance with"}],"source_content_type":"text/x-rst","patch_set":5,"id":"24baeede_e5078674","line":121,"range":{"start_line":120,"start_character":49,"end_line":121,"end_character":46},"in_reply_to":"85703785_78ca3b15","updated":"2024-12-10 17:40:21.000000000","message":"they could cold migrate yes.\n\nmost move operations are not supprot but resize/cold migration is supprot\nhttps://docs.openstack.org/nova/latest/admin/emulated-tpm.html#limitations\n\nthe only caveat is that the admin cant start it again but that by design.\nit techinaly need to steps.\n\npower off as you said and then cold migrate so that nova does not try to start the vm as part fo verify resize.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"aaf8a8a6eac6124f735263b4ba3656d12619b1f1","unresolved":true,"context_lines":[{"line_number":119,"context_line":"This goes against the privacy and transparency argument made in the previous"},{"line_number":120,"context_line":"paragraphs, but this tooling already exists, and operators have a"},{"line_number":121,"context_line":"legitimate need to live migrate vTPM instances. What operators cannot do is"},{"line_number":122,"context_line":"perform an instance operation with the user\u0027s token. Thus, after an operator"},{"line_number":123,"context_line":"modifies an instance\u0027s image properties, the instance will be \"dirty\" and live"},{"line_number":124,"context_line":"migration will not work until the user performs an action on the instance with"},{"line_number":125,"context_line":"their token to allow Nova to set an ACL on the vTPM. There have been"},{"line_number":126,"context_line":"discussions around an `\"image↔instance \"converge\" feature"},{"line_number":127,"context_line":"\u003chttps://issues.redhat.com/browse/OSPRH-11252\u003e`_, but such work is outside the"},{"line_number":128,"context_line":"scope of this spec."}],"source_content_type":"text/x-rst","patch_set":5,"id":"d325a34a_f8282799","line":125,"range":{"start_line":122,"start_character":53,"end_line":125,"end_character":52},"updated":"2024-12-10 15:50:15.000000000","message":"I think this is actually what we want. So the user can still decide to allow the admin to read the vTPM secret or instead of that simply delete the VM and find another could provider with higher privacy.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"7a8ea6322b2e4ae2ea0040a7515d5382ab22b2ed","unresolved":false,"context_lines":[{"line_number":119,"context_line":"This goes against the privacy and transparency argument made in the previous"},{"line_number":120,"context_line":"paragraphs, but this tooling already exists, and operators have a"},{"line_number":121,"context_line":"legitimate need to live migrate vTPM instances. What operators cannot do is"},{"line_number":122,"context_line":"perform an instance operation with the user\u0027s token. Thus, after an operator"},{"line_number":123,"context_line":"modifies an instance\u0027s image properties, the instance will be \"dirty\" and live"},{"line_number":124,"context_line":"migration will not work until the user performs an action on the instance with"},{"line_number":125,"context_line":"their token to allow Nova to set an ACL on the vTPM. There have been"},{"line_number":126,"context_line":"discussions around an `\"image↔instance \"converge\" feature"},{"line_number":127,"context_line":"\u003chttps://issues.redhat.com/browse/OSPRH-11252\u003e`_, but such work is outside the"},{"line_number":128,"context_line":"scope of this spec."}],"source_content_type":"text/x-rst","patch_set":5,"id":"adb1ac62_da4998db","line":125,"range":{"start_line":122,"start_character":53,"end_line":125,"end_character":52},"in_reply_to":"aa936939_23846382","updated":"2025-01-09 18:04:38.000000000","message":"Done","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"f067fb8042d1ac33ee88a35fd8608e018c68911a","unresolved":true,"context_lines":[{"line_number":119,"context_line":"This goes against the privacy and transparency argument made in the previous"},{"line_number":120,"context_line":"paragraphs, but this tooling already exists, and operators have a"},{"line_number":121,"context_line":"legitimate need to live migrate vTPM instances. What operators cannot do is"},{"line_number":122,"context_line":"perform an instance operation with the user\u0027s token. Thus, after an operator"},{"line_number":123,"context_line":"modifies an instance\u0027s image properties, the instance will be \"dirty\" and live"},{"line_number":124,"context_line":"migration will not work until the user performs an action on the instance with"},{"line_number":125,"context_line":"their token to allow Nova to set an ACL on the vTPM. There have been"},{"line_number":126,"context_line":"discussions around an `\"image↔instance \"converge\" feature"},{"line_number":127,"context_line":"\u003chttps://issues.redhat.com/browse/OSPRH-11252\u003e`_, but such work is outside the"},{"line_number":128,"context_line":"scope of this spec."}],"source_content_type":"text/x-rst","patch_set":5,"id":"aa936939_23846382","line":125,"range":{"start_line":122,"start_character":53,"end_line":125,"end_character":52},"in_reply_to":"bf8bde7b_e45af6ed","updated":"2024-12-20 22:21:32.000000000","message":"\u003e I think this is actually what we want. So the user can still decide to allow the admin to read the vTPM secret or instead of that simply delete the VM and find another could provider with higher privacy.\n\nThat\u0027s a whole big separate thing that, while related to vTPM live migration, far out-scopes it. I almost want to say - _block_ `nova-manage image_property set` from setting `secret_access`, and it private clouds that don\u0027t care about secret privacy want to live migrate vTPM instances, we can document that they have to set custom Barbican policy","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e492b65407fd0e2cb5fc09aed07329d82acd801d","unresolved":true,"context_lines":[{"line_number":119,"context_line":"This goes against the privacy and transparency argument made in the previous"},{"line_number":120,"context_line":"paragraphs, but this tooling already exists, and operators have a"},{"line_number":121,"context_line":"legitimate need to live migrate vTPM instances. What operators cannot do is"},{"line_number":122,"context_line":"perform an instance operation with the user\u0027s token. Thus, after an operator"},{"line_number":123,"context_line":"modifies an instance\u0027s image properties, the instance will be \"dirty\" and live"},{"line_number":124,"context_line":"migration will not work until the user performs an action on the instance with"},{"line_number":125,"context_line":"their token to allow Nova to set an ACL on the vTPM. There have been"},{"line_number":126,"context_line":"discussions around an `\"image↔instance \"converge\" feature"},{"line_number":127,"context_line":"\u003chttps://issues.redhat.com/browse/OSPRH-11252\u003e`_, but such work is outside the"},{"line_number":128,"context_line":"scope of this spec."}],"source_content_type":"text/x-rst","patch_set":5,"id":"bf8bde7b_e45af6ed","line":125,"range":{"start_line":122,"start_character":53,"end_line":125,"end_character":52},"in_reply_to":"d325a34a_f8282799","updated":"2024-12-10 17:40:21.000000000","message":"we coudl also do this diffently.\n\nwe could make it so that nova will only ever add the acl on inial spaw or resize/rebuild to a falvor/image with it the approate proeprty set.\n\nfor exsint isntance we coudl document how a user woudl grant access to nova via the barbican api.\n\nmay main problem with that is they would have to know which project to grand access too for nova to retive the secret and that error prone.\n\n\nnova having logic to grant the acl on hard reboot feels like a bit of a hack to me.\n\nit would almost be better to have a new instance action to allow them to explicitly opt in or out if it\u0027s not part fo a resize or rebuild.\n\nadding a whole new instance action is pretty heavy weight for just that, however.\n\nso I keep coming back to should we do this for existing instances at all out side of resize or rebuild. I\u0027m leaning toward no but im unsure.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a337a2caf06f24d6d842ffd012a6c8280b9ccfd4","unresolved":true,"context_lines":[{"line_number":131,"context_line":"---------"},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"As a cloud operator, I want to be able to live migrate instances with vTPM"},{"line_number":134,"context_line":"devices, in particular Windows instances."},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"Proposed change"},{"line_number":137,"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":5,"id":"1c02176d_a095ced6","line":134,"updated":"2024-12-09 19:48:58.000000000","message":"as an aside windows i belive also uses the NVRAM variable store\n\nand currently nova is deleted the nvram file on many lifecycle operations\nhttps://review.opendev.org/c/openstack/nova/+/621646\n\nso we will need to fix that eventually too or it will eventulaly bite us.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"382653408b93f5887579349627043a3850bb3ecf","unresolved":true,"context_lines":[{"line_number":131,"context_line":"---------"},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"As a cloud operator, I want to be able to live migrate instances with vTPM"},{"line_number":134,"context_line":"devices, in particular Windows instances."},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"Proposed change"},{"line_number":137,"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":5,"id":"d643f3fd_547b92b4","line":134,"in_reply_to":"1ae6ff86_b868e1fa","updated":"2025-01-06 18:47:33.000000000","message":"I don\u0027t disagree that the NVRAM bug is important, but this spec is about vTPM live migration (with considerations for other operations that need to handle Barbican secrets), not \"overall Windows support\"","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ec23316314f01a981e73ee16d26d16b3e7c07020","unresolved":true,"context_lines":[{"line_number":131,"context_line":"---------"},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"As a cloud operator, I want to be able to live migrate instances with vTPM"},{"line_number":134,"context_line":"devices, in particular Windows instances."},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"Proposed change"},{"line_number":137,"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":5,"id":"1ae6ff86_b868e1fa","line":134,"in_reply_to":"1c02176d_a095ced6","updated":"2025-01-06 18:03:20.000000000","message":"Should we not roll that in here? I was thinking there was some secure boot requirement for the nvram as well, is there not? I guess maybe not if it\u0027s already deleted, but...","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d46d7072f7448bd30f917ba1f1b6d8afba11fa6c","unresolved":false,"context_lines":[{"line_number":131,"context_line":"---------"},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"As a cloud operator, I want to be able to live migrate instances with vTPM"},{"line_number":134,"context_line":"devices, in particular Windows instances."},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"Proposed change"},{"line_number":137,"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":5,"id":"7c4f9f71_e43b41b3","line":134,"in_reply_to":"d643f3fd_547b92b4","updated":"2025-01-09 17:58:31.000000000","message":"It\u0027s the crossover with secure boot I was referring to, but yep.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"aaf8a8a6eac6124f735263b4ba3656d12619b1f1","unresolved":true,"context_lines":[{"line_number":132,"context_line":""},{"line_number":133,"context_line":"As a cloud operator, I want to be able to live migrate instances with vTPM"},{"line_number":134,"context_line":"devices, in particular Windows instances."},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"Proposed change"},{"line_number":137,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":138,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"ecefdba4_b128acb9","line":135,"updated":"2024-12-10 15:50:15.000000000","message":"+ As a cloud user, I want to keep the content of the vTPM of my instance private. The cloud system should only be able to decrypt it when I request it via my user token and the system should only keep the decryption secret around for a limited time. I as a user willing to accept that such privacy requirements limit some of the admin initiated lifecycle operations on my VM.\n\n// I.e. the nova user should not be able to decrypt the secret any time to limit the blast radius of a compromised compute host. E.g. the VM is shutdown, the vTPM file and the encrypted VM disk is on the host, the vTPM key is stored on a different host by barbican. If at this point an attacker access the compute host today it cannot decrypt the vTPM file and therefore cannot decrypt the VM\u0027s disk as the vTPM secret is not accessible by the compromised host. But if there is a persistent ACL in barbican for the nova user for the secret, then the attacker can read the nova service password from the nova config file and read the secret from barbican and the user\u0027s data is leaked.\nI can even argue that while the VM is running and therefore qemu has the secret in memory such secret is safe if qemu devs are carefully put that secret into the host\u0027s physical TPM instead of in plain memory.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"f067fb8042d1ac33ee88a35fd8608e018c68911a","unresolved":false,"context_lines":[{"line_number":132,"context_line":""},{"line_number":133,"context_line":"As a cloud operator, I want to be able to live migrate instances with vTPM"},{"line_number":134,"context_line":"devices, in particular Windows instances."},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"Proposed change"},{"line_number":137,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":138,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"a222d534_a2874424","line":135,"in_reply_to":"ecefdba4_b128acb9","updated":"2024-12-20 22:21:32.000000000","message":"Done","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a337a2caf06f24d6d842ffd012a6c8280b9ccfd4","unresolved":true,"context_lines":[{"line_number":142,"context_line":"To enable vTPM live migration, changes in ``pre_live_migration()``,"},{"line_number":143,"context_line":"``post_live_migration()`` and ``rollback_live_migration_at_destination()`` are"},{"line_number":144,"context_line":"necessary to make the mechanics of it work. To handle rolling upgrades, a"},{"line_number":145,"context_line":"compute service bump is necessary to gate all of the above changes."},{"line_number":146,"context_line":""},{"line_number":147,"context_line":"Once those changes are in place, the currenty API block can be modified to only"},{"line_number":148,"context_line":"block the live migration if the user does not have access to the vTPM secret."}],"source_content_type":"text/x-rst","patch_set":5,"id":"d7a71a9f_d5de6053","line":145,"updated":"2024-12-09 19:48:58.000000000","message":"ack so the current api block will be replaced with a min compute service version check.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e492b65407fd0e2cb5fc09aed07329d82acd801d","unresolved":true,"context_lines":[{"line_number":142,"context_line":"To enable vTPM live migration, changes in ``pre_live_migration()``,"},{"line_number":143,"context_line":"``post_live_migration()`` and ``rollback_live_migration_at_destination()`` are"},{"line_number":144,"context_line":"necessary to make the mechanics of it work. To handle rolling upgrades, a"},{"line_number":145,"context_line":"compute service bump is necessary to gate all of the above changes."},{"line_number":146,"context_line":""},{"line_number":147,"context_line":"Once those changes are in place, the currenty API block can be modified to only"},{"line_number":148,"context_line":"block the live migration if the user does not have access to the vTPM secret."}],"source_content_type":"text/x-rst","patch_set":5,"id":"a25944ee_16dd6185","line":145,"in_reply_to":"0cb384cd_32026722","updated":"2024-12-10 17:40:21.000000000","message":"technically i think it could be made work with just the destination\nhowever I dont think we should support that.\n\nso even if its technically possible i think we should enfoce a min compute service version for the deployment in the api instead of doing a host-specific check in the condocutor.\n\n\nwe have done both in the past but the extra complexity of doing this in the conductor never really seamsed worth it to me. so unless we have a very stong reason why we want ot supprot this with poteially 2 release old compute as the souce node lets keep it simple and say you have to be fully upgraded to epoxy to use this.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"377dc653c8b3537cc4dacbf61d52a542bf4e8016","unresolved":true,"context_lines":[{"line_number":142,"context_line":"To enable vTPM live migration, changes in ``pre_live_migration()``,"},{"line_number":143,"context_line":"``post_live_migration()`` and ``rollback_live_migration_at_destination()`` are"},{"line_number":144,"context_line":"necessary to make the mechanics of it work. To handle rolling upgrades, a"},{"line_number":145,"context_line":"compute service bump is necessary to gate all of the above changes."},{"line_number":146,"context_line":""},{"line_number":147,"context_line":"Once those changes are in place, the currenty API block can be modified to only"},{"line_number":148,"context_line":"block the live migration if the user does not have access to the vTPM secret."}],"source_content_type":"text/x-rst","patch_set":5,"id":"dccdf193_838cce39","line":145,"in_reply_to":"a25944ee_16dd6185","updated":"2024-12-13 10:05:51.000000000","message":"Forcing both the source and the dest to be upgraded first works for me as a nova-compute upgrade does not require draining the VMs from the compute so we don\u0027t end up in a dependency loop of we need live migration to drain to upgrade to get the new feature, but we need the new feature to live migrate.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"cf7fac0a51df8a0fd2545da861eabd9526006d6d","unresolved":false,"context_lines":[{"line_number":142,"context_line":"To enable vTPM live migration, changes in ``pre_live_migration()``,"},{"line_number":143,"context_line":"``post_live_migration()`` and ``rollback_live_migration_at_destination()`` are"},{"line_number":144,"context_line":"necessary to make the mechanics of it work. To handle rolling upgrades, a"},{"line_number":145,"context_line":"compute service bump is necessary to gate all of the above changes."},{"line_number":146,"context_line":""},{"line_number":147,"context_line":"Once those changes are in place, the currenty API block can be modified to only"},{"line_number":148,"context_line":"block the live migration if the user does not have access to the vTPM secret."}],"source_content_type":"text/x-rst","patch_set":5,"id":"68b7e939_44855cc4","line":145,"in_reply_to":"d23c4327_d4204a7a","updated":"2025-01-07 14:22:19.000000000","message":"Acknowledged","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"aaf8a8a6eac6124f735263b4ba3656d12619b1f1","unresolved":true,"context_lines":[{"line_number":142,"context_line":"To enable vTPM live migration, changes in ``pre_live_migration()``,"},{"line_number":143,"context_line":"``post_live_migration()`` and ``rollback_live_migration_at_destination()`` are"},{"line_number":144,"context_line":"necessary to make the mechanics of it work. To handle rolling upgrades, a"},{"line_number":145,"context_line":"compute service bump is necessary to gate all of the above changes."},{"line_number":146,"context_line":""},{"line_number":147,"context_line":"Once those changes are in place, the currenty API block can be modified to only"},{"line_number":148,"context_line":"block the live migration if the user does not have access to the vTPM secret."}],"source_content_type":"text/x-rst","patch_set":5,"id":"0cb384cd_32026722","line":145,"in_reply_to":"d7a71a9f_d5de6053","updated":"2024-12-10 15:50:15.000000000","message":"Does both the source and the dest host needs to be on the new compute service?","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"f067fb8042d1ac33ee88a35fd8608e018c68911a","unresolved":true,"context_lines":[{"line_number":142,"context_line":"To enable vTPM live migration, changes in ``pre_live_migration()``,"},{"line_number":143,"context_line":"``post_live_migration()`` and ``rollback_live_migration_at_destination()`` are"},{"line_number":144,"context_line":"necessary to make the mechanics of it work. To handle rolling upgrades, a"},{"line_number":145,"context_line":"compute service bump is necessary to gate all of the above changes."},{"line_number":146,"context_line":""},{"line_number":147,"context_line":"Once those changes are in place, the currenty API block can be modified to only"},{"line_number":148,"context_line":"block the live migration if the user does not have access to the vTPM secret."}],"source_content_type":"text/x-rst","patch_set":5,"id":"d23c4327_d4204a7a","line":145,"in_reply_to":"dccdf193_838cce39","updated":"2024-12-20 22:21:32.000000000","message":"It\u0027s impossible to correctly handle vTPM live migration unless both source and dest support it. If we assume a _successful_ live migration, old to new can work, but in case of a rollback we\u0027d be leaving the secret defined on the dest  if our source is old.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"aaf8a8a6eac6124f735263b4ba3656d12619b1f1","unresolved":true,"context_lines":[{"line_number":145,"context_line":"compute service bump is necessary to gate all of the above changes."},{"line_number":146,"context_line":""},{"line_number":147,"context_line":"Once those changes are in place, the currenty API block can be modified to only"},{"line_number":148,"context_line":"block the live migration if the user does not have access to the vTPM secret."},{"line_number":149,"context_line":"This will allow live migration to work for instances created by admin, or in"},{"line_number":150,"context_line":"deployments with custom Barbican policy where admins have access to vTPM"},{"line_number":151,"context_line":"secrets."}],"source_content_type":"text/x-rst","patch_set":5,"id":"4e3d1f7a_7fd644d0","line":148,"range":{"start_line":148,"start_character":24,"end_line":148,"end_character":41},"updated":"2024-12-10 15:50:15.000000000","message":"nit: if the nova user does not","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"f067fb8042d1ac33ee88a35fd8608e018c68911a","unresolved":true,"context_lines":[{"line_number":145,"context_line":"compute service bump is necessary to gate all of the above changes."},{"line_number":146,"context_line":""},{"line_number":147,"context_line":"Once those changes are in place, the currenty API block can be modified to only"},{"line_number":148,"context_line":"block the live migration if the user does not have access to the vTPM secret."},{"line_number":149,"context_line":"This will allow live migration to work for instances created by admin, or in"},{"line_number":150,"context_line":"deployments with custom Barbican policy where admins have access to vTPM"},{"line_number":151,"context_line":"secrets."}],"source_content_type":"text/x-rst","patch_set":5,"id":"9e96cf49_d99784ca","line":148,"range":{"start_line":148,"start_character":24,"end_line":148,"end_character":41},"in_reply_to":"4e3d1f7a_7fd644d0","updated":"2024-12-20 22:21:32.000000000","message":"So I actually meant \"admin\" here. Once the mechanics are added and the cloud fully upgraded, instances owned by admin can be live migrated immediately (or if the operator has custom Barbican policy). So the check here is - \"does the user executing the live migration have access to the Barbican secret?\".","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"cf7fac0a51df8a0fd2545da861eabd9526006d6d","unresolved":false,"context_lines":[{"line_number":145,"context_line":"compute service bump is necessary to gate all of the above changes."},{"line_number":146,"context_line":""},{"line_number":147,"context_line":"Once those changes are in place, the currenty API block can be modified to only"},{"line_number":148,"context_line":"block the live migration if the user does not have access to the vTPM secret."},{"line_number":149,"context_line":"This will allow live migration to work for instances created by admin, or in"},{"line_number":150,"context_line":"deployments with custom Barbican policy where admins have access to vTPM"},{"line_number":151,"context_line":"secrets."}],"source_content_type":"text/x-rst","patch_set":5,"id":"9c708f97_febf61c9","line":148,"range":{"start_line":148,"start_character":24,"end_line":148,"end_character":41},"in_reply_to":"9e96cf49_d99784ca","updated":"2025-01-07 14:22:19.000000000","message":"Acknowledged","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a337a2caf06f24d6d842ffd012a6c8280b9ccfd4","unresolved":true,"context_lines":[{"line_number":148,"context_line":"block the live migration if the user does not have access to the vTPM secret."},{"line_number":149,"context_line":"This will allow live migration to work for instances created by admin, or in"},{"line_number":150,"context_line":"deployments with custom Barbican policy where admins have access to vTPM"},{"line_number":151,"context_line":"secrets."},{"line_number":152,"context_line":""},{"line_number":153,"context_line":"Once that is in place, the ``secret_access`` image property and flavor extra"},{"line_number":154,"context_line":"spec are added; initially the only possible value is ``nova``.  If set to"}],"source_content_type":"text/x-rst","patch_set":5,"id":"ec5afd49_76af857c","line":151,"updated":"2024-12-09 19:48:58.000000000","message":"ok so you want to detect that in the api instead of check_can_live_migrate_destiantion or pre_live_migration\ni thnk thats ok too.\n\npre_live_migraiton is the latest we shoudl check but doing it at the api is also valid. we shoudl avoid doing a get reqest for the content of the secreate but we can do a list or get without the content if that is possible to prevent transfering the secret data when we are just trying to check if we have access.\n\nif that the only way for use to test this in the api i think i would prefer to do this in pre_live_migration or check_can_live_migrate_destiantion.\n\nhttps://docs.openstack.org/nova/latest/reference/live-migration.html","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"7a8ea6322b2e4ae2ea0040a7515d5382ab22b2ed","unresolved":false,"context_lines":[{"line_number":148,"context_line":"block the live migration if the user does not have access to the vTPM secret."},{"line_number":149,"context_line":"This will allow live migration to work for instances created by admin, or in"},{"line_number":150,"context_line":"deployments with custom Barbican policy where admins have access to vTPM"},{"line_number":151,"context_line":"secrets."},{"line_number":152,"context_line":""},{"line_number":153,"context_line":"Once that is in place, the ``secret_access`` image property and flavor extra"},{"line_number":154,"context_line":"spec are added; initially the only possible value is ``nova``.  If set to"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1e835213_4fa8acd3","line":151,"in_reply_to":"ec5afd49_76af857c","updated":"2025-01-09 18:04:38.000000000","message":"Done","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"aaf8a8a6eac6124f735263b4ba3656d12619b1f1","unresolved":true,"context_lines":[{"line_number":152,"context_line":""},{"line_number":153,"context_line":"Once that is in place, the ``secret_access`` image property and flavor extra"},{"line_number":154,"context_line":"spec are added; initially the only possible value is ``nova``.  If set to"},{"line_number":155,"context_line":"``secret_access\u003dnova``, the ``encure_vtpm_secret()`` method makes sure an ACL"},{"line_number":156,"context_line":"that grants read access to the Nova service user is set on the secret. This"},{"line_number":157,"context_line":"happens regardless of whether the secret has just been created or if the secret"},{"line_number":158,"context_line":"already exists."}],"source_content_type":"text/x-rst","patch_set":5,"id":"0a4f08f9_9ef66557","line":155,"range":{"start_line":155,"start_character":30,"end_line":155,"end_character":48},"updated":"2024-12-10 15:50:15.000000000","message":"nit: ensure_vtpm_secret?","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"f067fb8042d1ac33ee88a35fd8608e018c68911a","unresolved":false,"context_lines":[{"line_number":152,"context_line":""},{"line_number":153,"context_line":"Once that is in place, the ``secret_access`` image property and flavor extra"},{"line_number":154,"context_line":"spec are added; initially the only possible value is ``nova``.  If set to"},{"line_number":155,"context_line":"``secret_access\u003dnova``, the ``encure_vtpm_secret()`` method makes sure an ACL"},{"line_number":156,"context_line":"that grants read access to the Nova service user is set on the secret. This"},{"line_number":157,"context_line":"happens regardless of whether the secret has just been created or if the secret"},{"line_number":158,"context_line":"already exists."}],"source_content_type":"text/x-rst","patch_set":5,"id":"f1a6a281_1c21ae6d","line":155,"range":{"start_line":155,"start_character":30,"end_line":155,"end_character":48},"in_reply_to":"0a4f08f9_9ef66557","updated":"2024-12-20 22:21:32.000000000","message":"Done","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a337a2caf06f24d6d842ffd012a6c8280b9ccfd4","unresolved":true,"context_lines":[{"line_number":155,"context_line":"``secret_access\u003dnova``, the ``encure_vtpm_secret()`` method makes sure an ACL"},{"line_number":156,"context_line":"that grants read access to the Nova service user is set on the secret. This"},{"line_number":157,"context_line":"happens regardless of whether the secret has just been created or if the secret"},{"line_number":158,"context_line":"already exists."},{"line_number":159,"context_line":""},{"line_number":160,"context_line":"If ``secret_access\u003dnova`` is set by the operator, the instance becomes \"dirty\""},{"line_number":161,"context_line":"and cannot be live migrated until the user performs an operation on it that"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3317a969_541b70a8","line":158,"updated":"2024-12-09 19:48:58.000000000","message":"we can actully do the api change later. and i woudl do the api change after this\n\nintially we can add the image property/extra spec and libvirt driver change without the api chagne.\n\nthis will allwo nova to start providing access to the nova service before we have enabeld the live migation code path in the api.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"7a8ea6322b2e4ae2ea0040a7515d5382ab22b2ed","unresolved":false,"context_lines":[{"line_number":155,"context_line":"``secret_access\u003dnova``, the ``encure_vtpm_secret()`` method makes sure an ACL"},{"line_number":156,"context_line":"that grants read access to the Nova service user is set on the secret. This"},{"line_number":157,"context_line":"happens regardless of whether the secret has just been created or if the secret"},{"line_number":158,"context_line":"already exists."},{"line_number":159,"context_line":""},{"line_number":160,"context_line":"If ``secret_access\u003dnova`` is set by the operator, the instance becomes \"dirty\""},{"line_number":161,"context_line":"and cannot be live migrated until the user performs an operation on it that"}],"source_content_type":"text/x-rst","patch_set":5,"id":"2e28c616_16e4f1df","line":158,"in_reply_to":"3317a969_541b70a8","updated":"2025-01-09 18:04:38.000000000","message":"Done","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a337a2caf06f24d6d842ffd012a6c8280b9ccfd4","unresolved":true,"context_lines":[{"line_number":162,"context_line":"triggers setting the ACL. Without further work outside the scope of this spec,"},{"line_number":163,"context_line":"it is not possible to communicate this \"dirtiness\" to the user in an automated"},{"line_number":164,"context_line":"way. This will have to be documented, and operators will have to rely on manual"},{"line_number":165,"context_line":"processes of their creation."},{"line_number":166,"context_line":""},{"line_number":167,"context_line":"This spec does not foresee other possible values for ``secret_access`` in the"},{"line_number":168,"context_line":"future - the ``nova`` value is chosen to best communicate the meaning of this"}],"source_content_type":"text/x-rst","patch_set":5,"id":"414c8937_e6d9f2ae","line":165,"updated":"2024-12-09 19:48:58.000000000","message":"so the only way ot set this on an exisitn isntance is db modifcation of the embeded flavor or image.\n\nthe image can be modifed in teh db via the nova-manage command but the flavor can only be updated via sql.\n\nso realistically this won\u0027t happen unless the operator modifies the db state in an unsupported way.\n\nin the context of this spec i would consider the nova-manage command to be unsupported in that its intentionally introducing this inconsistent state.\n\nAn operator might be ok with that inconsitency but i dont think nova shoudl provde a way to track if we have api access or not. that can be detected via the barbican acls.\n\n\nwhile i dont think it makes sense ot make \"nova\" in general track the dirty state we coudl consider if a nova-mange command might be worht adding to check if an acl is missing for an isntance that say it shoudl have access or perhaps nova-status.\n\nim leaning toward no, just document this but if other think that would be a good idea im not agaisnt it.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"f067fb8042d1ac33ee88a35fd8608e018c68911a","unresolved":true,"context_lines":[{"line_number":162,"context_line":"triggers setting the ACL. Without further work outside the scope of this spec,"},{"line_number":163,"context_line":"it is not possible to communicate this \"dirtiness\" to the user in an automated"},{"line_number":164,"context_line":"way. This will have to be documented, and operators will have to rely on manual"},{"line_number":165,"context_line":"processes of their creation."},{"line_number":166,"context_line":""},{"line_number":167,"context_line":"This spec does not foresee other possible values for ``secret_access`` in the"},{"line_number":168,"context_line":"future - the ``nova`` value is chosen to best communicate the meaning of this"}],"source_content_type":"text/x-rst","patch_set":5,"id":"b9253bfb_b8097cf4","line":165,"in_reply_to":"414c8937_e6d9f2ae","updated":"2024-12-20 22:21:32.000000000","message":"Yeah, I\u0027ve dropped this entirely, and proposed blocking nova-manage from changing this image property at all. If operators really want to live migrate vTPM instances, they can set custom policy. There\u0027s no way to make this work while still allowing users to give their consent - not unless we add huge amounts of scope, like the \"dirty\" instance thing.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"7a8ea6322b2e4ae2ea0040a7515d5382ab22b2ed","unresolved":false,"context_lines":[{"line_number":162,"context_line":"triggers setting the ACL. Without further work outside the scope of this spec,"},{"line_number":163,"context_line":"it is not possible to communicate this \"dirtiness\" to the user in an automated"},{"line_number":164,"context_line":"way. This will have to be documented, and operators will have to rely on manual"},{"line_number":165,"context_line":"processes of their creation."},{"line_number":166,"context_line":""},{"line_number":167,"context_line":"This spec does not foresee other possible values for ``secret_access`` in the"},{"line_number":168,"context_line":"future - the ``nova`` value is chosen to best communicate the meaning of this"}],"source_content_type":"text/x-rst","patch_set":5,"id":"6de7eb50_870f872e","line":165,"in_reply_to":"b9253bfb_b8097cf4","updated":"2025-01-09 18:04:38.000000000","message":"Done","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a337a2caf06f24d6d842ffd012a6c8280b9ccfd4","unresolved":true,"context_lines":[{"line_number":165,"context_line":"processes of their creation."},{"line_number":166,"context_line":""},{"line_number":167,"context_line":"This spec does not foresee other possible values for ``secret_access`` in the"},{"line_number":168,"context_line":"future - the ``nova`` value is chosen to best communicate the meaning of this"},{"line_number":169,"context_line":"image property/extra spec. The intention is to reuse this image property for"},{"line_number":170,"context_line":"other instance operations where Barbican secret access by the Nova service user"},{"line_number":171,"context_line":"are necessary - for example for the fix for `bug 1895848"}],"source_content_type":"text/x-rst","patch_set":5,"id":"8b12f7de_098f85ae","line":168,"range":{"start_line":168,"start_character":15,"end_line":168,"end_character":19},"updated":"2024-12-09 19:48:58.000000000","message":"so nova shoudl be `compute`\n\nwe do not use project codenames in iamge properies or extra specs.\n\nits why we use accel: instead of cyborg\n\nhttps://github.com/openstack/nova/blob/master/nova/api/validation/extra_specs/accel.py#L22C15-L22C34\n\nthe other reasonabel value to have would be ``project`` to be the current state where only a member of the project can access it.\n\nthat is what your implictily considering unset but i would argue it better to modle that in the enum and make `project` the default when not set.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"7a8ea6322b2e4ae2ea0040a7515d5382ab22b2ed","unresolved":false,"context_lines":[{"line_number":165,"context_line":"processes of their creation."},{"line_number":166,"context_line":""},{"line_number":167,"context_line":"This spec does not foresee other possible values for ``secret_access`` in the"},{"line_number":168,"context_line":"future - the ``nova`` value is chosen to best communicate the meaning of this"},{"line_number":169,"context_line":"image property/extra spec. The intention is to reuse this image property for"},{"line_number":170,"context_line":"other instance operations where Barbican secret access by the Nova service user"},{"line_number":171,"context_line":"are necessary - for example for the fix for `bug 1895848"}],"source_content_type":"text/x-rst","patch_set":5,"id":"dc8adfc8_dd34887a","line":168,"range":{"start_line":168,"start_character":15,"end_line":168,"end_character":19},"in_reply_to":"0596d80e_a78bb686","updated":"2025-01-09 18:04:38.000000000","message":"Done","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e492b65407fd0e2cb5fc09aed07329d82acd801d","unresolved":true,"context_lines":[{"line_number":165,"context_line":"processes of their creation."},{"line_number":166,"context_line":""},{"line_number":167,"context_line":"This spec does not foresee other possible values for ``secret_access`` in the"},{"line_number":168,"context_line":"future - the ``nova`` value is chosen to best communicate the meaning of this"},{"line_number":169,"context_line":"image property/extra spec. The intention is to reuse this image property for"},{"line_number":170,"context_line":"other instance operations where Barbican secret access by the Nova service user"},{"line_number":171,"context_line":"are necessary - for example for the fix for `bug 1895848"}],"source_content_type":"text/x-rst","patch_set":5,"id":"541de95d_b49781d9","line":168,"range":{"start_line":168,"start_character":15,"end_line":168,"end_character":19},"in_reply_to":"2d601ad0_ce6b3929","updated":"2024-12-10 17:40:21.000000000","message":"so i thought the user owned it but i remember being told it was actually owned by the user project when discussing mels local encryption series\n\nso we should confirm but I believe it\u0027s the project.\n\nif the user owns it I agree with using something like \"user_only\" to reflect that.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"f067fb8042d1ac33ee88a35fd8608e018c68911a","unresolved":true,"context_lines":[{"line_number":165,"context_line":"processes of their creation."},{"line_number":166,"context_line":""},{"line_number":167,"context_line":"This spec does not foresee other possible values for ``secret_access`` in the"},{"line_number":168,"context_line":"future - the ``nova`` value is chosen to best communicate the meaning of this"},{"line_number":169,"context_line":"image property/extra spec. The intention is to reuse this image property for"},{"line_number":170,"context_line":"other instance operations where Barbican secret access by the Nova service user"},{"line_number":171,"context_line":"are necessary - for example for the fix for `bug 1895848"}],"source_content_type":"text/x-rst","patch_set":5,"id":"0596d80e_a78bb686","line":168,"range":{"start_line":168,"start_character":15,"end_line":168,"end_character":19},"in_reply_to":"541de95d_b49781d9","updated":"2024-12-20 22:21:32.000000000","message":"I\u0027m not sure I understand what the point of `project` or `user_only` would be. That\u0027s basically what we have now, right? I\u0027m taking the angle that \"missing secret_access \u003d default/current behaviour\". Would we want `user_only` for _removing_ the ACL? That\u0027s something the user can do themselves, I\u0027m not sure they should be setting an image property to get Nova to proxy it for them. They can just remove the ACL and unset the image property.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"aaf8a8a6eac6124f735263b4ba3656d12619b1f1","unresolved":true,"context_lines":[{"line_number":165,"context_line":"processes of their creation."},{"line_number":166,"context_line":""},{"line_number":167,"context_line":"This spec does not foresee other possible values for ``secret_access`` in the"},{"line_number":168,"context_line":"future - the ``nova`` value is chosen to best communicate the meaning of this"},{"line_number":169,"context_line":"image property/extra spec. The intention is to reuse this image property for"},{"line_number":170,"context_line":"other instance operations where Barbican secret access by the Nova service user"},{"line_number":171,"context_line":"are necessary - for example for the fix for `bug 1895848"}],"source_content_type":"text/x-rst","patch_set":5,"id":"2d601ad0_ce6b3929","line":168,"range":{"start_line":168,"start_character":15,"end_line":168,"end_character":19},"in_reply_to":"8b12f7de_098f85ae","updated":"2024-12-10 15:50:15.000000000","message":"Is it really the whole project that can access the user\u0027s secret in barbican? I want to believe that barbican restricts the secret to the user not to the project. So I would suggest to user \"user_only\" internally instead of \"project\"\n\nI\u0027m OK to change the value from \"nova\" to \"compute\" as we cannot really encode the name of the user that will be granted access as the nova service user\u0027s username is configurable.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a337a2caf06f24d6d842ffd012a6c8280b9ccfd4","unresolved":true,"context_lines":[{"line_number":178,"context_line":"ensure that the vTPM secret is defined on the destination host."},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"Another option would be for Nova to fetch the secret from Libvirt on the source"},{"line_number":181,"context_line":"host, send it to the destination host over RPC, and define it on the"},{"line_number":182,"context_line":"destination without ever querying Barbican. This has the advantage of not"},{"line_number":183,"context_line":"needing any changes in the way vTPM secrets are created in Barbican. However,"},{"line_number":184,"context_line":"Nova currently defines the secret in Libvirt as both `private and ephemeral"}],"source_content_type":"text/x-rst","patch_set":5,"id":"505bef52_dac11ec8","line":181,"range":{"start_line":181,"start_character":43,"end_line":181,"end_character":47},"updated":"2024-12-09 19:48:58.000000000","message":"or over something else like ssh.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"f067fb8042d1ac33ee88a35fd8608e018c68911a","unresolved":false,"context_lines":[{"line_number":178,"context_line":"ensure that the vTPM secret is defined on the destination host."},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"Another option would be for Nova to fetch the secret from Libvirt on the source"},{"line_number":181,"context_line":"host, send it to the destination host over RPC, and define it on the"},{"line_number":182,"context_line":"destination without ever querying Barbican. This has the advantage of not"},{"line_number":183,"context_line":"needing any changes in the way vTPM secrets are created in Barbican. However,"},{"line_number":184,"context_line":"Nova currently defines the secret in Libvirt as both `private and ephemeral"}],"source_content_type":"text/x-rst","patch_set":5,"id":"00065edd_127e8eef","line":181,"range":{"start_line":181,"start_character":43,"end_line":181,"end_character":47},"in_reply_to":"505bef52_dac11ec8","updated":"2024-12-20 22:21:32.000000000","message":"Done","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"aaf8a8a6eac6124f735263b4ba3656d12619b1f1","unresolved":true,"context_lines":[{"line_number":187,"context_line":"secret public and persistent is a privacy violation, and sending it to the"},{"line_number":188,"context_line":"destination over RPC is only secure if the deployment uses TLS everywhere."},{"line_number":189,"context_line":""},{"line_number":190,"context_line":"An RFE could also be filed with Libvirt for Libvirt itself to copy the secret"},{"line_number":191,"context_line":"during live migration. This might be feasible, but the timeline is unknown; and"},{"line_number":192,"context_line":"while the advantage in simplicity is real, the currently proposed solution"},{"line_number":193,"context_line":"isn\u0027t prohibitively complex either."},{"line_number":194,"context_line":""},{"line_number":195,"context_line":"Instead of using ACLs to give the Nova service user read access to Barbican"},{"line_number":196,"context_line":"secrets, Nova could start creating the secret for *itself* rather than with the"}],"source_content_type":"text/x-rst","patch_set":5,"id":"e1c1d87a_43526d1b","line":193,"range":{"start_line":190,"start_character":0,"end_line":193,"end_character":35},"updated":"2024-12-10 15:50:15.000000000","message":"I would still suggest to file such RFE on libvirt so that in the future we can simplify nova.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"f067fb8042d1ac33ee88a35fd8608e018c68911a","unresolved":true,"context_lines":[{"line_number":187,"context_line":"secret public and persistent is a privacy violation, and sending it to the"},{"line_number":188,"context_line":"destination over RPC is only secure if the deployment uses TLS everywhere."},{"line_number":189,"context_line":""},{"line_number":190,"context_line":"An RFE could also be filed with Libvirt for Libvirt itself to copy the secret"},{"line_number":191,"context_line":"during live migration. This might be feasible, but the timeline is unknown; and"},{"line_number":192,"context_line":"while the advantage in simplicity is real, the currently proposed solution"},{"line_number":193,"context_line":"isn\u0027t prohibitively complex either."},{"line_number":194,"context_line":""},{"line_number":195,"context_line":"Instead of using ACLs to give the Nova service user read access to Barbican"},{"line_number":196,"context_line":"secrets, Nova could start creating the secret for *itself* rather than with the"}],"source_content_type":"text/x-rst","patch_set":5,"id":"b4320628_6bb358fc","line":193,"range":{"start_line":190,"start_character":0,"end_line":193,"end_character":35},"in_reply_to":"51e57eb0_e19f548e","updated":"2024-12-20 22:21:32.000000000","message":"Yeah, I can do that and amend the spec later.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"7a8ea6322b2e4ae2ea0040a7515d5382ab22b2ed","unresolved":false,"context_lines":[{"line_number":187,"context_line":"secret public and persistent is a privacy violation, and sending it to the"},{"line_number":188,"context_line":"destination over RPC is only secure if the deployment uses TLS everywhere."},{"line_number":189,"context_line":""},{"line_number":190,"context_line":"An RFE could also be filed with Libvirt for Libvirt itself to copy the secret"},{"line_number":191,"context_line":"during live migration. This might be feasible, but the timeline is unknown; and"},{"line_number":192,"context_line":"while the advantage in simplicity is real, the currently proposed solution"},{"line_number":193,"context_line":"isn\u0027t prohibitively complex either."},{"line_number":194,"context_line":""},{"line_number":195,"context_line":"Instead of using ACLs to give the Nova service user read access to Barbican"},{"line_number":196,"context_line":"secrets, Nova could start creating the secret for *itself* rather than with the"}],"source_content_type":"text/x-rst","patch_set":5,"id":"ed4643ab_bb99dcbe","line":193,"range":{"start_line":190,"start_character":0,"end_line":193,"end_character":35},"in_reply_to":"b4320628_6bb358fc","updated":"2025-01-09 18:04:38.000000000","message":"Done","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"2a535b5f38d0cd02c13961c03fb34084dbe80280","unresolved":true,"context_lines":[{"line_number":187,"context_line":"secret public and persistent is a privacy violation, and sending it to the"},{"line_number":188,"context_line":"destination over RPC is only secure if the deployment uses TLS everywhere."},{"line_number":189,"context_line":""},{"line_number":190,"context_line":"An RFE could also be filed with Libvirt for Libvirt itself to copy the secret"},{"line_number":191,"context_line":"during live migration. This might be feasible, but the timeline is unknown; and"},{"line_number":192,"context_line":"while the advantage in simplicity is real, the currently proposed solution"},{"line_number":193,"context_line":"isn\u0027t prohibitively complex either."},{"line_number":194,"context_line":""},{"line_number":195,"context_line":"Instead of using ACLs to give the Nova service user read access to Barbican"},{"line_number":196,"context_line":"secrets, Nova could start creating the secret for *itself* rather than with the"}],"source_content_type":"text/x-rst","patch_set":5,"id":"51e57eb0_e19f548e","line":193,"range":{"start_line":190,"start_character":0,"end_line":193,"end_character":35},"in_reply_to":"e1c1d87a_43526d1b","updated":"2024-12-13 04:06:17.000000000","message":"+1 this would be so nice to have.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a337a2caf06f24d6d842ffd012a6c8280b9ccfd4","unresolved":true,"context_lines":[{"line_number":197,"context_line":"user\u0027s token. The net effect is the same, but this would remove the upgrade"},{"line_number":198,"context_line":"path from legacy instances: while adding an ACL to their secrets is feasible,"},{"line_number":199,"context_line":"changing the owner is not."},{"line_number":200,"context_line":""},{"line_number":201,"context_line":"Data model impact"},{"line_number":202,"context_line":"-----------------"},{"line_number":203,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"e63ed152_b7cc267f","line":200,"updated":"2024-12-09 19:48:58.000000000","message":"realiticlly this is what we proably should have done form the start but we made it owned by the user to mirror cinder encypted volumes.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"382653408b93f5887579349627043a3850bb3ecf","unresolved":true,"context_lines":[{"line_number":197,"context_line":"user\u0027s token. The net effect is the same, but this would remove the upgrade"},{"line_number":198,"context_line":"path from legacy instances: while adding an ACL to their secrets is feasible,"},{"line_number":199,"context_line":"changing the owner is not."},{"line_number":200,"context_line":""},{"line_number":201,"context_line":"Data model impact"},{"line_number":202,"context_line":"-----------------"},{"line_number":203,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"408c517b_8a1be1e1","line":200,"in_reply_to":"25476148_bf53f551","updated":"2025-01-06 18:47:33.000000000","message":"I guess it depends on who else has access to the Nova service account? If it\u0027s only root-level compute hosts admin, then yeah, we\u0027re not adding any attack vector by giving them ownership of the vTPM secrets. If it\u0027s API-admins, then I\u0027d argue that we\u0027re breaking the confidentiality expectation.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ec23316314f01a981e73ee16d26d16b3e7c07020","unresolved":true,"context_lines":[{"line_number":197,"context_line":"user\u0027s token. The net effect is the same, but this would remove the upgrade"},{"line_number":198,"context_line":"path from legacy instances: while adding an ACL to their secrets is feasible,"},{"line_number":199,"context_line":"changing the owner is not."},{"line_number":200,"context_line":""},{"line_number":201,"context_line":"Data model impact"},{"line_number":202,"context_line":"-----------------"},{"line_number":203,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"25476148_bf53f551","line":200,"in_reply_to":"271d0e6c_06e01703","updated":"2025-01-06 18:03:20.000000000","message":"I agree with Sean that this would have been a better model, IMHO. Can we have a discussion about changing this spec to to do this and migrate existing keys? Keys for the volume are one thing, but unlike volumes the user literally cannot use the key nova creates for anything as they never have access to the actual TPM image. I\u0027d just like to really hear what the attack vector looks like with service-owned keys vs user-owned.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"105312a2ffef247ea4b5d54f874141f29ac66f08","unresolved":true,"context_lines":[{"line_number":197,"context_line":"user\u0027s token. The net effect is the same, but this would remove the upgrade"},{"line_number":198,"context_line":"path from legacy instances: while adding an ACL to their secrets is feasible,"},{"line_number":199,"context_line":"changing the owner is not."},{"line_number":200,"context_line":""},{"line_number":201,"context_line":"Data model impact"},{"line_number":202,"context_line":"-----------------"},{"line_number":203,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"5b9c8fce_d7670c21","line":200,"in_reply_to":"408c517b_8a1be1e1","updated":"2025-01-06 19:01:55.000000000","message":"Root-level admins have access to the service user credentials by virtue of being able to read any file on disk, and thus the nova.conf where those credentials are written. If the secret is owned by the nova service user, then API admins can migrate instances without being able to read the secrets in barbican, which seems like the ideal we\u0027re going for here. Same behavior if we define the key in libvirt so we can read it back out again.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"cf7fac0a51df8a0fd2545da861eabd9526006d6d","unresolved":true,"context_lines":[{"line_number":197,"context_line":"user\u0027s token. The net effect is the same, but this would remove the upgrade"},{"line_number":198,"context_line":"path from legacy instances: while adding an ACL to their secrets is feasible,"},{"line_number":199,"context_line":"changing the owner is not."},{"line_number":200,"context_line":""},{"line_number":201,"context_line":"Data model impact"},{"line_number":202,"context_line":"-----------------"},{"line_number":203,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"d3298e8e_9be419c1","line":200,"in_reply_to":"5b9c8fce_d7670c21","updated":"2025-01-07 14:22:19.000000000","message":"\u003e I\u0027d just like to really hear what the attack vector looks like with service-owned keys vs user-owned.\n\nIf the nova service user has permanent access to the secret in barbican, then the vector is:\n1. compromised compute node\n2. compromised nova service user / pass from nova.conf\n3. compromised vTMP encryption secret\n4. compromised VM disk content (assuming vTMP contains the key for the disk encryption as I assume the case for windows)\n\nIf only the user token has access to the secret in barbican then, nova has a limited time window when it has the ability to go to barbican, read the secret and potentially decrypt the VM disk. The window is limited as it needs the user token provided by the user and such token expires.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d46d7072f7448bd30f917ba1f1b6d8afba11fa6c","unresolved":false,"context_lines":[{"line_number":197,"context_line":"user\u0027s token. The net effect is the same, but this would remove the upgrade"},{"line_number":198,"context_line":"path from legacy instances: while adding an ACL to their secrets is feasible,"},{"line_number":199,"context_line":"changing the owner is not."},{"line_number":200,"context_line":""},{"line_number":201,"context_line":"Data model impact"},{"line_number":202,"context_line":"-----------------"},{"line_number":203,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"8c7bee44_5dc01eb6","line":200,"in_reply_to":"d3298e8e_9be419c1","updated":"2025-01-09 17:58:31.000000000","message":"Acknowledged","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"aaf8a8a6eac6124f735263b4ba3656d12619b1f1","unresolved":true,"context_lines":[{"line_number":197,"context_line":"user\u0027s token. The net effect is the same, but this would remove the upgrade"},{"line_number":198,"context_line":"path from legacy instances: while adding an ACL to their secrets is feasible,"},{"line_number":199,"context_line":"changing the owner is not."},{"line_number":200,"context_line":""},{"line_number":201,"context_line":"Data model impact"},{"line_number":202,"context_line":"-----------------"},{"line_number":203,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"271d0e6c_06e01703","line":200,"in_reply_to":"e63ed152_b7cc267f","updated":"2024-12-10 15:50:15.000000000","message":"I\u0027m glad we did not do it. That would have weakened the privacy feature.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a337a2caf06f24d6d842ffd012a6c8280b9ccfd4","unresolved":true,"context_lines":[{"line_number":201,"context_line":"Data model impact"},{"line_number":202,"context_line":"-----------------"},{"line_number":203,"context_line":""},{"line_number":204,"context_line":"The ``Flavor`` and ``ImageMetaProps`` Nova objects are updated to support the"},{"line_number":205,"context_line":"new ``secret_access`` extra spec and image properties, but the database schema"},{"line_number":206,"context_line":"is unaffected."},{"line_number":207,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"30478a23_30a1cfb3","line":204,"range":{"start_line":204,"start_character":4,"end_line":204,"end_character":14},"updated":"2024-12-09 19:48:58.000000000","message":"the flavor object is not modifed by the addtion of a new extra spec.\nthe extra_specs filed is a dict of string to sring.\n\nthe image is changed when we add new image properties however.\n\nyou will also need to update the notification objects.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"f067fb8042d1ac33ee88a35fd8608e018c68911a","unresolved":false,"context_lines":[{"line_number":201,"context_line":"Data model impact"},{"line_number":202,"context_line":"-----------------"},{"line_number":203,"context_line":""},{"line_number":204,"context_line":"The ``Flavor`` and ``ImageMetaProps`` Nova objects are updated to support the"},{"line_number":205,"context_line":"new ``secret_access`` extra spec and image properties, but the database schema"},{"line_number":206,"context_line":"is unaffected."},{"line_number":207,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"494ee124_9be08c59","line":204,"range":{"start_line":204,"start_character":4,"end_line":204,"end_character":14},"in_reply_to":"30478a23_30a1cfb3","updated":"2024-12-20 22:21:32.000000000","message":"Done","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a337a2caf06f24d6d842ffd012a6c8280b9ccfd4","unresolved":true,"context_lines":[{"line_number":209,"context_line":"---------------"},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"None. Flavor extra-specs and image properties are not officially part of Nova\u0027s"},{"line_number":212,"context_line":"REST API."},{"line_number":213,"context_line":""},{"line_number":214,"context_line":"Security impact"},{"line_number":215,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"77654cb3_5be788a1","line":212,"updated":"2024-12-09 19:48:58.000000000","message":"not quite ture.\n\nextra specs and image properties are part of the API. the allowed keys and values \nof flavour extra specs are exstiabel without an api microversion.\n\nthis is because operators can freely define there own flavor extra specs to use with filters. image properties are not freely extensible and always require an object change but the do not form part of the nova API. we only reference the image uuid. \n\nas such there is no api change as a result fo the addition of flavour extra specs or image properties.\n\n\nwith all that said when you add a new flavor extra spec you do need to extend the api validation to supprot that.\n\nthat does not cause a microversion change but we need to agree on which flavor namespace to add the secret_access key.\n\nit shoudl either be os:secret_access or hw:secret_access in my opipion\n\n\nwhich woudl make the image properties os_secret_access or hw_secret_access\n\nunless you suggesting a new `secret` namespace \n\nsecret:access  in which case the image property would be just secret_access\n\nhttps://github.com/openstack/nova/blob/master/nova/api/validation/extra_specs/os.py\nhttps://github.com/openstack/nova/blob/master/nova/api/validation/extra_specs/hw.py\n\nhw would make sense to group it with the other tpm extra specs\nhttps://github.com/openstack/nova/blob/master/nova/api/validation/extra_specs/hw.py#L460-L491\n\nso that woudl be my prefence.\n\nby the way i do not want to have to add a add a disk_secrte_access  extra spec/image property for local encyption jsut because tpm got here first\n\nif we dont wnat to commit to using a single value for all barbical sotrages secret for vtpu, volume encyption and local stroage then i want tpm in the name \n\nin which case i woudl stongly prefer\n\nhw:tpm_secret_access and hw_tpm_secret_access\n\nwhich woudl allow \n\nhw:volume_secret_access and hw_volume_secret_access to be added for cidner encypted voluems in the future.\n\nor hw:disk_secret_access and hw_disk_secret_access to be added for local disk encyption.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"f067fb8042d1ac33ee88a35fd8608e018c68911a","unresolved":true,"context_lines":[{"line_number":209,"context_line":"---------------"},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"None. Flavor extra-specs and image properties are not officially part of Nova\u0027s"},{"line_number":212,"context_line":"REST API."},{"line_number":213,"context_line":""},{"line_number":214,"context_line":"Security impact"},{"line_number":215,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"ed8a35f0_e72cba11","line":212,"in_reply_to":"77654cb3_5be788a1","updated":"2024-12-20 22:21:32.000000000","message":"The advantage of using a single extra spec/image property for all secrets is consistent easy to understand behaviour. Splitting it by secret type is more flexible, but I\u0027m not sure whether there are use cases where, for example, the vTPM secret needs to remain private but the volume encryption secret can be read by Nova. And anyways, the moment a _single_ secret isn\u0027t readable by Nova, the instance can\u0027t be live migrated, so for live migration we need all or none. So I think a single image prop/extra spec makes more sense. That being, I don\u0027t particularly care about the namespace. Feels like we need a new one, since nothing we currently have correctly reflects it (it\u0027s not quite os and it\u0027s not quite hw)","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"7a8ea6322b2e4ae2ea0040a7515d5382ab22b2ed","unresolved":false,"context_lines":[{"line_number":209,"context_line":"---------------"},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"None. Flavor extra-specs and image properties are not officially part of Nova\u0027s"},{"line_number":212,"context_line":"REST API."},{"line_number":213,"context_line":""},{"line_number":214,"context_line":"Security impact"},{"line_number":215,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"f2ba4a09_a659f4de","line":212,"in_reply_to":"ed8a35f0_e72cba11","updated":"2025-01-09 18:04:38.000000000","message":"Done","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a337a2caf06f24d6d842ffd012a6c8280b9ccfd4","unresolved":true,"context_lines":[{"line_number":235,"context_line":"Notifications impact"},{"line_number":236,"context_line":"--------------------"},{"line_number":237,"context_line":""},{"line_number":238,"context_line":"None."},{"line_number":239,"context_line":""},{"line_number":240,"context_line":"Other end user impact"},{"line_number":241,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3a8cea3c_475c4e3b","line":238,"updated":"2024-12-09 19:48:58.000000000","message":"the new image propety will cause the notrifcation objects to be updated both other then that i agree","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a337a2caf06f24d6d842ffd012a6c8280b9ccfd4","unresolved":true,"context_lines":[{"line_number":245,"context_line":"Performance Impact"},{"line_number":246,"context_line":"------------------"},{"line_number":247,"context_line":""},{"line_number":248,"context_line":"None beyond the additional runtime of the new code."},{"line_number":249,"context_line":""},{"line_number":250,"context_line":"Other deployer impact"},{"line_number":251,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"f3ef836e_6f10b342","line":248,"updated":"2024-12-09 19:48:58.000000000","message":"which is effectivly 1-2 calls to barbican to valide access and download the secret to the destination host.\n\nand that only applies if the instnace is using vtpm","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"7a8ea6322b2e4ae2ea0040a7515d5382ab22b2ed","unresolved":false,"context_lines":[{"line_number":245,"context_line":"Performance Impact"},{"line_number":246,"context_line":"------------------"},{"line_number":247,"context_line":""},{"line_number":248,"context_line":"None beyond the additional runtime of the new code."},{"line_number":249,"context_line":""},{"line_number":250,"context_line":"Other deployer impact"},{"line_number":251,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"30ff92c3_98c9ea5b","line":248,"in_reply_to":"f3ef836e_6f10b342","updated":"2025-01-09 18:04:38.000000000","message":"Done","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a337a2caf06f24d6d842ffd012a6c8280b9ccfd4","unresolved":true,"context_lines":[{"line_number":265,"context_line":"broken behavior when either the source or destination host hadn\u0027t been upgraded"},{"line_number":266,"context_line":"was a possibility). To that end, the compute service version is bumped, and"},{"line_number":267,"context_line":"vTPM live migration is kept blocked until the cloud is fully upgraded to the"},{"line_number":268,"context_line":"new version."},{"line_number":269,"context_line":""},{"line_number":270,"context_line":"Implementation"},{"line_number":271,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":5,"id":"99a7d1dd_7ac1b7f3","line":268,"updated":"2024-12-09 19:48:58.000000000","message":"+1","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"7a8ea6322b2e4ae2ea0040a7515d5382ab22b2ed","unresolved":false,"context_lines":[{"line_number":265,"context_line":"broken behavior when either the source or destination host hadn\u0027t been upgraded"},{"line_number":266,"context_line":"was a possibility). To that end, the compute service version is bumped, and"},{"line_number":267,"context_line":"vTPM live migration is kept blocked until the cloud is fully upgraded to the"},{"line_number":268,"context_line":"new version."},{"line_number":269,"context_line":""},{"line_number":270,"context_line":"Implementation"},{"line_number":271,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":5,"id":"98c965c8_5f6c9d90","line":268,"in_reply_to":"99a7d1dd_7ac1b7f3","updated":"2025-01-09 18:04:38.000000000","message":"Done","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"aaf8a8a6eac6124f735263b4ba3656d12619b1f1","unresolved":true,"context_lines":[{"line_number":283,"context_line":"---------------"},{"line_number":284,"context_line":""},{"line_number":285,"context_line":"Feature liaison:"},{"line_number":286,"context_line":"  melwitt, gibi"},{"line_number":287,"context_line":""},{"line_number":288,"context_line":"Work Items"},{"line_number":289,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"99e07c33_c1e24feb","line":286,"updated":"2024-12-10 15:50:15.000000000","message":"Based on our planning doc it was planned to be Dan and Mel. I have the SRIOV VGPU assigned as top prio so I need to consider the vTPM work as secondary.","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"f067fb8042d1ac33ee88a35fd8608e018c68911a","unresolved":false,"context_lines":[{"line_number":283,"context_line":"---------------"},{"line_number":284,"context_line":""},{"line_number":285,"context_line":"Feature liaison:"},{"line_number":286,"context_line":"  melwitt, gibi"},{"line_number":287,"context_line":""},{"line_number":288,"context_line":"Work Items"},{"line_number":289,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"dc4c9b1d_5b6b1315","line":286,"in_reply_to":"99e07c33_c1e24feb","updated":"2024-12-20 22:21:32.000000000","message":"Done","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"add12e45b4907c7102583fc48f52e765d17c45ca","unresolved":true,"context_lines":[{"line_number":297,"context_line":"#. Modify ``ensure_vtpm_secret()`` to add an ACL to the secret if"},{"line_number":298,"context_line":"   ``secret_access\u003dnova`` is set."},{"line_number":299,"context_line":"#. Add a whitebox/integration test."},{"line_number":300,"context_line":"#. Update the documentation."},{"line_number":301,"context_line":""},{"line_number":302,"context_line":"Dependencies"},{"line_number":303,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":5,"id":"a69ff32b_42e08298","line":300,"updated":"2024-12-09 19:51:50.000000000","message":"part of updating the docuementaion shoudl be extending the glance metadefs\nhttps://github.com/openstack/glance/blob/master/etc/metadefs/compute-libvirt-image.json\nhttps://github.com/openstack/glance/blob/master/etc/metadefs/compute-vtpm-hw.json","commit_id":"60be3f77b2f6c248d962448dfb877e998765c1ce"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ec23316314f01a981e73ee16d26d16b3e7c07020","unresolved":true,"context_lines":[{"line_number":81,"context_line":"When creating an instance with vTPM, Nova asks a key manager - normally"},{"line_number":82,"context_line":"Barbican - to generate a secret. Crucially, this is done with the user\u0027s token,"},{"line_number":83,"context_line":"and the created secret is owned by the user, with no one else - not even admin"},{"line_number":84,"context_line":"- being able to read it. This is correct behavior and Barbican should not"},{"line_number":85,"context_line":"change its default policy. Nova then `defines the secret in Libvirt"},{"line_number":86,"context_line":"\u003chttps://libvirt.org/formatsecret.html\u003e`_, and in the instance XML references"},{"line_number":87,"context_line":"the secret by its UUID. This tells Libvirt to encrypt the instance\u0027s vTPM state"},{"line_number":88,"context_line":"using the contents of that secret as the symmetric key. Nova `undefines the"}],"source_content_type":"text/x-rst","patch_set":9,"id":"09595418_a7c24fa7","line":85,"range":{"start_line":84,"start_character":54,"end_line":85,"end_character":25},"updated":"2025-01-06 18:03:20.000000000","message":"Can we ask some operators about this? Not about the default, but whether or not *they* would just set this in their policy and move on to make their lives easier. Like, I\u0027d like to hear which operators care about vTPM live migration and would *not* do this.","commit_id":"d718f140c91639698e433885c4286dba8da12887"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"d4be66605e411336c9583ceaffbbe2bbf57a4f8c","unresolved":true,"context_lines":[{"line_number":81,"context_line":"When creating an instance with vTPM, Nova asks a key manager - normally"},{"line_number":82,"context_line":"Barbican - to generate a secret. Crucially, this is done with the user\u0027s token,"},{"line_number":83,"context_line":"and the created secret is owned by the user, with no one else - not even admin"},{"line_number":84,"context_line":"- being able to read it. This is correct behavior and Barbican should not"},{"line_number":85,"context_line":"change its default policy. Nova then `defines the secret in Libvirt"},{"line_number":86,"context_line":"\u003chttps://libvirt.org/formatsecret.html\u003e`_, and in the instance XML references"},{"line_number":87,"context_line":"the secret by its UUID. This tells Libvirt to encrypt the instance\u0027s vTPM state"},{"line_number":88,"context_line":"using the contents of that secret as the symmetric key. Nova `undefines the"}],"source_content_type":"text/x-rst","patch_set":9,"id":"f59746aa_c604b7ea","line":85,"range":{"start_line":84,"start_character":54,"end_line":85,"end_character":25},"in_reply_to":"09595418_a7c24fa7","updated":"2025-01-06 20:13:36.000000000","message":"IMHO regardless of their answer, I think it\u0027s best to avoid Nova doing automatic things involving the Barbican secret API access policy on the fly. If it turns out to be generally accepted by the operator community to grant Barbican secret API access to admin and/or service users, it should be done as part of installers and/or configuration in my opinion.","commit_id":"d718f140c91639698e433885c4286dba8da12887"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"7a8ea6322b2e4ae2ea0040a7515d5382ab22b2ed","unresolved":false,"context_lines":[{"line_number":81,"context_line":"When creating an instance with vTPM, Nova asks a key manager - normally"},{"line_number":82,"context_line":"Barbican - to generate a secret. Crucially, this is done with the user\u0027s token,"},{"line_number":83,"context_line":"and the created secret is owned by the user, with no one else - not even admin"},{"line_number":84,"context_line":"- being able to read it. This is correct behavior and Barbican should not"},{"line_number":85,"context_line":"change its default policy. Nova then `defines the secret in Libvirt"},{"line_number":86,"context_line":"\u003chttps://libvirt.org/formatsecret.html\u003e`_, and in the instance XML references"},{"line_number":87,"context_line":"the secret by its UUID. This tells Libvirt to encrypt the instance\u0027s vTPM state"},{"line_number":88,"context_line":"using the contents of that secret as the symmetric key. Nova `undefines the"}],"source_content_type":"text/x-rst","patch_set":9,"id":"2a486a46_5dcbf7ea","line":85,"range":{"start_line":84,"start_character":54,"end_line":85,"end_character":25},"in_reply_to":"f59746aa_c604b7ea","updated":"2025-01-09 18:04:38.000000000","message":"Done","commit_id":"d718f140c91639698e433885c4286dba8da12887"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ec23316314f01a981e73ee16d26d16b3e7c07020","unresolved":true,"context_lines":[{"line_number":114,"context_line":".. note::"},{"line_number":115,"context_line":"   It\u0027s possible for flavor extra specs to be hidden from users via custom"},{"line_number":116,"context_line":"   policy. Setting ``secret_access\u003dcompute`` in such a fashion forces users to"},{"line_number":117,"context_line":"   expose their secrets to the Nova service user without their knowledge or"},{"line_number":118,"context_line":"   consent.  This has to be left out of scope, and this spec has to assume"},{"line_number":119,"context_line":"   default policy. Custom policy, in particular custom Barbican policy that"},{"line_number":120,"context_line":"   grants read access to secrets, tramples over any privacy and consent"}],"source_content_type":"text/x-rst","patch_set":9,"id":"3d3dca13_8cd1c445","line":117,"updated":"2025-01-06 18:03:20.000000000","message":"By \"forces users to expose their secrets to the nova service [user]\" you mean the key the nova service created for them ten minutes ago and the key which they have no other use for right? :D","commit_id":"d718f140c91639698e433885c4286dba8da12887"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"382653408b93f5887579349627043a3850bb3ecf","unresolved":true,"context_lines":[{"line_number":114,"context_line":".. note::"},{"line_number":115,"context_line":"   It\u0027s possible for flavor extra specs to be hidden from users via custom"},{"line_number":116,"context_line":"   policy. Setting ``secret_access\u003dcompute`` in such a fashion forces users to"},{"line_number":117,"context_line":"   expose their secrets to the Nova service user without their knowledge or"},{"line_number":118,"context_line":"   consent.  This has to be left out of scope, and this spec has to assume"},{"line_number":119,"context_line":"   default policy. Custom policy, in particular custom Barbican policy that"},{"line_number":120,"context_line":"   grants read access to secrets, tramples over any privacy and consent"}],"source_content_type":"text/x-rst","patch_set":9,"id":"9a874c4e_55d985e9","line":117,"in_reply_to":"3d3dca13_8cd1c445","updated":"2025-01-06 18:47:33.000000000","message":"I can rephrase it to be more about expectations. Yeah, the user doesn\u0027t directly use that secret ever again, but they have an expectation that their TPM isn\u0027t readable by others. Breaking that expectation by giving extra access to their secret is not cool.","commit_id":"d718f140c91639698e433885c4286dba8da12887"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"7a8ea6322b2e4ae2ea0040a7515d5382ab22b2ed","unresolved":false,"context_lines":[{"line_number":114,"context_line":".. note::"},{"line_number":115,"context_line":"   It\u0027s possible for flavor extra specs to be hidden from users via custom"},{"line_number":116,"context_line":"   policy. Setting ``secret_access\u003dcompute`` in such a fashion forces users to"},{"line_number":117,"context_line":"   expose their secrets to the Nova service user without their knowledge or"},{"line_number":118,"context_line":"   consent.  This has to be left out of scope, and this spec has to assume"},{"line_number":119,"context_line":"   default policy. Custom policy, in particular custom Barbican policy that"},{"line_number":120,"context_line":"   grants read access to secrets, tramples over any privacy and consent"}],"source_content_type":"text/x-rst","patch_set":9,"id":"a9b91140_d0150286","line":117,"in_reply_to":"9a874c4e_55d985e9","updated":"2025-01-09 18:04:38.000000000","message":"Done","commit_id":"d718f140c91639698e433885c4286dba8da12887"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ec23316314f01a981e73ee16d26d16b3e7c07020","unresolved":true,"context_lines":[{"line_number":132,"context_line":"For users this is relatively simple: set ``secret_access\u003dcompute`` on the"},{"line_number":133,"context_line":"image, then resize or rebuild the instance."},{"line_number":134,"context_line":""},{"line_number":135,"context_line":"For operators, setting this image property, if they have acces, is also"},{"line_number":136,"context_line":"possible. They would also be able to leverage the existing `nova-manage"},{"line_number":137,"context_line":"image_property set command"},{"line_number":138,"context_line":"\u003chttps://docs.openstack.org/nova/latest/cli/nova-manage.html#image-property-set\u003e`_"}],"source_content_type":"text/x-rst","patch_set":9,"id":"c7c5fa82_2e1589fb","line":135,"range":{"start_line":135,"start_character":57,"end_line":135,"end_character":62},"updated":"2025-01-06 18:03:20.000000000","message":"\"access\"","commit_id":"d718f140c91639698e433885c4286dba8da12887"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"382653408b93f5887579349627043a3850bb3ecf","unresolved":false,"context_lines":[{"line_number":132,"context_line":"For users this is relatively simple: set ``secret_access\u003dcompute`` on the"},{"line_number":133,"context_line":"image, then resize or rebuild the instance."},{"line_number":134,"context_line":""},{"line_number":135,"context_line":"For operators, setting this image property, if they have acces, is also"},{"line_number":136,"context_line":"possible. They would also be able to leverage the existing `nova-manage"},{"line_number":137,"context_line":"image_property set command"},{"line_number":138,"context_line":"\u003chttps://docs.openstack.org/nova/latest/cli/nova-manage.html#image-property-set\u003e`_"}],"source_content_type":"text/x-rst","patch_set":9,"id":"036e747a_b0270149","line":135,"range":{"start_line":135,"start_character":57,"end_line":135,"end_character":62},"in_reply_to":"c7c5fa82_2e1589fb","updated":"2025-01-06 18:47:33.000000000","message":"Done","commit_id":"d718f140c91639698e433885c4286dba8da12887"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ec23316314f01a981e73ee16d26d16b3e7c07020","unresolved":true,"context_lines":[{"line_number":143,"context_line":"``nova-manage image_property`` command from setting ``secret_access``."},{"line_number":144,"context_line":"Operators who absolutely need to live migrate vTPM instances and are either"},{"line_number":145,"context_line":"unwilling or unable to ask their users to update their image properties will"},{"line_number":146,"context_line":"have to use custom Barbican policy. This will be documented."},{"line_number":147,"context_line":""},{"line_number":148,"context_line":"Adjacent work"},{"line_number":149,"context_line":"-------------"}],"source_content_type":"text/x-rst","patch_set":9,"id":"1f2b649d_ea611ab2","line":146,"updated":"2025-01-06 18:03:20.000000000","message":"I think you\u0027re proving my \"this is just theater at the expense of admin usability\" argument here.\n\nIf we were to store the key in libvirt, we could fix each of these instances the next time the user does any action with them, and the admins could ask users to go do that in order to make their instances migrate-able (i.e. higher-ly available).","commit_id":"d718f140c91639698e433885c4286dba8da12887"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"17dceefc782c0650d55cd98714178c1dbb988443","unresolved":true,"context_lines":[{"line_number":143,"context_line":"``nova-manage image_property`` command from setting ``secret_access``."},{"line_number":144,"context_line":"Operators who absolutely need to live migrate vTPM instances and are either"},{"line_number":145,"context_line":"unwilling or unable to ask their users to update their image properties will"},{"line_number":146,"context_line":"have to use custom Barbican policy. This will be documented."},{"line_number":147,"context_line":""},{"line_number":148,"context_line":"Adjacent work"},{"line_number":149,"context_line":"-------------"}],"source_content_type":"text/x-rst","patch_set":9,"id":"a0a7cd8e_7bcfef5c","line":146,"in_reply_to":"09c99132_13e8698c","updated":"2025-01-06 21:54:24.000000000","message":"ack, retrievably is satisfyable by removing private\u003d\u0027yes\u0027 and not deletign the data in libvirt on boot.\n\nhttps://libvirt.org/formatsecret.html\n\n\"\"\"\nSecrets stored by libvirt may have attributes associated with them, using the secret element. The secret element has two optional attributes, each with values \u0027yes\u0027 and \u0027no\u0027, and defaulting to \u0027no\u0027:\n\nephemeral\n\n    This secret must only be kept in memory, never stored persistently.\nprivate\n\n    The value of the secret must not be revealed to any caller of libvirt, nor to any other node.\n\"\"\"\n\nby the way at some point libvirt gained the idea of secret types.\none of the types is vtpm \n\nhttps://libvirt.org/formatsecret.html#usage-type-vtpm\n\nwhen we add vtpm support we modifed how we create the secret in libvirt to set ephmeral and private to true only if the type was vtpm\n\nhttps://github.com/openstack/nova/blob/e10b36b5d39a48740c821cc7b6ce192d58015e42/nova/virt/libvirt/host.py#L1116-L1117\n\nall other libvirt cecrets we define are not marked as private or ephermal i.e the cinder volume encyptions secret form what i can tell.\n\nthe workding is also kind of interesting for the definition of private.\n\n\"\"\"\n    The value of the secret must not be revealed to any caller of libvirt, nor to any other node.\n\"\"\"\n\ni wonder if that implies that non private secreate will be transerfed to other nodes i.e. on live migration?\n\nthat might be worth testing.","commit_id":"d718f140c91639698e433885c4286dba8da12887"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"48d2439db8cf46364eeda79393bdb726190bb475","unresolved":true,"context_lines":[{"line_number":143,"context_line":"``nova-manage image_property`` command from setting ``secret_access``."},{"line_number":144,"context_line":"Operators who absolutely need to live migrate vTPM instances and are either"},{"line_number":145,"context_line":"unwilling or unable to ask their users to update their image properties will"},{"line_number":146,"context_line":"have to use custom Barbican policy. This will be documented."},{"line_number":147,"context_line":""},{"line_number":148,"context_line":"Adjacent work"},{"line_number":149,"context_line":"-------------"}],"source_content_type":"text/x-rst","patch_set":9,"id":"09c99132_13e8698c","line":146,"in_reply_to":"148389a4_b6b7f7bc","updated":"2025-01-06 20:14:48.000000000","message":"\u003e its only sort of defiend in libvirt right now.\n\u003e after the vm boot we delete teh secret form libvirt\n\nRight, when I say \"stored in libvirt\" or \"defined in libvirt\" I mean *persistently* and *retrievably*. I know libvirt knows about it ephemerally already, it\u0027s the and-accessible later that I\u0027m referring to almost everywhere in my review.","commit_id":"d718f140c91639698e433885c4286dba8da12887"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"0092c55634a101a750fe0a4c71dd626866c63284","unresolved":true,"context_lines":[{"line_number":143,"context_line":"``nova-manage image_property`` command from setting ``secret_access``."},{"line_number":144,"context_line":"Operators who absolutely need to live migrate vTPM instances and are either"},{"line_number":145,"context_line":"unwilling or unable to ask their users to update their image properties will"},{"line_number":146,"context_line":"have to use custom Barbican policy. This will be documented."},{"line_number":147,"context_line":""},{"line_number":148,"context_line":"Adjacent work"},{"line_number":149,"context_line":"-------------"}],"source_content_type":"text/x-rst","patch_set":9,"id":"148389a4_b6b7f7bc","line":146,"in_reply_to":"1c69c01f_ba2c0a50","updated":"2025-01-06 19:55:56.000000000","message":"its only sort of defiend in libvirt right now.\nafter the vm boot we delete teh secret form libvirt\n\n\nwe aslo define the secret with \u003csecret ephemeral\u003d\u0027yes\u0027 private\u003d\u0027yes\u0027\u003e\n\nprivate\u003dyes means we cant read it back from libvivrt\nand ephemeral\u003d\u0027yes\u0027 means its never stored on disk only in memopry so it does not survive host reboots.\n\nif we remove both of those and stop deletign it we coudl read it back on live migration and we could also use it to start the vm on host reboot if that conifg option is set.\n\ni think the tpm screte is the only one that is rerfence by a runnning domain that we then delete. i dotn belvie we do that for cinder volumes so its very much a special case today and not what i was expcting before we looked at the code.","commit_id":"d718f140c91639698e433885c4286dba8da12887"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"382653408b93f5887579349627043a3850bb3ecf","unresolved":true,"context_lines":[{"line_number":143,"context_line":"``nova-manage image_property`` command from setting ``secret_access``."},{"line_number":144,"context_line":"Operators who absolutely need to live migrate vTPM instances and are either"},{"line_number":145,"context_line":"unwilling or unable to ask their users to update their image properties will"},{"line_number":146,"context_line":"have to use custom Barbican policy. This will be documented."},{"line_number":147,"context_line":""},{"line_number":148,"context_line":"Adjacent work"},{"line_number":149,"context_line":"-------------"}],"source_content_type":"text/x-rst","patch_set":9,"id":"e4da8ec1_ba986fc6","line":146,"in_reply_to":"1f2b649d_ea611ab2","updated":"2025-01-06 18:47:33.000000000","message":"What do you mean store the key in libvirt? It\u0027s already in libvirt - it has to be for libvirt to be able to encrypt the vTPM state with it. It just _comes_ from Barbican. Are you saying stop using Barbican altogether? Or do you mean definining the secret in libvirt in a way that we can read it back whenever we need to?","commit_id":"d718f140c91639698e433885c4286dba8da12887"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"7a8ea6322b2e4ae2ea0040a7515d5382ab22b2ed","unresolved":false,"context_lines":[{"line_number":143,"context_line":"``nova-manage image_property`` command from setting ``secret_access``."},{"line_number":144,"context_line":"Operators who absolutely need to live migrate vTPM instances and are either"},{"line_number":145,"context_line":"unwilling or unable to ask their users to update their image properties will"},{"line_number":146,"context_line":"have to use custom Barbican policy. This will be documented."},{"line_number":147,"context_line":""},{"line_number":148,"context_line":"Adjacent work"},{"line_number":149,"context_line":"-------------"}],"source_content_type":"text/x-rst","patch_set":9,"id":"29cdd807_7a28d35c","line":146,"in_reply_to":"a0a7cd8e_7bcfef5c","updated":"2025-01-09 18:04:38.000000000","message":"Done","commit_id":"d718f140c91639698e433885c4286dba8da12887"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"105312a2ffef247ea4b5d54f874141f29ac66f08","unresolved":true,"context_lines":[{"line_number":143,"context_line":"``nova-manage image_property`` command from setting ``secret_access``."},{"line_number":144,"context_line":"Operators who absolutely need to live migrate vTPM instances and are either"},{"line_number":145,"context_line":"unwilling or unable to ask their users to update their image properties will"},{"line_number":146,"context_line":"have to use custom Barbican policy. This will be documented."},{"line_number":147,"context_line":""},{"line_number":148,"context_line":"Adjacent work"},{"line_number":149,"context_line":"-------------"}],"source_content_type":"text/x-rst","patch_set":9,"id":"1c69c01f_ba2c0a50","line":146,"in_reply_to":"e4da8ec1_ba986fc6","updated":"2025-01-06 19:01:55.000000000","message":"I mean defining it so the hypervisor can access it when it needs to participate in a move operation.","commit_id":"d718f140c91639698e433885c4286dba8da12887"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ec23316314f01a981e73ee16d26d16b3e7c07020","unresolved":true,"context_lines":[{"line_number":160,"context_line":"migrated. Therefore, it makes sense to make secret access an all-or-nothing"},{"line_number":161,"context_line":"switch, and use a single image property/flavor extra spec for all cases where"},{"line_number":162,"context_line":"secret access by Nova is necessary for instance operations."},{"line_number":163,"context_line":""},{"line_number":164,"context_line":"Use Cases"},{"line_number":165,"context_line":"---------"},{"line_number":166,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"df56b215_5c10532d","line":163,"updated":"2025-01-06 18:03:20.000000000","message":"Shouldn\u0027t you also mention that we can\u0027t restart these instances on host reboot? Another problem that would be fixed by storing the secrets in libvirt.","commit_id":"d718f140c91639698e433885c4286dba8da12887"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"382653408b93f5887579349627043a3850bb3ecf","unresolved":false,"context_lines":[{"line_number":160,"context_line":"migrated. Therefore, it makes sense to make secret access an all-or-nothing"},{"line_number":161,"context_line":"switch, and use a single image property/flavor extra spec for all cases where"},{"line_number":162,"context_line":"secret access by Nova is necessary for instance operations."},{"line_number":163,"context_line":""},{"line_number":164,"context_line":"Use Cases"},{"line_number":165,"context_line":"---------"},{"line_number":166,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"e21b35ca_0920e5f4","line":163,"in_reply_to":"df56b215_5c10532d","updated":"2025-01-06 18:47:33.000000000","message":"Done","commit_id":"d718f140c91639698e433885c4286dba8da12887"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ec23316314f01a981e73ee16d26d16b3e7c07020","unresolved":true,"context_lines":[{"line_number":188,"context_line":"rollback becomes necessary, Nova\u0027s rollback RPC mechanics combined with an old"},{"line_number":189,"context_line":"source compute host would leave the destination without cleanup, keeping the"},{"line_number":190,"context_line":"vTPM secret defined in Libvirt. vTPM live migration is kept blocked until the"},{"line_number":191,"context_line":"entire cloud is updated to the new compute service version."},{"line_number":192,"context_line":""},{"line_number":193,"context_line":"Once those changes are in place, vTPM live migration becomes technically"},{"line_number":194,"context_line":"possible as long as the user initiating the live migration has access to the"}],"source_content_type":"text/x-rst","patch_set":9,"id":"e6dd54ee_dcfe75a3","line":191,"updated":"2025-01-06 18:03:20.000000000","message":"This means people that migrate to avoid upgrading a node with live instances on it are excluded. Seems like we could handle the cleanup of stale secrets in init_host or a periodic right? Not saying it\u0027s really that important, but it does kinda suck. \"Migrate to upgrade\" is the model we have in other places.","commit_id":"d718f140c91639698e433885c4286dba8da12887"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"7a8ea6322b2e4ae2ea0040a7515d5382ab22b2ed","unresolved":false,"context_lines":[{"line_number":188,"context_line":"rollback becomes necessary, Nova\u0027s rollback RPC mechanics combined with an old"},{"line_number":189,"context_line":"source compute host would leave the destination without cleanup, keeping the"},{"line_number":190,"context_line":"vTPM secret defined in Libvirt. vTPM live migration is kept blocked until the"},{"line_number":191,"context_line":"entire cloud is updated to the new compute service version."},{"line_number":192,"context_line":""},{"line_number":193,"context_line":"Once those changes are in place, vTPM live migration becomes technically"},{"line_number":194,"context_line":"possible as long as the user initiating the live migration has access to the"}],"source_content_type":"text/x-rst","patch_set":9,"id":"6e68cf3f_132c1609","line":191,"in_reply_to":"547f3f25_da7b0588","updated":"2025-01-09 18:04:38.000000000","message":"Done","commit_id":"d718f140c91639698e433885c4286dba8da12887"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"382653408b93f5887579349627043a3850bb3ecf","unresolved":true,"context_lines":[{"line_number":188,"context_line":"rollback becomes necessary, Nova\u0027s rollback RPC mechanics combined with an old"},{"line_number":189,"context_line":"source compute host would leave the destination without cleanup, keeping the"},{"line_number":190,"context_line":"vTPM secret defined in Libvirt. vTPM live migration is kept blocked until the"},{"line_number":191,"context_line":"entire cloud is updated to the new compute service version."},{"line_number":192,"context_line":""},{"line_number":193,"context_line":"Once those changes are in place, vTPM live migration becomes technically"},{"line_number":194,"context_line":"possible as long as the user initiating the live migration has access to the"}],"source_content_type":"text/x-rst","patch_set":9,"id":"547f3f25_da7b0588","line":191,"in_reply_to":"e6dd54ee_dcfe75a3","updated":"2025-01-06 18:47:33.000000000","message":"If we want to do that it means we can\u0027t have the source send the key over, it has to come from Barbican so that the new destination can download it and set it up. I\u0027m not against the idea, just know that it\u0027s mutually exclusive with your other idea :)","commit_id":"d718f140c91639698e433885c4286dba8da12887"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ec23316314f01a981e73ee16d26d16b3e7c07020","unresolved":true,"context_lines":[{"line_number":263,"context_line":"The main security consequence of this spec is that the Nova service user gains"},{"line_number":264,"context_line":"read access to vTPM secrets. This isn\u0027t bad in and of itself, as the Nova"},{"line_number":265,"context_line":"service user is assumed to be secure, but it does mean that any compromise of"},{"line_number":266,"context_line":"the Nova service user can escalate to a compromise the workloads\u0027s vTPMs, and"},{"line_number":267,"context_line":"then to anything secured via those vTPMs, like Windows guests\u0027s disk encryption"},{"line_number":268,"context_line":"with BitLocker."},{"line_number":269,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"923d1231_eb1e9224","line":266,"range":{"start_line":266,"start_character":40,"end_line":266,"end_character":50},"updated":"2025-01-06 18:03:20.000000000","message":"\"compromise *of*\" ?","commit_id":"d718f140c91639698e433885c4286dba8da12887"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"382653408b93f5887579349627043a3850bb3ecf","unresolved":false,"context_lines":[{"line_number":263,"context_line":"The main security consequence of this spec is that the Nova service user gains"},{"line_number":264,"context_line":"read access to vTPM secrets. This isn\u0027t bad in and of itself, as the Nova"},{"line_number":265,"context_line":"service user is assumed to be secure, but it does mean that any compromise of"},{"line_number":266,"context_line":"the Nova service user can escalate to a compromise the workloads\u0027s vTPMs, and"},{"line_number":267,"context_line":"then to anything secured via those vTPMs, like Windows guests\u0027s disk encryption"},{"line_number":268,"context_line":"with BitLocker."},{"line_number":269,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"e6634674_7bd7883c","line":266,"range":{"start_line":266,"start_character":40,"end_line":266,"end_character":50},"in_reply_to":"923d1231_eb1e9224","updated":"2025-01-06 18:47:33.000000000","message":"Done","commit_id":"d718f140c91639698e433885c4286dba8da12887"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ec23316314f01a981e73ee16d26d16b3e7c07020","unresolved":true,"context_lines":[{"line_number":264,"context_line":"read access to vTPM secrets. This isn\u0027t bad in and of itself, as the Nova"},{"line_number":265,"context_line":"service user is assumed to be secure, but it does mean that any compromise of"},{"line_number":266,"context_line":"the Nova service user can escalate to a compromise the workloads\u0027s vTPMs, and"},{"line_number":267,"context_line":"then to anything secured via those vTPMs, like Windows guests\u0027s disk encryption"},{"line_number":268,"context_line":"with BitLocker."},{"line_number":269,"context_line":""},{"line_number":270,"context_line":"All of this is mitigated by said read access being opt-in on the part of the"}],"source_content_type":"text/x-rst","patch_set":9,"id":"a03a5c8e_9bcd04b2","line":267,"range":{"start_line":267,"start_character":55,"end_line":267,"end_character":63},"updated":"2025-01-06 18:03:20.000000000","message":"\"guests\u0027\" ?","commit_id":"d718f140c91639698e433885c4286dba8da12887"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"382653408b93f5887579349627043a3850bb3ecf","unresolved":false,"context_lines":[{"line_number":264,"context_line":"read access to vTPM secrets. This isn\u0027t bad in and of itself, as the Nova"},{"line_number":265,"context_line":"service user is assumed to be secure, but it does mean that any compromise of"},{"line_number":266,"context_line":"the Nova service user can escalate to a compromise the workloads\u0027s vTPMs, and"},{"line_number":267,"context_line":"then to anything secured via those vTPMs, like Windows guests\u0027s disk encryption"},{"line_number":268,"context_line":"with BitLocker."},{"line_number":269,"context_line":""},{"line_number":270,"context_line":"All of this is mitigated by said read access being opt-in on the part of the"}],"source_content_type":"text/x-rst","patch_set":9,"id":"495cce65_7f0e05de","line":267,"range":{"start_line":267,"start_character":55,"end_line":267,"end_character":63},"in_reply_to":"a03a5c8e_9bcd04b2","updated":"2025-01-06 18:47:33.000000000","message":"I\u0027m never sure of plural possessive. \"Guests\u0027 \"?","commit_id":"d718f140c91639698e433885c4286dba8da12887"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4fc47bd7b1a34432e1becad8380a717f55d01c39","unresolved":false,"context_lines":[{"line_number":76,"context_line":"Secret management"},{"line_number":77,"context_line":"-----------------"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"When creating an instance with vTPM, Nova asks a key manager - normally"},{"line_number":80,"context_line":"Barbican - to generate a secret. Crucially, this is done with the user\u0027s token,"},{"line_number":81,"context_line":"and the created secret is owned by the user, with no one else - not even admin"},{"line_number":82,"context_line":"or the Nova service user - being able to read it. Nova then `defines the secret"},{"line_number":83,"context_line":"in Libvirt \u003chttps://libvirt.org/formatsecret.html\u003e`_, and in the instance XML"}],"source_content_type":"text/x-rst","patch_set":11,"id":"1b9a5aa6_86e61674","line":80,"range":{"start_line":79,"start_character":63,"end_line":80,"end_character":9},"updated":"2025-01-09 20:18:23.000000000","message":"right we have an indirection via castellan so it technically could be something else but practically speaking it wont be","commit_id":"ffca3fe48dd2aa8ef4b4bf1fc953b695586c294c"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"7758776f6a19d3e1e8e732f8ae4008e098064f53","unresolved":true,"context_lines":[{"line_number":92,"context_line":"Libvirt can decrypt the vTPM state. Currently, Nova has no way of doing this."},{"line_number":93,"context_line":"Live migration is an admin operation, and neither admin nor the Nova service"},{"line_number":94,"context_line":"user have access to the Barbican secret (unless the admin happens to be the"},{"line_number":95,"context_line":"owen of the instance, but that\u0027s an edge case). The Libvirt secret cannot be"},{"line_number":96,"context_line":"read back on the source host either, because it\u0027s defined as `private"},{"line_number":97,"context_line":"\u003chttps://opendev.org/openstack/nova/src/commit/c79bec0f2257967da1dcccc9f562253d6ede535d/nova/virt/libvirt/host.py#L1115-L1116\u003e`_"},{"line_number":98,"context_line":"and is undefined once the domain spawns."}],"source_content_type":"text/x-rst","patch_set":11,"id":"7d14e629_04ac270b","line":95,"range":{"start_line":95,"start_character":0,"end_line":95,"end_character":4},"updated":"2025-01-10 01:46:17.000000000","message":"owner","commit_id":"ffca3fe48dd2aa8ef4b4bf1fc953b695586c294c"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d46d7072f7448bd30f917ba1f1b6d8afba11fa6c","unresolved":true,"context_lines":[{"line_number":114,"context_line":"The cloud system should only be able to decrypt it when I request it via my"},{"line_number":115,"context_line":"user token and the system should only keep the decryption secret around for a"},{"line_number":116,"context_line":"limited time. I as a user am willing to accept that such privacy requirements"},{"line_number":117,"context_line":"limit some of the admin initiated lifecycle operations on my instance."},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"As a cloud operator, I want vTPM instances on a compute host to start back up"},{"line_number":120,"context_line":"again after a host reboot."}],"source_content_type":"text/x-rst","patch_set":11,"id":"d2369f6a_e26364d4","line":117,"updated":"2025-01-09 17:58:31.000000000","message":"Sounds like this needs an update? Maybe at least soften the \"my security trumps admin abilities\" with \"keep the secret in as few places as necessary\".","commit_id":"ffca3fe48dd2aa8ef4b4bf1fc953b695586c294c"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"0a8710b07bddfdbcfa9bd494a2db10739674a2bf","unresolved":false,"context_lines":[{"line_number":114,"context_line":"The cloud system should only be able to decrypt it when I request it via my"},{"line_number":115,"context_line":"user token and the system should only keep the decryption secret around for a"},{"line_number":116,"context_line":"limited time. I as a user am willing to accept that such privacy requirements"},{"line_number":117,"context_line":"limit some of the admin initiated lifecycle operations on my instance."},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"As a cloud operator, I want vTPM instances on a compute host to start back up"},{"line_number":120,"context_line":"again after a host reboot."}],"source_content_type":"text/x-rst","patch_set":11,"id":"a04d8bc9_370c4c89","line":117,"in_reply_to":"d2369f6a_e26364d4","updated":"2025-01-09 23:54:22.000000000","message":"Done","commit_id":"ffca3fe48dd2aa8ef4b4bf1fc953b695586c294c"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d46d7072f7448bd30f917ba1f1b6d8afba11fa6c","unresolved":true,"context_lines":[{"line_number":144,"context_line":"     - The instance is immovable and cannot be restarted by Nova in the event of a"},{"line_number":145,"context_line":"       compute host crash or reboot."},{"line_number":146,"context_line":"   * - ``host``"},{"line_number":147,"context_line":"     - The Libvirt secret is persistent and retrievable."},{"line_number":148,"context_line":"     - This is \"medium\" security. API-level admins and the Nova service user do"},{"line_number":149,"context_line":"       not have access to the secret, but it can be access by users on the compute"},{"line_number":150,"context_line":"       host."}],"source_content_type":"text/x-rst","patch_set":11,"id":"b033a60c_2ce50c45","line":147,"updated":"2025-01-09 17:58:31.000000000","message":"Personally I think this is fine, but I think it wasn\u0027t quite clear from the discussion we had whether we wanted to make it persistent. However, this means host mode solves the migration *and* reboot problems, at the expense of plugs-out exposure. However, the admin can also mitigate that with their own host-based encryption of the `/var/lib/swtpm` area, which to me means we *should* make host persistent, making `host` mode very compelling.","commit_id":"ffca3fe48dd2aa8ef4b4bf1fc953b695586c294c"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"0a8710b07bddfdbcfa9bd494a2db10739674a2bf","unresolved":true,"context_lines":[{"line_number":144,"context_line":"     - The instance is immovable and cannot be restarted by Nova in the event of a"},{"line_number":145,"context_line":"       compute host crash or reboot."},{"line_number":146,"context_line":"   * - ``host``"},{"line_number":147,"context_line":"     - The Libvirt secret is persistent and retrievable."},{"line_number":148,"context_line":"     - This is \"medium\" security. API-level admins and the Nova service user do"},{"line_number":149,"context_line":"       not have access to the secret, but it can be access by users on the compute"},{"line_number":150,"context_line":"       host."}],"source_content_type":"text/x-rst","patch_set":11,"id":"c67d0ebb_9e4318f2","line":147,"in_reply_to":"b033a60c_2ce50c45","updated":"2025-01-09 23:54:22.000000000","message":"Yeah, it was left open during the call and I figured I\u0027d just decide something and propose it. Making it persistent solves the reboot problem, so I chose that.","commit_id":"ffca3fe48dd2aa8ef4b4bf1fc953b695586c294c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4fc47bd7b1a34432e1becad8380a717f55d01c39","unresolved":true,"context_lines":[{"line_number":144,"context_line":"     - The instance is immovable and cannot be restarted by Nova in the event of a"},{"line_number":145,"context_line":"       compute host crash or reboot."},{"line_number":146,"context_line":"   * - ``host``"},{"line_number":147,"context_line":"     - The Libvirt secret is persistent and retrievable."},{"line_number":148,"context_line":"     - This is \"medium\" security. API-level admins and the Nova service user do"},{"line_number":149,"context_line":"       not have access to the secret, but it can be access by users on the compute"},{"line_number":150,"context_line":"       host."}],"source_content_type":"text/x-rst","patch_set":11,"id":"30e7d84c_09e8c6ce","line":147,"in_reply_to":"b033a60c_2ce50c45","updated":"2025-01-09 20:18:23.000000000","message":"un less there is stong push back form other lets defer if it perseitent to the implementation review but i think that is ok for the reason you said . i.e. encypring /var/lib/swtpm at the host level at rest.","commit_id":"ffca3fe48dd2aa8ef4b4bf1fc953b695586c294c"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d46d7072f7448bd30f917ba1f1b6d8afba11fa6c","unresolved":true,"context_lines":[{"line_number":146,"context_line":"   * - ``host``"},{"line_number":147,"context_line":"     - The Libvirt secret is persistent and retrievable."},{"line_number":148,"context_line":"     - This is \"medium\" security. API-level admins and the Nova service user do"},{"line_number":149,"context_line":"       not have access to the secret, but it can be access by users on the compute"},{"line_number":150,"context_line":"       host."},{"line_number":151,"context_line":"     - The instance can be live migrated because Nova can read the secret back"},{"line_number":152,"context_line":"       from Libvirt on the source host and send it to the destination over RPC."}],"source_content_type":"text/x-rst","patch_set":11,"id":"aa999eeb_a137e192","line":149,"range":{"start_line":149,"start_character":52,"end_line":149,"end_character":58},"updated":"2025-01-09 17:58:31.000000000","message":"\"accessed\"","commit_id":"ffca3fe48dd2aa8ef4b4bf1fc953b695586c294c"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d46d7072f7448bd30f917ba1f1b6d8afba11fa6c","unresolved":true,"context_lines":[{"line_number":146,"context_line":"   * - ``host``"},{"line_number":147,"context_line":"     - The Libvirt secret is persistent and retrievable."},{"line_number":148,"context_line":"     - This is \"medium\" security. API-level admins and the Nova service user do"},{"line_number":149,"context_line":"       not have access to the secret, but it can be access by users on the compute"},{"line_number":150,"context_line":"       host."},{"line_number":151,"context_line":"     - The instance can be live migrated because Nova can read the secret back"},{"line_number":152,"context_line":"       from Libvirt on the source host and send it to the destination over RPC."}],"source_content_type":"text/x-rst","patch_set":11,"id":"656dd0a2_811ee095","line":149,"range":{"start_line":149,"start_character":62,"end_line":149,"end_character":67},"updated":"2025-01-09 17:58:31.000000000","message":"This sounds worse than it is to me. I think you mean \"root users\" or maybe \"attackers which have gained sufficient control over the node\". I also think it might be worth calling out the \"level of exposure\" or \"amount of compromise to expose\" for each of these being \"only the user\", \"only the host\", and \"the deployment\".","commit_id":"ffca3fe48dd2aa8ef4b4bf1fc953b695586c294c"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"0a8710b07bddfdbcfa9bd494a2db10739674a2bf","unresolved":false,"context_lines":[{"line_number":146,"context_line":"   * - ``host``"},{"line_number":147,"context_line":"     - The Libvirt secret is persistent and retrievable."},{"line_number":148,"context_line":"     - This is \"medium\" security. API-level admins and the Nova service user do"},{"line_number":149,"context_line":"       not have access to the secret, but it can be access by users on the compute"},{"line_number":150,"context_line":"       host."},{"line_number":151,"context_line":"     - The instance can be live migrated because Nova can read the secret back"},{"line_number":152,"context_line":"       from Libvirt on the source host and send it to the destination over RPC."}],"source_content_type":"text/x-rst","patch_set":11,"id":"056acf4c_8fff04da","line":149,"range":{"start_line":149,"start_character":62,"end_line":149,"end_character":67},"in_reply_to":"656dd0a2_811ee095","updated":"2025-01-09 23:54:22.000000000","message":"Done","commit_id":"ffca3fe48dd2aa8ef4b4bf1fc953b695586c294c"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"0a8710b07bddfdbcfa9bd494a2db10739674a2bf","unresolved":false,"context_lines":[{"line_number":146,"context_line":"   * - ``host``"},{"line_number":147,"context_line":"     - The Libvirt secret is persistent and retrievable."},{"line_number":148,"context_line":"     - This is \"medium\" security. API-level admins and the Nova service user do"},{"line_number":149,"context_line":"       not have access to the secret, but it can be access by users on the compute"},{"line_number":150,"context_line":"       host."},{"line_number":151,"context_line":"     - The instance can be live migrated because Nova can read the secret back"},{"line_number":152,"context_line":"       from Libvirt on the source host and send it to the destination over RPC."}],"source_content_type":"text/x-rst","patch_set":11,"id":"7ba14c2d_94da2479","line":149,"range":{"start_line":149,"start_character":52,"end_line":149,"end_character":58},"in_reply_to":"aa999eeb_a137e192","updated":"2025-01-09 23:54:22.000000000","message":"Done","commit_id":"ffca3fe48dd2aa8ef4b4bf1fc953b695586c294c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4fc47bd7b1a34432e1becad8380a717f55d01c39","unresolved":true,"context_lines":[{"line_number":152,"context_line":"       from Libvirt on the source host and send it to the destination over RPC."},{"line_number":153,"context_line":"       Security over the wire is left as the operator\u0027s responsibility, but TLS or"},{"line_number":154,"context_line":"       similar is assumed. The instance can also be restarted by Nova in the event"},{"line_number":155,"context_line":"       of a compute host crash or reboot for the exact same reason."},{"line_number":156,"context_line":"   * - ``deployment``"},{"line_number":157,"context_line":"     - The Nova service user owns the Barbican secret."},{"line_number":158,"context_line":"     - This is the least secure but most flexible option."}],"source_content_type":"text/x-rst","patch_set":11,"id":"1b28cc51_63a01428","line":155,"updated":"2025-01-09 20:18:23.000000000","message":"ok i guess the same level of protection exits when talkign to barbican\n\ni.e. if your not using tls for the api call its in the clear anyway in flight so we can expect/document that tls shoudl be used for rabbit too.\n\nits not perfect as the message could be persisted to disk by rabbit if your using durable queues but it think as long as we document it thats all we can really do.","commit_id":"ffca3fe48dd2aa8ef4b4bf1fc953b695586c294c"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d46d7072f7448bd30f917ba1f1b6d8afba11fa6c","unresolved":true,"context_lines":[{"line_number":159,"context_line":"     - The instance can be live migrated because Nova can download the secret from"},{"line_number":160,"context_line":"       Barbican and define it in Libvirt on the destination host. The instance can"},{"line_number":161,"context_line":"       also be restarted by Nova in the event of a compute host crash or reboot"},{"line_number":162,"context_line":"       for the exact same reason."},{"line_number":163,"context_line":""},{"line_number":164,"context_line":"These three values are exposed as driver capability traits, one per compute"},{"line_number":165,"context_line":"host resource provider. Instance owners can request which security policy they"}],"source_content_type":"text/x-rst","patch_set":11,"id":"859c77c5_78fe4c39","line":162,"updated":"2025-01-09 17:58:31.000000000","message":"This also means shared-storage instances can be evacuated by the admins or an external tool. Otherwise, with persistent and retrievable libvirt, this doesn\u0027t have much of a difference other than not charging/exposing the key to the user.\n\nThis also makes me think... in the case of a ceph-backed instance where the host catches fire, evacuation will not be possible for an instance if the TPM image perished in the fire.... I hope operators are aware :)","commit_id":"ffca3fe48dd2aa8ef4b4bf1fc953b695586c294c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4fc47bd7b1a34432e1becad8380a717f55d01c39","unresolved":true,"context_lines":[{"line_number":159,"context_line":"     - The instance can be live migrated because Nova can download the secret from"},{"line_number":160,"context_line":"       Barbican and define it in Libvirt on the destination host. The instance can"},{"line_number":161,"context_line":"       also be restarted by Nova in the event of a compute host crash or reboot"},{"line_number":162,"context_line":"       for the exact same reason."},{"line_number":163,"context_line":""},{"line_number":164,"context_line":"These three values are exposed as driver capability traits, one per compute"},{"line_number":165,"context_line":"host resource provider. Instance owners can request which security policy they"}],"source_content_type":"text/x-rst","patch_set":11,"id":"a40944e9_89a00d65","line":162,"in_reply_to":"859c77c5_78fe4c39","updated":"2025-01-09 20:18:23.000000000","message":"given the currently limitation of swtpm\nthe only way i can see to suporting evacuate in a reasonable way is \nputting /var/lib/swtpm on nfs share.\n\nwe may want to consider in the future allowing evacuate but just creating an empty tpm on the dest.\n\nif the guest is not actually using the tpm for BitLocker or similar that may allow the vm to be recovered in a usable state with a minimal lost of data\n\ni.e. if i was usign the tpm to store my x509 signing keys in an instnace, well thos woudl be gone but at leaast you get the root disk back.\n\n\nobviously, if the tpm was actually storing a bitlock encryption key you are still screwed unless you have bitlocker recovery codes backed up but that is actully still better then todya where you cant evacuate at all.","commit_id":"ffca3fe48dd2aa8ef4b4bf1fc953b695586c294c"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"1cd6ce5d68a2ac757f01fa82895f2dfaee794c24","unresolved":true,"context_lines":[{"line_number":159,"context_line":"     - The instance can be live migrated because Nova can download the secret from"},{"line_number":160,"context_line":"       Barbican and define it in Libvirt on the destination host. The instance can"},{"line_number":161,"context_line":"       also be restarted by Nova in the event of a compute host crash or reboot"},{"line_number":162,"context_line":"       for the exact same reason."},{"line_number":163,"context_line":""},{"line_number":164,"context_line":"These three values are exposed as driver capability traits, one per compute"},{"line_number":165,"context_line":"host resource provider. Instance owners can request which security policy they"}],"source_content_type":"text/x-rst","patch_set":11,"id":"2819a629_8e46852a","line":162,"in_reply_to":"a40944e9_89a00d65","updated":"2025-01-10 16:18:58.000000000","message":"Yeah, this is what I was thinking. Obviously if bitlocker, then no solution other than tpm on shared storage. But, if you have a TPM just because windows makes you, it sucks to be unable to live migrate, evacuate, etc.","commit_id":"ffca3fe48dd2aa8ef4b4bf1fc953b695586c294c"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d46d7072f7448bd30f917ba1f1b6d8afba11fa6c","unresolved":true,"context_lines":[{"line_number":163,"context_line":""},{"line_number":164,"context_line":"These three values are exposed as driver capability traits, one per compute"},{"line_number":165,"context_line":"host resource provider. Instance owners can request which security policy they"},{"line_number":166,"context_line":"want by setting required traits on their images. Once an instance boots an"},{"line_number":167,"context_line":"host, the host\u0027s configured ``vtpm_secret_security`` policy is persisted in"},{"line_number":168,"context_line":"``instance.system_metadata[vtpm_secret_security]``."},{"line_number":169,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"2f4e64ae_3988eb2a","line":166,"range":{"start_line":166,"start_character":72,"end_line":166,"end_character":74},"updated":"2025-01-09 17:58:31.000000000","message":"\"on\" ?","commit_id":"ffca3fe48dd2aa8ef4b4bf1fc953b695586c294c"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d46d7072f7448bd30f917ba1f1b6d8afba11fa6c","unresolved":true,"context_lines":[{"line_number":163,"context_line":""},{"line_number":164,"context_line":"These three values are exposed as driver capability traits, one per compute"},{"line_number":165,"context_line":"host resource provider. Instance owners can request which security policy they"},{"line_number":166,"context_line":"want by setting required traits on their images. Once an instance boots an"},{"line_number":167,"context_line":"host, the host\u0027s configured ``vtpm_secret_security`` policy is persisted in"},{"line_number":168,"context_line":"``instance.system_metadata[vtpm_secret_security]``."},{"line_number":169,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"7ab0dca8_15b0753b","line":166,"range":{"start_line":166,"start_character":0,"end_line":166,"end_character":4},"updated":"2025-01-09 17:58:31.000000000","message":"can you change \"want\" to \"require\" to make it more clear that we\u0027re not just letting them choose, but letting them declare the minimum level of security they\u0027re willing to tolerate?","commit_id":"ffca3fe48dd2aa8ef4b4bf1fc953b695586c294c"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"0a8710b07bddfdbcfa9bd494a2db10739674a2bf","unresolved":false,"context_lines":[{"line_number":163,"context_line":""},{"line_number":164,"context_line":"These three values are exposed as driver capability traits, one per compute"},{"line_number":165,"context_line":"host resource provider. Instance owners can request which security policy they"},{"line_number":166,"context_line":"want by setting required traits on their images. Once an instance boots an"},{"line_number":167,"context_line":"host, the host\u0027s configured ``vtpm_secret_security`` policy is persisted in"},{"line_number":168,"context_line":"``instance.system_metadata[vtpm_secret_security]``."},{"line_number":169,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"14a7ee49_3d8b0aa0","line":166,"range":{"start_line":166,"start_character":72,"end_line":166,"end_character":74},"in_reply_to":"2f4e64ae_3988eb2a","updated":"2025-01-09 23:54:22.000000000","message":"Done","commit_id":"ffca3fe48dd2aa8ef4b4bf1fc953b695586c294c"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"0a8710b07bddfdbcfa9bd494a2db10739674a2bf","unresolved":false,"context_lines":[{"line_number":163,"context_line":""},{"line_number":164,"context_line":"These three values are exposed as driver capability traits, one per compute"},{"line_number":165,"context_line":"host resource provider. Instance owners can request which security policy they"},{"line_number":166,"context_line":"want by setting required traits on their images. Once an instance boots an"},{"line_number":167,"context_line":"host, the host\u0027s configured ``vtpm_secret_security`` policy is persisted in"},{"line_number":168,"context_line":"``instance.system_metadata[vtpm_secret_security]``."},{"line_number":169,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"3c5bdb6e_6d27e6a7","line":166,"range":{"start_line":166,"start_character":0,"end_line":166,"end_character":4},"in_reply_to":"7ab0dca8_15b0753b","updated":"2025-01-09 23:54:22.000000000","message":"Done","commit_id":"ffca3fe48dd2aa8ef4b4bf1fc953b695586c294c"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d46d7072f7448bd30f917ba1f1b6d8afba11fa6c","unresolved":true,"context_lines":[{"line_number":165,"context_line":"host resource provider. Instance owners can request which security policy they"},{"line_number":166,"context_line":"want by setting required traits on their images. Once an instance boots an"},{"line_number":167,"context_line":"host, the host\u0027s configured ``vtpm_secret_security`` policy is persisted in"},{"line_number":168,"context_line":"``instance.system_metadata[vtpm_secret_security]``."},{"line_number":169,"context_line":""},{"line_number":170,"context_line":"A compute service version bump is necessary to upgrade instances created before"},{"line_number":171,"context_line":"the vTPM live migration feature merges. How this is achieved is explained in"}],"source_content_type":"text/x-rst","patch_set":11,"id":"a46e93cb_8416ae1c","line":168,"updated":"2025-01-09 17:58:31.000000000","message":"I don\u0027t think this is necessary, is it? It\u0027s already in the instance image metadata if they set a requirement, and if they didn\u0027t I don\u0027t think we need to get in another pinning-the-default war like AZs, do we?","commit_id":"ffca3fe48dd2aa8ef4b4bf1fc953b695586c294c"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"7758776f6a19d3e1e8e732f8ae4008e098064f53","unresolved":true,"context_lines":[{"line_number":174,"context_line":"Instances with their ``vtpm_secret_security`` set to ``user`` (either"},{"line_number":175,"context_line":"implicitly right after an upgrade, or explicitly by booting on such a host)"},{"line_number":176,"context_line":"cannot be live migrated. Instances with ``host`` or ``deployment`` can, and the"},{"line_number":177,"context_line":"current API block is modified to only allow live migration of such instances."},{"line_number":178,"context_line":""},{"line_number":179,"context_line":".. todo:: Simply having a ``vtpm_secret_security`` policy of ``host`` or"},{"line_number":180,"context_line":"   ``deployment`` is not enough. If this is a pre-existing instance, the owner"}],"source_content_type":"text/x-rst","patch_set":11,"id":"33cd9dff_4bb869ac","line":177,"updated":"2025-01-10 01:46:17.000000000","message":"This is the only thing that made me pause a little, thinking about the artificial API block in the case of `user` even if the user has granted admin secret access via Barbican ACL and it would otherwise work.\n\nI get that if live migration is part of an operator\u0027s standard usage model they would configure `deployment` but I\u0027m thinking what if they need `user` 99.9% of the time but unexpectedly need to one-off a live migration for some sort of recovery or to unwedge something ... they would not have the option of granting temporary access via ACL even though it is technically possible.\n\nTBH it\u0027s not an unreasonable compromise to not be able to have every possible ability given a config choice, for simplicity, but I just wanted to mention it since I thought of it.\n\nIf we were to not artificially block, we would want/need to check for secret access in the API in order to fail fast in the case of no secret access, which would add the expense of a GET call to Barbican for vTPM live migration `user` requests.\n\nI did exactly that in the proposed local disk encryption series last cycle based on code review feedback, so I guess I wonder why we wouldn\u0027t do the same thing here similarly and not artificially block.","commit_id":"ffca3fe48dd2aa8ef4b4bf1fc953b695586c294c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b1ed2eeba513a0ea2efe4ffbe17e8019d5a99379","unresolved":true,"context_lines":[{"line_number":174,"context_line":"Instances with their ``vtpm_secret_security`` set to ``user`` (either"},{"line_number":175,"context_line":"implicitly right after an upgrade, or explicitly by booting on such a host)"},{"line_number":176,"context_line":"cannot be live migrated. Instances with ``host`` or ``deployment`` can, and the"},{"line_number":177,"context_line":"current API block is modified to only allow live migration of such instances."},{"line_number":178,"context_line":""},{"line_number":179,"context_line":".. todo:: Simply having a ``vtpm_secret_security`` policy of ``host`` or"},{"line_number":180,"context_line":"   ``deployment`` is not enough. If this is a pre-existing instance, the owner"}],"source_content_type":"text/x-rst","patch_set":11,"id":"6e403ef3_a84727a6","line":177,"in_reply_to":"33cd9dff_4bb869ac","updated":"2025-01-10 11:17:15.000000000","message":"oh that was in your series not artom that explains the look of confugion when i mentioned that yesterday.\n\nso ya we can do an accessablity check from the api like you did instead of hard block.\n\nalso did you look at the follow up patch?\nit woudl be good to get yoru input on that too.","commit_id":"ffca3fe48dd2aa8ef4b4bf1fc953b695586c294c"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"76f092ab97f8cb73884d00f3896a9ca7309f2c27","unresolved":true,"context_lines":[{"line_number":174,"context_line":"Instances with their ``vtpm_secret_security`` set to ``user`` (either"},{"line_number":175,"context_line":"implicitly right after an upgrade, or explicitly by booting on such a host)"},{"line_number":176,"context_line":"cannot be live migrated. Instances with ``host`` or ``deployment`` can, and the"},{"line_number":177,"context_line":"current API block is modified to only allow live migration of such instances."},{"line_number":178,"context_line":""},{"line_number":179,"context_line":".. todo:: Simply having a ``vtpm_secret_security`` policy of ``host`` or"},{"line_number":180,"context_line":"   ``deployment`` is not enough. If this is a pre-existing instance, the owner"}],"source_content_type":"text/x-rst","patch_set":11,"id":"311d520e_abe31e56","line":177,"in_reply_to":"6e403ef3_a84727a6","updated":"2025-01-10 20:38:12.000000000","message":"\u003e oh that was in your series not artom that explains the look of confugion when i mentioned that yesterday.\n\nHaha 🙂\n\n\u003e so ya we can do an accessablity check from the api like you did instead of hard block.\n\nCool, that would be good if we can.\n\n\u003e also did you look at the follow up patch?\n\u003e it woudl be good to get yoru input on that too.\n\nAcking that the follow up patch has since been squashed into this one.","commit_id":"ffca3fe48dd2aa8ef4b4bf1fc953b695586c294c"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d46d7072f7448bd30f917ba1f1b6d8afba11fa6c","unresolved":true,"context_lines":[{"line_number":180,"context_line":"   ``deployment`` is not enough. If this is a pre-existing instance, the owner"},{"line_number":181,"context_line":"   has to have taken an action with their token to actually perform the"},{"line_number":182,"context_line":"   conversion. How do we record this having happened so that the API block can"},{"line_number":183,"context_line":"   know which instances can be live migrated?"},{"line_number":184,"context_line":""},{"line_number":185,"context_line":"Before modifying the API block, the mechanics to actually live migrate vTPM"},{"line_number":186,"context_line":"instances need to be put in place. ``pre_live_migration()`` on the source sends"}],"source_content_type":"text/x-rst","patch_set":11,"id":"de374636_ec84dec3","line":183,"updated":"2025-01-09 17:58:31.000000000","message":"Handle it in the compute node, which will fail later than earlier? It\u0027s not ideal, but I think it\u0027s not super terrible. Especially if we expose the stoplight indication for the instances that we discussed.","commit_id":"ffca3fe48dd2aa8ef4b4bf1fc953b695586c294c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4fc47bd7b1a34432e1becad8380a717f55d01c39","unresolved":true,"context_lines":[{"line_number":198,"context_line":"Barbican secret to the Nova service user. This was deemed too unfriendly to"},{"line_number":199,"context_line":"operators, especially of private clouds, who are looking for a way to enable"},{"line_number":200,"context_line":"live migration for all their vTPM instances without having to request user"},{"line_number":201,"context_line":"confirmation for every instance."},{"line_number":202,"context_line":""},{"line_number":203,"context_line":"Data model impact"},{"line_number":204,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":11,"id":"913b874e_2d709af0","line":201,"updated":"2025-01-09 20:18:23.000000000","message":"so we chatted about this again and we willl likely go back to ^\nwith the addtion of 2 config options\n\n1 a list of a allow polices per host\n2 a default to use when not set in the image or flavor.\n\nwhen the default is set on booth form the config option  or flaovr we will recored it in the instance_system_metadata as if it was set in the image\n\nform a code point of view we will always just read the \"image\" value form the cached copy so we have a single code path on the comptue\n\nin the api we need to make sure that on server create, or resize that we dont have a flavor/image conflcit like normal when somethign can be requested form both.\n\ni would also suggest that on rebuild we shoudl not delete the TPM data today but we shoudl check if the metadtaa on the rebuidl image  conflcit with the flavor.\n\nif your rebuilding a snapshot it shoudl never conflcit\nif your rebuildign to an entirly idffent image it might and we woudl just reject the image liek we woudl for initial spawn.","commit_id":"ffca3fe48dd2aa8ef4b4bf1fc953b695586c294c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"470ba7e79e1fc992d681d97af1c5cdda348a8dcb","unresolved":false,"context_lines":[{"line_number":198,"context_line":"Barbican secret to the Nova service user. This was deemed too unfriendly to"},{"line_number":199,"context_line":"operators, especially of private clouds, who are looking for a way to enable"},{"line_number":200,"context_line":"live migration for all their vTPM instances without having to request user"},{"line_number":201,"context_line":"confirmation for every instance."},{"line_number":202,"context_line":""},{"line_number":203,"context_line":"Data model impact"},{"line_number":204,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":11,"id":"644fb6e1_4d8f97f5","line":201,"in_reply_to":"913b874e_2d709af0","updated":"2025-01-10 15:52:08.000000000","message":"Done","commit_id":"ffca3fe48dd2aa8ef4b4bf1fc953b695586c294c"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d46d7072f7448bd30f917ba1f1b6d8afba11fa6c","unresolved":true,"context_lines":[{"line_number":264,"context_line":"If it is set, the next check is whether all instances on the host have a value"},{"line_number":265,"context_line":"persisted in ``instance.system_metadata[vtpm_secret_security]``. If none of"},{"line_number":266,"context_line":"them do, all instances on the host are converted to use the configured value"},{"line_number":267,"context_line":"for ``vtpm_secret_security``, and this value is persisted in the database."},{"line_number":268,"context_line":""},{"line_number":269,"context_line":"If all instances on the host *do* have a value in"},{"line_number":270,"context_line":"``instance.system_metadata[vtpm_secret_security]``, then nothing is done as"}],"source_content_type":"text/x-rst","patch_set":11,"id":"5a0c8c42_a40e0fd8","line":267,"updated":"2025-01-09 17:58:31.000000000","message":"As I mentioned, I think we can do this by just stabbing a new image property into the cached version, as if the user had requested it instead of the new separate key we have to track, right?","commit_id":"ffca3fe48dd2aa8ef4b4bf1fc953b695586c294c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"470ba7e79e1fc992d681d97af1c5cdda348a8dcb","unresolved":false,"context_lines":[{"line_number":264,"context_line":"If it is set, the next check is whether all instances on the host have a value"},{"line_number":265,"context_line":"persisted in ``instance.system_metadata[vtpm_secret_security]``. If none of"},{"line_number":266,"context_line":"them do, all instances on the host are converted to use the configured value"},{"line_number":267,"context_line":"for ``vtpm_secret_security``, and this value is persisted in the database."},{"line_number":268,"context_line":""},{"line_number":269,"context_line":"If all instances on the host *do* have a value in"},{"line_number":270,"context_line":"``instance.system_metadata[vtpm_secret_security]``, then nothing is done as"}],"source_content_type":"text/x-rst","patch_set":11,"id":"b93ea808_66d9133e","line":267,"in_reply_to":"5a0c8c42_a40e0fd8","updated":"2025-01-10 15:52:08.000000000","message":"Done","commit_id":"ffca3fe48dd2aa8ef4b4bf1fc953b695586c294c"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d46d7072f7448bd30f917ba1f1b6d8afba11fa6c","unresolved":true,"context_lines":[{"line_number":286,"context_line":".. todo:: How do we communicate to the owners that their instance now has a"},{"line_number":287,"context_line":"   ``vtpm_secret_security`` policy set, and they they can either do an action on"},{"line_number":288,"context_line":"   their instance to opt in to this new policy, or either do nothing or delete"},{"line_number":289,"context_line":"   their instance if they disagree?"},{"line_number":290,"context_line":""},{"line_number":291,"context_line":"Implementation"},{"line_number":292,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":11,"id":"6f0d9ce2_b8efe5d9","line":289,"updated":"2025-01-09 17:58:31.000000000","message":"I guess we don\u0027t have an embedded copy of the image metadata like we do flavor .. if so, that would do it. But, the \"can I migrate and why not\" stoplight property would do it.","commit_id":"ffca3fe48dd2aa8ef4b4bf1fc953b695586c294c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"470ba7e79e1fc992d681d97af1c5cdda348a8dcb","unresolved":false,"context_lines":[{"line_number":286,"context_line":".. todo:: How do we communicate to the owners that their instance now has a"},{"line_number":287,"context_line":"   ``vtpm_secret_security`` policy set, and they they can either do an action on"},{"line_number":288,"context_line":"   their instance to opt in to this new policy, or either do nothing or delete"},{"line_number":289,"context_line":"   their instance if they disagree?"},{"line_number":290,"context_line":""},{"line_number":291,"context_line":"Implementation"},{"line_number":292,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":11,"id":"9f5f8054_d48582f1","line":289,"in_reply_to":"3a24c8b8_23cc87ac","updated":"2025-01-10 15:52:08.000000000","message":"we are going to cover this with a diffent spec","commit_id":"ffca3fe48dd2aa8ef4b4bf1fc953b695586c294c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4fc47bd7b1a34432e1becad8380a717f55d01c39","unresolved":true,"context_lines":[{"line_number":286,"context_line":".. todo:: How do we communicate to the owners that their instance now has a"},{"line_number":287,"context_line":"   ``vtpm_secret_security`` policy set, and they they can either do an action on"},{"line_number":288,"context_line":"   their instance to opt in to this new policy, or either do nothing or delete"},{"line_number":289,"context_line":"   their instance if they disagree?"},{"line_number":290,"context_line":""},{"line_number":291,"context_line":"Implementation"},{"line_number":292,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":11,"id":"3a24c8b8_23cc87ac","line":289,"in_reply_to":"6f0d9ce2_b8efe5d9","updated":"2025-01-09 20:18:23.000000000","message":"well we do we jsut dont dispaly it in server show.\n\nthat would also be very nice to add to server show but we proably need to pull that into a spec for next cycle.","commit_id":"ffca3fe48dd2aa8ef4b4bf1fc953b695586c294c"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"1cd6ce5d68a2ac757f01fa82895f2dfaee794c24","unresolved":true,"context_lines":[{"line_number":173,"context_line":"host\u0027s ``vtpm_secret_security`` policy persisted in its ``system_metadata``"},{"line_number":174,"context_line":"upon booting on that host."},{"line_number":175,"context_line":""},{"line_number":176,"context_line":"Operators ae able to specify what level they support by using the new"},{"line_number":177,"context_line":"``[compute]supported_vtpm_secret_security`` config option. This is a"},{"line_number":178,"context_line":"per compute host list option that can take the value of one or more of the"},{"line_number":179,"context_line":"security levels from the previous table. Its default value is all three levels."}],"source_content_type":"text/x-rst","patch_set":12,"id":"add316ed_01ae3fad","line":176,"range":{"start_line":176,"start_character":10,"end_line":176,"end_character":12},"updated":"2025-01-10 16:18:58.000000000","message":"\"are\"","commit_id":"d998ffd9cd10b29768bfd98ded0412ea5fc396ef"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"9c9857ea08e63013d0fc5b4dc7e3a6f55103f3cb","unresolved":true,"context_lines":[{"line_number":173,"context_line":"host\u0027s ``vtpm_secret_security`` policy persisted in its ``system_metadata``"},{"line_number":174,"context_line":"upon booting on that host."},{"line_number":175,"context_line":""},{"line_number":176,"context_line":"Operators ae able to specify what level they support by using the new"},{"line_number":177,"context_line":"``[compute]supported_vtpm_secret_security`` config option. This is a"},{"line_number":178,"context_line":"per compute host list option that can take the value of one or more of the"},{"line_number":179,"context_line":"security levels from the previous table. Its default value is all three levels."}],"source_content_type":"text/x-rst","patch_set":12,"id":"2ed550fe_c1e1514d","line":176,"range":{"start_line":176,"start_character":10,"end_line":176,"end_character":12},"updated":"2025-01-10 16:32:25.000000000","message":"are","commit_id":"d998ffd9cd10b29768bfd98ded0412ea5fc396ef"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"1cd6ce5d68a2ac757f01fa82895f2dfaee794c24","unresolved":true,"context_lines":[{"line_number":178,"context_line":"per compute host list option that can take the value of one or more of the"},{"line_number":179,"context_line":"security levels from the previous table. Its default value is all three levels."},{"line_number":180,"context_line":"These values are exposed as driver capability traits. The"},{"line_number":181,"context_line":"``hw_vtpm_secret_Security`` image property and flavor extra spec are translated"},{"line_number":182,"context_line":"to required traits to match the driver capabilities."},{"line_number":183,"context_line":""},{"line_number":184,"context_line":"The behavior of an instance during live migratioon is defined by its persisted"}],"source_content_type":"text/x-rst","patch_set":12,"id":"46ac2ac5_b319a79b","line":181,"range":{"start_line":181,"start_character":17,"end_line":181,"end_character":25},"updated":"2025-01-10 16:18:58.000000000","message":"un-caps","commit_id":"d998ffd9cd10b29768bfd98ded0412ea5fc396ef"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"9c9857ea08e63013d0fc5b4dc7e3a6f55103f3cb","unresolved":true,"context_lines":[{"line_number":181,"context_line":"``hw_vtpm_secret_Security`` image property and flavor extra spec are translated"},{"line_number":182,"context_line":"to required traits to match the driver capabilities."},{"line_number":183,"context_line":""},{"line_number":184,"context_line":"The behavior of an instance during live migratioon is defined by its persisted"},{"line_number":185,"context_line":"``hw_vtpm_secret_security`` (either explicitly set by the user, or added by"},{"line_number":186,"context_line":"default by Nova from the host\u0027s config option). Instances with ``user`` cannot"},{"line_number":187,"context_line":"be live migrated. For instances with ``host``, the source compute host reads"}],"source_content_type":"text/x-rst","patch_set":12,"id":"cf2eb452_52501a6f","line":184,"range":{"start_line":184,"start_character":40,"end_line":184,"end_character":50},"updated":"2025-01-10 16:32:25.000000000","message":"migration","commit_id":"d998ffd9cd10b29768bfd98ded0412ea5fc396ef"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"1cd6ce5d68a2ac757f01fa82895f2dfaee794c24","unresolved":true,"context_lines":[{"line_number":262,"context_line":"`\u003cProposed change_\u003e_` section. Any instances without this set are pre-existing"},{"line_number":263,"context_line":"instances, and need to be upgraded. They are upgraded to the value of the"},{"line_number":264,"context_line":"``[compute]default_vtpm_secret_security`` value. Just persisting this in their"},{"line_number":265,"context_line":"``system_metadata`` is not enough - their owner also needs to performa an"},{"line_number":266,"context_line":"operation with their token on the instance so that Nova can either convert the"},{"line_number":267,"context_line":"Libvirt secret to non-private and persistent in the case of ``host``, or create"},{"line_number":268,"context_line":"a new Barbican secret with the same contents, but owned by the Nova service"}],"source_content_type":"text/x-rst","patch_set":12,"id":"38c17b49_2652c142","line":265,"range":{"start_line":265,"start_character":62,"end_line":265,"end_character":70},"updated":"2025-01-10 16:18:58.000000000","message":"\"perform\"","commit_id":"d998ffd9cd10b29768bfd98ded0412ea5fc396ef"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"76f092ab97f8cb73884d00f3896a9ca7309f2c27","unresolved":true,"context_lines":[{"line_number":296,"context_line":"#. Introduce the ``hw_vtpm_secret_security``, ``hw:vtpm_secret_security``,"},{"line_number":297,"context_line":"   ``[compute]vtpm_secret_security``, and"},{"line_number":298,"context_line":"   ``[compute]default_vtpm_secret_security`` image properties, flavor extra"},{"line_number":299,"context_line":"   specs, and config options."},{"line_number":300,"context_line":"#. Modify the pre live migration and rollback code to handle secret definition"},{"line_number":301,"context_line":"   and cleanup."},{"line_number":302,"context_line":"#. Bump the service version."}],"source_content_type":"text/x-rst","patch_set":12,"id":"573be8af_19879da6","line":299,"updated":"2025-01-10 20:38:12.000000000","message":"Also the ``[compute]supported_vtpm_secret_security`` config option.","commit_id":"d998ffd9cd10b29768bfd98ded0412ea5fc396ef"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"76f092ab97f8cb73884d00f3896a9ca7309f2c27","unresolved":true,"context_lines":[{"line_number":305,"context_line":"   bumped version."},{"line_number":306,"context_line":"#. Add a whitebox/integration test."},{"line_number":307,"context_line":"#. Update the documentation."},{"line_number":308,"context_line":""},{"line_number":309,"context_line":"Dependencies"},{"line_number":310,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":311,"context_line":""}],"source_content_type":"text/x-rst","patch_set":12,"id":"ac45b96e_7cae344c","line":308,"updated":"2025-01-10 20:38:12.000000000","message":"Adding and exposing driver capability traits will also be a work item IIUC","commit_id":"d998ffd9cd10b29768bfd98ded0412ea5fc396ef"}]}