13:01:50 <redrobot> #startmeeting barbican
13:01:51 <openstack> Meeting started Tue Feb 26 13:01:50 2019 UTC and is due to finish in 60 minutes.  The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:01:52 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:01:54 <openstack> The meeting name has been set to 'barbican'
13:01:59 <graeb> o/
13:02:01 <redrobot> #topic Roll Call
13:02:22 <redrobot> Courtesy ping for ade_lee hrybacki jamespage Luzi lxkong moguimar raildo rm_work xek
13:02:33 <Luzi> o/
13:02:49 <redrobot> As usual our agenda can be found here:
13:02:54 <rm_work> o/
13:03:02 <redrobot> #link https://etherpad.openstack.org/p/barbican-weekly-meeting
13:03:38 <redrobot> Good mornin' y'all!
13:03:51 * redrobot is moving a little slow from lack of coffee
13:04:27 <redrobot> Still awake rm_work ?
13:04:34 <redrobot> Ok, let's get started
13:04:43 <redrobot> #topic Action Items from last meeting
13:04:48 <moguimar> o/
13:04:57 <redrobot> #link http://eavesdrop.openstack.org/meetings/barbican/2019/barbican.2019-02-19-13.00.html
13:05:05 <redrobot> There was only one action item
13:05:22 <redrobot> redrobot to follow up with Ade about Castellan Feature Freeze this Friday
13:05:35 <redrobot> I did look into that.
13:05:44 <redrobot> Thanks to moguimar we got a Castellan release
13:05:54 <moguimar> thanks to bnemec =P
13:06:15 <moguimar> I think he released it yesterday
13:06:47 <redrobot> #link https://pypi.org/project/castellan/#history
13:06:55 <redrobot> moguimar, :)
13:07:01 <redrobot> moguimar, looks like it was 13 hours ago
13:07:06 <redrobot> probably still warm from the oven
13:07:28 <moguimar> so not yesterday in my local time xD
13:07:43 <redrobot> And that reminds me
13:07:53 <redrobot> let's talk about Castellan
13:07:56 <redrobot> #topic Castellan
13:08:26 <redrobot> I honestly don't think Castellan is ready for prod use
13:08:48 <redrobot> My main concern is about how much access a single instance of Castellan has to a Vault backend
13:09:06 <redrobot> Originally we needed a root token, which is an anti-pattern
13:09:17 <jamespage> anything specific? that was the purpose of some of my changes re approle and backend configuration options
13:09:52 <redrobot> jamespage, my main concern is that even with the approle, a single instance of Castellan still needs read/write access to the root of a KV mount
13:10:04 <moguimar> well, it doesn't need to be a root token
13:10:20 <rm_work> i think people don't want security -- they want to say they are using "industry acceptable security" and move on with having a working cloud, lol
13:10:29 <jamespage> no its a token issued via the approle, which will have a very specific policy for access if done correctly
13:10:51 <rm_work> check-box security :P
13:11:19 <redrobot> jamespage, but the Vault backend still stores secrets under /kv/XXXXXXX
13:11:30 <redrobot> jamespage, so nothing else can use that same backend
13:11:39 <jamespage> kv mounts are inexpensive so giving each castellan consuming app a different KV backend provides a level of segregation
13:11:40 <redrobot> unless I'm completely misunderstanding approles
13:11:43 <moguimar> if you use it read only, you can have better policy for tokens
13:12:06 <moguimar> but there is no way to predict new secret ids to get policies to match that
13:12:18 <moguimar> unless we can change the mount point
13:12:40 <moguimar> and there is no option to update a secret
13:12:59 <redrobot> jamespage, hmm... does typical use of Vault include creating dozens of KV mountpoints?
13:13:30 <redrobot> because each app that uses Castellan would need its own KV mountpoint to get its own policy
13:13:50 <redrobot> I was working on a patch to get path support so that Castellan doesn't stuff everything in the root of the KV
13:13:50 <moguimar> depends on what you call mount point
13:13:52 <redrobot> #link https://review.openstack.org/#/c/638742/
13:13:54 <jamespage> well not dozens
13:14:08 <jamespage> some - in my use case its 2
13:14:27 <moguimar> you can mount to secrets/vm-0001
13:14:37 <redrobot> let's say I wanted to keep my octavia and cinder secrets separate so that each service cannot access the other
13:14:44 <redrobot> right now I'd nead once KV mountpoint for each one.
13:15:05 <moguimar> secrets/octavia and secrets/cinder
13:15:14 <moguimar> different tokens with different policies
13:15:33 <jamespage> I think the point is that barbican is providing that isolation, not vault
13:15:38 <redrobot> well, now it would be octavia/ and cider/ right now. IIRC.  secrets/ is the default KV mountpoint.
13:15:43 <jamespage> the KV is associated to barbican via castellan
13:16:02 <redrobot> Castellan is typically used when you don't want to use Barbican though
13:16:29 <jamespage> right - so in that case you would have a KV mountpoint for each castellan consumer
13:16:29 <redrobot> which brings me to point #2 why Castellan is not ready for prod:
13:17:09 <redrobot> right, which would result in potentially dozens of mountpoints ...
13:17:10 <moguimar> so you wanna state that on the project readme?
13:17:20 <redrobot> with that patch I linked you could have arbitrary paths in a single KV mountpoint
13:17:23 <rm_work> i don't know that it's "if you don't want barbican"
13:17:25 <rm_work> it's a way to be generic
13:17:40 <moguimar> rm_work +1
13:17:42 <rm_work> so people CAN use barbican ... OR just vault
13:17:51 <rm_work> depending on their needs
13:17:56 <moguimar> or be ready for the next one to come
13:18:01 <rm_work> some providers really don't need to enforce that level of isolation
13:18:17 <redrobot> so you could have a policy for secrets/cinder/* and secrets/octavia/*, etc
13:18:17 <rm_work> IE, non-public-clouds, with basically one group using it
13:19:19 <rm_work> which comes back to, some deployers really don't care about security so long as they can say 'we tried', or maybe really they just want SOMETHING to work
13:19:46 <redrobot> Heh yea
13:19:56 <redrobot> but then why not use simple crypto?
13:20:00 <redrobot> in any case, point #2
13:20:11 <redrobot> Castellan behaves differently if you have Barbican vs Vault backends
13:20:13 <jamespage> I agree that the security of the backend is entirely dependent on the approles, policy and backend configuration
13:20:41 <redrobot> jamespage, do you think being able to use arbitrary paths for secret storage is helpful?
13:20:52 <redrobot> i.e. not stuffing everything in root
13:21:43 <redrobot> seems less costly to me to add a new path + policy when adding a new castellan+vault client than adding a new KV mountpoint
13:22:07 <jamespage> some level of isolation between apps is good; however whether thats N KV mountpoints or subpaths within a single KV mountpoint
13:22:32 <redrobot> cool, I'm going to continue working on that patch
13:22:34 <jamespage> the security is related to the paths applied via policy to the approle
13:22:44 <jamespage> rather than the use of distinct mountpoints
13:23:14 <redrobot> yeah, I think not being able to specify an arbitrary path is an issue, since it does force you to have to add N mountpoints.
13:23:19 <jamespage> redrobot: I think your patch is a useful enhancement but not a blocker for marking castellan/vault as ready for production
13:23:31 <redrobot> that's just point #1 :)
13:23:37 <redrobot> point #2:
13:23:49 <redrobot> Castellan behaves differently when using Barbican backend vs Vault backend
13:24:03 <redrobot> most notably, the Vault backend completely ignores the context being passed in
13:24:26 <jamespage> OK this is an implementation detail I'm not familiar with
13:24:53 <redrobot> #link https://bugs.launchpad.net/castellan/+bug/1776989
13:24:54 <openstack> Launchpad bug 1776989 in castellan "Vault backend does not check contex for authorization" [Medium,New] - Assigned to Douglas Mendizábal (dougmendizabal)
13:25:38 <redrobot> #link http://git.openstack.org/cgit/openstack/castellan/tree/castellan/key_manager/vault_key_manager.py#n330
13:25:58 <redrobot> Right now it checks that a context was passed in, but doesn't do anything with it
13:26:16 <redrobot> I can literally pass in the string 'bogus' as the context and the Vault backend doesn't care.
13:26:57 <rm_work> i mean, isn't the point of using barbican partially the integration with openstack auth mechanisms like keystone and such?
13:26:58 <redrobot> Also, we had this bug which was fixed by moguimar:
13:27:05 <rm_work> without it... there IS no auth that can be done?
13:27:06 <rm_work> I thought
13:27:07 <moguimar> 🧐 we have a context object, LGTM
13:27:20 <rm_work> what is in that / what would it check with?
13:27:22 <moguimar> that's the vault km
13:27:54 <redrobot> #link https://bugs.launchpad.net/castellan/+bug/1817248
13:27:55 <openstack> Launchpad bug 1817248 in castellan "KeyManager.create_key length parameter is ambiguous" [High,Fix released] - Assigned to Moisés Guimarães de Medeiros (moguimar)
13:28:38 <redrobot> Honestly, there is no way to fix that.  It's got keystone roles and suck
13:28:40 <redrobot> *such
13:28:47 <redrobot> that Vault would not be able to use anyway
13:29:00 <redrobot> the only way to fix it is to remove the context from the interface altogether
13:29:18 <redrobot> which brings me to point #3
13:29:26 * moguimar needs to read the barbican km
13:29:52 <redrobot> I don't think there's a way to write code that can use both Vault or Barbican right now.
13:30:02 <redrobot> Cinder/Octavia only work because Vault ignores the context
13:30:04 <rm_work> hmmm i thought octavia could
13:30:06 <rm_work> ah
13:30:07 <rm_work> lolk
13:30:25 <redrobot> and because they both have easy access to either 1) their own keystone credentials or 2) the request context
13:30:30 <rm_work> though to be fair it's entirely theoretical, i don't think anyone has actually TRIED the driver i wrote :P
13:30:55 <redrobot> but, if I wanted to write an app that has to instantiate a context of its own and uses the Vault backend it wouldn't work
13:31:42 <redrobot> IOW the credential factory does not work with the Vault backend
13:31:43 <redrobot> #link http://git.openstack.org/cgit/openstack/castellan/tree/castellan/common/utils.py#n95
13:31:53 <redrobot> right now it only checks for keystone bits in the config
13:32:25 <redrobot> In any case, I just wanted to put this out there so folks can start thinking about it for the Denver Summit
13:34:18 * jamespage thinks
13:34:49 <jamespage> alot
13:34:57 <redrobot> I think removing the context from the interface may be the right thing to do... and it's more in-line with what the TC thinks Castellan should be
13:35:41 <redrobot> #link https://governance.openstack.org/tc/reference/base-services.html#current-list-of-base-services
13:35:44 <moguimar> will the barbican km survive without the context?
13:35:50 <redrobot> unfortunately that would be a backwards-incompatible change.
13:36:27 <redrobot> moguimar, yes, it would mean that Castellan->Barbican would behave more like Castellan->Vault where all secrets stored would be owned by a single account
13:37:00 <rm_work> if castellan starts supporting keystone auth and such ... wouldn't that just ... make it barbican?
13:37:25 <redrobot> rm_work, right, that's why I'm pushing for getting rid of context in Castellan :)
13:37:33 <rm_work> lolk
13:38:01 <rm_work> yeah it seems a little bit like people are remaking barbican bits at a time by committee without realizing it, because they didn't like barbican for some reason :D
13:38:07 <redrobot> Anyway... food for thought... I'm sure y'all will have awesome ideas next time we talk about this.
13:38:30 <redrobot> rm_work, haha, yes
13:38:41 <redrobot> ok, moving on
13:39:15 <redrobot> #topic Denver Forum Sessions - Ideas, etc
13:39:29 <redrobot> Obvs, we should definitely take some time to talk about Castellan
13:39:44 <redrobot> we desperately need better gate tests
13:39:57 <redrobot> esp. tests that will find discrepancies between different backends
13:40:17 <rm_work> yeah, testing leaves some things to be desired
13:40:29 <rm_work> i recently ran into some unit tests that are really not unit tests <_<
13:40:34 <rm_work> (dogtag tests)
13:40:44 <redrobot> I was shocked no one ever found that bits vs bytes issue
13:40:58 <redrobot> rm_work, heh
13:41:07 <rm_work> if you happen to have the dogtag libs installed, it will try to run against a real dogtag instance in the *unit tests*
13:41:14 <redrobot> I mean we _do_ want to unit test that backend
13:41:18 <rm_work> and explode if you don't have *configuration properly set*
13:41:26 <rm_work> yes but not by connecting to one? <_<
13:41:27 <redrobot> lol, ok that's bad
13:41:34 <rm_work> maybe mocks lol
13:41:36 <rm_work> like normal units
13:41:42 <rm_work> put the existing ones in functional if you want
13:41:51 <redrobot> sounds good to me
13:41:57 <rm_work> anyway, you can replicate -- run units, go into the tox env, install the dogtag lib, and then try running tests
13:42:03 <rm_work> it explodes at *discovery*
13:42:59 <redrobot> rm_work, wanna add a story to storyboard to track it?
13:43:18 <rm_work> not really :P
13:43:20 <rm_work> but uhh
13:43:33 <rm_work> I guess I could maybe
13:43:37 <redrobot> 😁😁😁
13:43:51 <redrobot> #action rm_work to add a story about fixing the dogtag unit tests
13:44:13 <redrobot> Any other ideas for Denver Forum Sessions?
13:44:53 <rm_work> hmmm not sure what went through / if i missed anything, just got bumped when my VPN died
13:45:49 <rm_work> i was trying to say "not really, but i guess i could maybe do that" :P
13:46:06 <redrobot> rm_work, all you missed was me assigning an action item to you for doing that
13:46:14 <rm_work> kk
13:46:26 <rm_work> maybe i'll even remember when i wake up ;)
13:46:49 <redrobot> Oh man, I guess we could talk about content-types :trollface:
13:47:02 <redrobot> but really though, content types are still a mess
13:47:12 <redrobot> especially when it comes to the cli
13:47:29 <redrobot> and I'd like to deprecate defaulting to opaque in the cli at some point
13:47:46 <redrobot> because I have a feeling EVERYTHING EVERYONE STORES is opaque at this point
13:48:27 <redrobot> do y'all have things to talk about at the summit?
13:48:32 <redrobot> ~summit~ forum?
13:48:57 * redrobot thinks his slack-fu is showing
13:49:13 <rm_work> lol not really from me
13:49:56 <rm_work> i'm mostly doing upgrade projects at the moment, across all of cloud <_< so unable to focus much on specific projects. but
13:50:08 <redrobot> right on
13:50:19 <redrobot> oh another Castellan point
13:50:20 <rm_work> i had one thing i wanted to put out there -- https://review.openstack.org/#/c/638526/ :D pretty sure it works -- was surprised this wasn't done a while ago. not a priority though.
13:50:27 <redrobot> moguimar, reminded me about hvac the other day
13:50:36 * redrobot looks
13:51:02 <redrobot> so I think long term we may want to rewrite the Vault backend using hvac, so that we're not maintaining our own Vault client
13:52:14 <redrobot> ok, well, keep thinking about the Forum and possible topics
13:52:19 <redrobot> and we can re-visit it next week
13:52:35 <redrobot> #topic Open Discussion
13:52:38 <redrobot> any other topics?
13:52:48 <rm_work> ah, the one i put there ^^
13:52:56 <rm_work> jumped the gun a minute
13:52:59 <redrobot> rm_work, added to my review queue
13:53:09 <redrobot> seems pretty straight-forward
13:54:46 * redrobot waves at dave-mccowan
13:55:04 <cmurphy> hello, I'm wondering (again) if we could get any feedback (positive or negative) on this bugfix https://review.openstack.org/544557
13:55:08 <dave-mccowan> hi redrobot
13:55:22 <redrobot> dave-mccowan, you caught the tail-end of the meeting
13:55:28 <redrobot> dave-mccowan, any last minute topics?
13:55:53 <dave-mccowan> nothing from me
13:56:55 <redrobot> cool cool
13:58:16 <redrobot> ok, just about out of time
13:58:26 <redrobot> thanks for coming everyone!
13:58:33 <redrobot> #endmeeting