13:01:10 <Luzi> #startmeeting image_encryption
13:01:11 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:01:14 <openstack> The meeting name has been set to 'image_encryption'
13:01:19 <efried> o/
13:01:25 <Luzi> #topic Roll Call
13:01:32 <gagehugo> o/
13:01:44 <rosmaita> o/
13:02:47 <Luzi> hi everyone
13:02:48 <mhen> o/
13:05:07 <hemna> yough
13:05:10 <Luzi> I have pinged Barbican and Cinder folks
13:05:39 <rosmaita> Luzi: eharney has a conflict this week, but said he will read through the meeting logs
13:06:03 <Luzi> ah thanks for the info rosmaita
13:06:06 <rosmaita> (i have a conflict and will disappear at 13:20)
13:08:04 <Luzi> well i wanted to talk about the Barbican Consumer API first, but no one is here at this point
13:08:19 <Luzi> #topic Barbican Consumer API Update
13:09:02 <Luzi> for the key handling in Glance, and now also Nova, we depend on the Consumer API of Barbican
13:09:26 <Luzi> #link https://review.opendev.org/#/c/662013/
13:09:52 <Luzi> the spec was merged but I am not sure who is working on it, right now
13:11:22 <Luzi> I will ask them about it tomorrow in the Barbican meeting
13:11:48 <Luzi> #topic Image Encryption Specs
13:13:18 <Luzi> Since the Summit, we edited all Specs, especially the nova one.
13:14:28 <Luzi> I would like to gather all open questions here, because most of them should be addressed in all specs.
13:14:35 <efried> I'll look at the nova one again today
13:14:54 <efried> If Sean is happy with the changes since my last upvote, I should be able to +2 it.
13:15:15 <efried> Luzi: You'll want to hunt down another core at that point.
13:16:08 <Luzi> 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 <efried> 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 <efried> (FYI mriedem is out this week)
13:17:56 <Luzi> i doubt that :D i seem to always get different nova developers to talk to :D
13:19:20 <Luzi> 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 <efried> But that ^ encryption is temporary and the key is not provided by or visible to the user, right?
13:21:35 <rosmaita> (i have to leave, will read through the meeting log; thanks for organizing this, Luzi)
13:22:38 <Luzi> efried, it is a little bit more complex but can be also used for a simple snapshot
13:22:56 <Luzi> a.k.a. server image create
13:24:09 <efried> Luzi: Forgive my ignorance, but how are 'barbican' and 'castellan' related?
13:24:59 <Luzi> you can look at it this way: castellan is the oslo-library to provide a key-storage-backend, which is Barbican
13:25:33 <Luzi> an access abstraction layer basically
13:26:36 <efried> 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 <efried> castellan itself doesn't have a service-types-authority entry
13:27:42 <efried> 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 <efried> is any of that going to be necessary for the image encryption effort?
13:28:26 <efried> (Apologies if this is in the spec -- it's been a couple of weeks since I read it last.)
13:28:46 <mhen> efried, see https://docs.openstack.org/ocata/config-reference/compute/config-options.html
13:28:56 <mhen> there are options for Barbican endpoint etc.
13:29:02 <Luzi> still in Stein
13:29:19 <mhen> e.g. "barbican_endpoint"
13:30:13 <Luzi> and it definitely works :D
13:30:32 * mhen confirms this
13:31:00 <efried> aha, now I see we're importing castellan options
13:31:30 <efried> https://opendev.org/openstack/nova/src/branch/master/nova/conf/key_manager.py
13:33:08 <efried> but we're not allowing any customization?
13:33:26 <efried> ah, that set_defaults thing is setting them up.
13:34:05 <efried> blam https://docs.openstack.org/nova/latest/configuration/config.html#key-manager
13:35:01 <efried> where are these coming from? https://docs.openstack.org/nova/latest/configuration/config.html#barbican
13:35:01 <jungleboyj> o/
13:35:47 <efried> 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 <efried> ...and soon using openstacksdk Connection instead.
13:37:39 <Luzi> well, I don't know how Barbican can / will handle this, but I yould also ask them that tomorrow
13:37:43 <efried> Anyone know what openstacksdk affordance for barbican looks like these days?
13:38:15 <Luzi> i didn't look into openstacksdk after it was clear, that we have to use another library
13:39:03 <efried> "use another library"?
13:39:54 <Luzi> for the encryption and decryption code
13:40:12 <Luzi> as cinder will not use openstacksdk
13:40:32 <Luzi> os_brick is what we are looking into right now
13:44:27 <Luzi> 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 <efried> jungleboyj is here, can he address?
13:45:07 <jungleboyj> I am here, but eharney is the one with the concerns.
13:45:13 <efried> Luzi: You mean all the encryption/decryption will be brokered by some other library, like os_brick, even from nova flows?
13:45:36 <jungleboyj> efried:  I think that was what we talked about at the PTG.
13:45:47 <Luzi> yes one part
13:45:52 <jungleboyj> Rather than creating some new library since both already use it.
13:46:04 <efried> so where do the conf options live (auth etc)?
13:46:40 <efried> 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 <Luzi> 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 <efried> yeah, I like that idea.
13:47:16 <mhen> efried, the auth and key retrieval part from Barbican will still happen in Nova
13:47:21 <jungleboyj> efried:  That is a good question.  os_brick doesn't have its own conf right now.
13:47:37 <efried> right, so this is my point
13:47:49 <efried> if we're needing to use keys from multiple different places
13:47:59 <mhen> 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 <efried> 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 <mhen> efried, correct
13:49:18 <efried> that's not ideal ux
13:49:19 <efried> but
13:49:32 <efried> I see how it's potentially better than asking os-brick to do the key retrieval?
13:49:54 <efried> also
13:50:13 <efried> I guess the agents for nova/cinder/ironic/etc might not even be running on the same host
13:51:14 <efried> 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 <efried> so what would be neat is if nova could use common ksa-isms to talk to barbican
13:51:35 <efried> and/or openstacksdk
13:51:36 <hemna> os-brick doesn't really know anything about the services per say, and shouldn't
13:51:39 <hemna> it's a standalone lib
13:52:01 <hemna> anything that os-brick needs should get passed in to do it's work
13:52:25 <efried> I think I (finally) understand that now :)
13:52:48 <hemna> it's consumed by the services as a lib, basically
13:52:52 <mhen> efried, pardon my ignorance but what does "ksa-isms" refer to?
13:56:37 <efried> 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 <efried> 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 <efried> so we did some work to make them all use common conf options from keystoneauth1
13:58:26 <Luzi> ah I see, that does make sense
13:58:28 <efried> so that the admin would be able to have one way to set up their conf for those various services.
13:58:39 <efried> (they still have to set up those same conf options for each service)
13:59:00 <efried> we got a good start of everything except cinder... and barbican
13:59:27 <efried> and now, we're doing some work to cut over to openstacksdk
13:59:37 <efried> and cutting out the clients entirely
13:59:52 <efried> but that's (currently) dependent on the services supporting keystoneauth1 conf
14:00:05 <efried> which barbican (as I'm now discovering, pawing through the code) clearly does not.
14:00:46 <efried> anyway
14:00:50 <efried> I think this is a separate issue
14:00:58 <efried> we clearly have to support the legacy configuration for barbican anyway
14:01:16 <efried> but if you are going to be using the existing barbican conf
14:01:31 <efried> you're going to be sharing with the ephemeral lvm encryption that's already in place for libvirt.
14:01:49 <mhen> efried, that's exactly what we are doing currently
14:01:59 <efried> and... is that okay?
14:02:05 <efried> intentional, by design?
14:02:59 <mhen> 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 <Luzi> well we are already over the time
14:03:51 <Luzi> thank you all for joining, we can also talk in another channel
14:03:52 <efried> sorry I hijacked the meeting
14:04:00 <Luzi> #endmeeting image_encryption