13:01:10 #startmeeting image_encryption 13:01:11 Meeting started Mon Jul 15 13:01:10 2019 UTC and is due to finish in 60 minutes. The chair is Luzi. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:01:12 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:01:14 The meeting name has been set to 'image_encryption' 13:01:19 o/ 13:01:25 #topic Roll Call 13:01:32 o/ 13:01:44 o/ 13:02:47 hi everyone 13:02:48 o/ 13:05:07 yough 13:05:10 I have pinged Barbican and Cinder folks 13:05:39 Luzi: eharney has a conflict this week, but said he will read through the meeting logs 13:06:03 ah thanks for the info rosmaita 13:06:06 (i have a conflict and will disappear at 13:20) 13:08:04 well i wanted to talk about the Barbican Consumer API first, but no one is here at this point 13:08:19 #topic Barbican Consumer API Update 13:09:02 for the key handling in Glance, and now also Nova, we depend on the Consumer API of Barbican 13:09:26 #link https://review.opendev.org/#/c/662013/ 13:09:52 the spec was merged but I am not sure who is working on it, right now 13:11:22 I will ask them about it tomorrow in the Barbican meeting 13:11:48 #topic Image Encryption Specs 13:13:18 Since the Summit, we edited all Specs, especially the nova one. 13:14:28 I would like to gather all open questions here, because most of them should be addressed in all specs. 13:14:35 I'll look at the nova one again today 13:14:54 If Sean is happy with the changes since my last upvote, I should be able to +2 it. 13:15:15 Luzi: You'll want to hunt down another core at that point. 13:16:08 thanks efried, I will do that. this meeting is also intended to get more people involved and reading / knowing about what we are doing :) 13:16:09 do you remember who you talked to in Denver about this? johnthetubaguy or dansmith would be good reviewers -- esp. if either one of them is familiar with the topic from the PTG. 13:17:05 (FYI mriedem is out this week) 13:17:56 i doubt that :D i seem to always get different nova developers to talk to :D 13:19:20 for everyone else, we added a slightly adjusted key-handling to the nova spec to also cover server shelve and cross-cell resize - in these cases temporary images could also be encrypted 13:19:51 But that ^ encryption is temporary and the key is not provided by or visible to the user, right? 13:21:35 (i have to leave, will read through the meeting log; thanks for organizing this, Luzi) 13:22:38 efried, it is a little bit more complex but can be also used for a simple snapshot 13:22:56 a.k.a. server image create 13:24:09 Luzi: Forgive my ignorance, but how are 'barbican' and 'castellan' related? 13:24:59 you can look at it this way: castellan is the oslo-library to provide a key-storage-backend, which is Barbican 13:25:33 an access abstraction layer basically 13:26:36 ah, okay. I remember looking at this a few years ago, and barbican was ripped out of nova in favor of castellan, so that makes sense 13:26:56 castellan itself doesn't have a service-types-authority entry 13:27:42 But also, there are no configurables in nova for barbican. E.g. a way to provide creds to the service, declare where the endpoint is, etc. 13:27:52 is any of that going to be necessary for the image encryption effort? 13:28:26 (Apologies if this is in the spec -- it's been a couple of weeks since I read it last.) 13:28:46 efried, see https://docs.openstack.org/ocata/config-reference/compute/config-options.html 13:28:56 there are options for Barbican endpoint etc. 13:29:02 still in Stein 13:29:19 e.g. "barbican_endpoint" 13:30:13 and it definitely works :D 13:30:32 * mhen confirms this 13:31:00 aha, now I see we're importing castellan options 13:31:30 https://opendev.org/openstack/nova/src/branch/master/nova/conf/key_manager.py 13:33:08 but we're not allowing any customization? 13:33:26 ah, that set_defaults thing is setting them up. 13:34:05 blam https://docs.openstack.org/nova/latest/configuration/config.html#key-manager 13:35:01 where are these coming from? https://docs.openstack.org/nova/latest/configuration/config.html#barbican 13:35:01 o/ 13:35:47 The reason I'm getting into this is because we'd like to be using common keystoneauth1 options and creating a ksa Adapter for services like this. 13:36:49 ...and soon using openstacksdk Connection instead. 13:37:39 well, I don't know how Barbican can / will handle this, but I yould also ask them that tomorrow 13:37:43 Anyone know what openstacksdk affordance for barbican looks like these days? 13:38:15 i didn't look into openstacksdk after it was clear, that we have to use another library 13:39:03 "use another library"? 13:39:54 for the encryption and decryption code 13:40:12 as cinder will not use openstacksdk 13:40:32 os_brick is what we are looking into right now 13:44:27 Well I would really like to talk to eharny about the cinder part again, maybe I will have to join the cinder meeting 13:44:42 jungleboyj is here, can he address? 13:45:07 I am here, but eharney is the one with the concerns. 13:45:13 Luzi: You mean all the encryption/decryption will be brokered by some other library, like os_brick, even from nova flows? 13:45:36 efried: I think that was what we talked about at the PTG. 13:45:47 yes one part 13:45:52 Rather than creating some new library since both already use it. 13:46:04 so where do the conf options live (auth etc)? 13:46:40 Do we load that stuff up from nova.conf and pass it down into os_brick? Or does os_brick have its own central conf that it loads up so the admin only has to fill that stuff out once? 13:46:50 efried, because the encryption and decryption is needed in noca, cinder and a potential client (and ironic later on) - we would really like to use a library 13:47:14 yeah, I like that idea. 13:47:16 efried, the auth and key retrieval part from Barbican will still happen in Nova 13:47:21 efried: That is a good question. os_brick doesn't have its own conf right now. 13:47:37 right, so this is my point 13:47:49 if we're needing to use keys from multiple different places 13:47:59 only the specific decryption/encryption process will be handled by the library, but the key will have been already acquired by that point 13:48:57 Okay, so each project (nova, cinder, ironic) that ties into this flow will need its own, separate, duplicate conf for barbican to retrieve the keys. And then those get passed into the os-brick methods. 13:49:15 efried, correct 13:49:18 that's not ideal ux 13:49:19 but 13:49:32 I see how it's potentially better than asking os-brick to do the key retrieval? 13:49:54 also 13:50:13 I guess the agents for nova/cinder/ironic/etc might not even be running on the same host 13:51:14 Okay, so coming full circle: nova (among others) is going to have to talk to barbican to do its key retrieval, and then pass that key down into these os-brick methods. 13:51:27 so what would be neat is if nova could use common ksa-isms to talk to barbican 13:51:35 and/or openstacksdk 13:51:36 os-brick doesn't really know anything about the services per say, and shouldn't 13:51:39 it's a standalone lib 13:52:01 anything that os-brick needs should get passed in to do it's work 13:52:25 I think I (finally) understand that now :) 13:52:48 it's consumed by the services as a lib, basically 13:52:52 efried, pardon my ignorance but what does "ksa-isms" refer to? 13:56:37 mhen: keystoneauth1 is a library that provides a common set of classes (various *Auth subclasses for auth, Session for http, and Adapter for catalog/endpoint/versioning/etc) 13:57:39 as of several years ago, nova was set up to talk to various services (cinder, ironic, glance, neutron, ...) through their clients, with wildly differing config opts for each 13:57:56 so we did some work to make them all use common conf options from keystoneauth1 13:58:26 ah I see, that does make sense 13:58:28 so that the admin would be able to have one way to set up their conf for those various services. 13:58:39 (they still have to set up those same conf options for each service) 13:59:00 we got a good start of everything except cinder... and barbican 13:59:27 and now, we're doing some work to cut over to openstacksdk 13:59:37 and cutting out the clients entirely 13:59:52 but that's (currently) dependent on the services supporting keystoneauth1 conf 14:00:05 which barbican (as I'm now discovering, pawing through the code) clearly does not. 14:00:46 anyway 14:00:50 I think this is a separate issue 14:00:58 we clearly have to support the legacy configuration for barbican anyway 14:01:16 but if you are going to be using the existing barbican conf 14:01:31 you're going to be sharing with the ephemeral lvm encryption that's already in place for libvirt. 14:01:49 efried, that's exactly what we are doing currently 14:01:59 and... is that okay? 14:02:05 intentional, by design? 14:02:59 I don't see any issue with that, we are only sharing the connection to Barbican - the access control is still done through the user's token 14:03:30 well we are already over the time 14:03:51 thank you all for joining, we can also talk in another channel 14:03:52 sorry I hijacked the meeting 14:04:00 #endmeeting image_encryption