| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-02-26 | |||
| 17:24:31 | dansmith | the what? | |
| 17:24:51 | sean-k-mooney | heavy weight | |
| 17:25:05 | sean-k-mooney | the dnm test just changes the tempest flvoars to make all vms use encyption | |
| 17:25:20 | sean-k-mooney | but since the flavor has ephmeral root and swap | |
| 17:25:26 | sean-k-mooney | it slows down the job | |
| 17:26:05 | sean-k-mooney | if we dont already have a job with barbican i would ike to have at least one so we can test cinder volume encyption and vtpm in that job too | |
| 17:26:21 | sean-k-mooney | i have not checked if we have any job today with barbican in our gate | |
| 17:29:23 | melwitt | I think we don't, so that's kind of the main thing is how do we want to add barbican | |
| 17:30:45 | melwitt | add it to an existing job like nova-next and then set a feature flag to run limited encryption tests? | |
| 17:30:59 | dansmith | yeah, something | |
| 17:31:09 | dansmith | or maybe nova-lvm since it's kinda relatedish? | |
| 17:31:36 | sean-k-mooney | not really since this feature wont support lvm | |
| 17:31:40 | sean-k-mooney | at least not in this release | |
| 17:31:56 | dansmith | meaning we can't do this underneath an lvm-backed nova? | |
| 17:32:15 | dansmith | I meant it's related to a more complex ephemeral disk layout | |
| 17:32:20 | sean-k-mooney | correct the serise is currently for qcow, raw and rbd | |
| 17:32:33 | sean-k-mooney | lvm could be supproted but not in the current serise | |
| 17:32:47 | dansmith | and we fail in that scenario how? | |
| 17:32:59 | sean-k-mooney | it does not report the triat saying we supprot this | |
| 17:33:21 | sean-k-mooney | so an lvm cloud will have no valid host or select a non lvm node if they eexist and supprot it | |
| 17:33:34 | dansmith | okay so if you have all LVM-backed nodes and you ask for this, nothing will be bootable | |
| 17:33:44 | sean-k-mooney | there is a per image backend SUPPORTS_LUKS flag | |
| 17:33:56 | sean-k-mooney | correct | |
| 17:34:52 | sean-k-mooney | if we assume this is enabeld in the falvor rahter then the imge | |
| 17:35:12 | sean-k-mooney | the presence of an encypted flavor tells you the operator has configured an approate backedn | |
| 17:35:17 | sean-k-mooney | (or they think they have) | |
| 17:35:29 | sean-k-mooney | but as an end user you cant tell form the api if this will work without trying it | |
| 17:35:46 | sean-k-mooney | i.e. if you wanted to enabel it in the image | |
| 17:35:46 | dansmith | there's a comment in one of the files that says otherwise | |
| 17:35:53 | dansmith | which I asked if it was correct | |
| 17:36:19 | dansmith | made it sound like you could request this via the block device or something, but I haven't gotten that far up the stack to know if that's true or not | |
| 17:36:22 | sean-k-mooney | you can use the old epmeral encyption feature in the lvm backend | |
| 17:37:13 | sean-k-mooney | but i belive that is config file based and not flavor/image based | |
| 17:39:55 | melwitt | yeah the existing ephemeral encryption is for the lvm backend only and it works via config options | |
| 17:45:32 | dansmith | so the comment is wrong yeah? | |
| 17:46:17 | dansmith | also, I'm sure ceph has some inbuilt encryption stuff right? I would assume luks encryption on top of rbd would be almost not-production-quality poor in terms of performance | |
| 17:46:24 | dansmith | is that not the case? | |
| 17:47:49 | melwitt | sorry, which comment? | |
| 17:49:04 | dansmith | one of my comments on the second patch | |
| 17:49:10 | dansmith | about a comment in the code that says the user can request a format | |
| 17:51:19 | melwitt | there is some inbuilt encryption stuff in ceph but as of the current stable release Quincy it doesn't support fast clone of encrypted disks and having a passphrase that's different than the parent. so there's a release note (on the rbd backend patch) stating that. for the performance, I would not be surprised if people wouldn't want to use it given the absence of fast clone. but I wasn't sure if it should be left out entirely bc of that | |
| 17:52:34 | dansmith | okay but fast clone can't be used here either right? | |
| 17:53:11 | melwitt | oh, yeah there's the flavor extra spec hw:ephemeral_encryption_format which is the only way to request a format but currently we're not supporting anything other than 'luks' | |
| 17:53:13 | dansmith | in fact, I'm not even sure how you could go from a non-encrypted base image to a root disk that uses encryption with this unless we flatten it when we create the instance | |
| 17:53:30 | sean-k-mooney | i honestly would not really think luks vs not logs would matter too much to rbd. its providing a block laywer device we are jsut creating a luks partion on that block device | |
| 17:53:50 | dansmith | okay that's not quite "the user" for a flavor, but will that be honored from an image? | |
| 17:54:38 | sean-k-mooney | flatening the image for rbd | |
| 17:54:45 | sean-k-mooney | yes | |
| 17:54:58 | dansmith | and qcow/ | |
| 17:55:26 | sean-k-mooney | qcow could share backing files for the same user on the same host | |
| 17:55:36 | dansmith | but not from a public image right? | |
| 17:55:37 | melwitt | fast clone would be for taking snapshots | |
| 17:55:50 | sean-k-mooney | and if the base qcow is not encypted we can share the backing file as normal | |
| 17:56:32 | sean-k-mooney | dansmith: mels serise supprot taking a non encypted qcow and then creating an encypted root disk | |
| 17:56:58 | dansmith | by flattening or does qemu handle only writing the delta as encrypted? | |
| 17:57:11 | melwitt | yes there is hw_ephemeral_encryption_format as an image property as wel | |
| 17:57:32 | dansmith | melwitt: ack, just seems a bit too behind-the-curtain to me | |
| 17:57:58 | dansmith | melwitt: that's not asking for anything that will affect the hardware in the guest (like numa or something), but rather only controls what is happening under the covers | |
| 17:58:20 | dansmith | that's okay for flavor, but wrong for image (and user-controllable to me).. | |
| 17:58:42 | sean-k-mooney | i belvie we create a seperate encypted backing file but reuse the image cache to copy the data | |
| 17:58:42 | sean-k-mooney | i would have to check again | |
| 17:58:49 | bauzas | folks, that discussion seems highly important for me to understand all of the meat, but I need to end my day :( | |
| 17:59:08 | bauzas | make sure I'll read the logs tomorrow when I'm back and crazy enough to start reviewing again | |
| 17:59:11 | dansmith | sean-k-mooney: okay I was expecting you can't mix those two things.. | |
| 17:59:18 | melwitt | it can also take encrypted qcow and share an encrypted backing file. otherwise in something like taking a snapshot of an encrypted instance and then booting other instances from that snapshot, you would have to make a copy of the encrypted backing file which would make it not cow | |
| 17:59:36 | melwitt | (near the end of the series encrypted backing file support is added for qcow2) | |
| 17:59:39 | dansmith | perhaps you can and qemu only encrypts the delta, but I kinda expected it was all or nothing | |
| 17:59:57 | dansmith | melwitt: right, but with different keys? | |
| 18:00:15 | melwitt | dansmith: the backing file will be the same key, the deltas will all be different keys | |
| 18:00:57 | dansmith | melwitt: okay so you can configure a key per layer? I'm not sure how that works because you tell libvirt "here's my qcow disk" and that disk references the base image, | |
| 18:01:11 | melwitt | dansmith: yes you can | |
| 18:01:15 | dansmith | so unless you stash the key for the base image in the delta/snapshot disk, I'm not sure how libvirt/qemu would know | |
| 18:01:22 | dansmith | melwitt: okay, in the libvirt xml? | |
| 18:01:32 | melwitt | dansmith: yes | |
| 18:01:48 | dansmith | okay, normally you don't have to tell libvirt about the base layers, so I've never seen what that looks like | |
| 18:01:54 | melwitt | there is a backingStore xml element which can have a <encryption> element under it | |
| 18:02:02 | dansmith | ah, okay, cool | |
| 18:02:18 | melwitt | yeah, you don't have to tell me lol ... it's all pretty much undocumented so figuring that out was fun | |
| 18:02:27 | dansmith | ack | |
| 18:03:25 | dansmith | yeah I literally don't see it in the libvirt docs | |
| 18:04:01 | melwitt | I learned a lot from old bugzillas I found with google. there might be one example somewhere in the docs, checking | |
| 18:04:03 | dansmith | "Note that the 'qcow' format of encryption is broken" | |
| 18:04:09 | dansmith | does that mean qcow and not qcow2? | |
| 18:05:10 | dansmith | oh, they mean qcow encryption not encryption with qcow I think | |
| 18:05:12 | melwitt | that is a different encryption (I know, helpful). it means the original legacy implementation of encryption in qemu. which was replaced with the new one that is being used in the series now | |
| 18:05:55 | melwitt | unless maybe you're reading a different doc than the qemu ones | |
| 18:06:05 | dansmith | boy, yeah I don't see any example of multiple layers of encryption | |
| 18:07:13 | dansmith | but, when you put the backingstore in there, the deepest one is the lowest layer in the stack it looks like | |
| 18:07:24 | melwitt | this is what it looks like without encryption https://libvirt.org/kbase/backing_chains.html#advanced-backing-chain-specifications | |
| 18:07:55 | melwitt | and encryption is really just sticking the <encryption> element under each backingStore if that layer is encrypted | |
| 18:08:29 | dansmith | aha yeah | |
| 18:08:59 | dansmith | and presumably if a layer doesn't have an <enc> then it's cleartext and not inherited from the parent ... | |
| 18:09:08 | melwitt | thankfully we're only dealing with two layers | |
| 18:09:13 | dansmith | yeah | |
| 18:09:49 | melwitt | this is one of the bugzillas I used to learn it https://bugzilla.redhat.com/show_bug.cgi?id=1788898 | |
| 18:10:15 | melwitt | yeah, that's my understanding | |
| 18:10:26 | dansmith | melwitt: I assume you're in the middle of replying to my comments on that second patch right? | |
| 18:11:13 | dansmith | I'm specifically interested in the key reuse one, since that seems like a -1 | |
| 18:11:14 | sean-k-mooney | yeah net split is over? | |
| 18:11:14 | melwitt | yes | |