| *** jaosorior has quit IRC | 01:20 | |
| *** jaosorior has joined #openstack-barbican | 01:32 | |
| *** whoami-rajat has joined #openstack-barbican | 02:01 | |
| *** ade_lee has quit IRC | 03:33 | |
| *** dave-mccowan has quit IRC | 04:44 | |
| *** Luzi has joined #openstack-barbican | 06:54 | |
| *** dpawlik has joined #openstack-barbican | 07:30 | |
| *** Luzi has quit IRC | 08:18 | |
| *** Luzi has joined #openstack-barbican | 08:32 | |
| *** pcaruana has joined #openstack-barbican | 08:35 | |
| *** arunkant has quit IRC | 09:35 | |
| *** arunkant has joined #openstack-barbican | 09:36 | |
| *** dpawlik has quit IRC | 10:05 | |
| *** dpawlik has joined #openstack-barbican | 11:37 | |
| *** Luzi has quit IRC | 11:54 | |
| *** Luzi has joined #openstack-barbican | 11:55 | |
| openstackgerrit | Ghanshyam Mann proposed openstack/barbican master: Set Tempest's service_availability setting for Barbican https://review.openstack.org/639153 | 12:04 |
|---|---|---|
| *** raildo has joined #openstack-barbican | 12:16 | |
| *** dayou has quit IRC | 12:30 | |
| *** dpawlik has quit IRC | 12:30 | |
| *** openstackgerrit has quit IRC | 12:30 | |
| *** dpawlik has joined #openstack-barbican | 12:31 | |
| *** dayou has joined #openstack-barbican | 12:32 | |
| *** dpawlik has quit IRC | 12:50 | |
| *** graeb has joined #openstack-barbican | 12:59 | |
| redrobot | #startmeeting barbican | 13:01 |
| 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 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 13:01 |
| *** openstack changes topic to " (Meeting topic: barbican)" | 13:01 | |
| openstack | The meeting name has been set to 'barbican' | 13:01 |
| graeb | o/ | 13:01 |
| redrobot | #topic Roll Call | 13:02 |
| *** openstack changes topic to "Roll Call (Meeting topic: barbican)" | 13:02 | |
| redrobot | Courtesy ping for ade_lee hrybacki jamespage Luzi lxkong moguimar raildo rm_work xek | 13:02 |
| Luzi | o/ | 13:02 |
| redrobot | As usual our agenda can be found here: | 13:02 |
| rm_work | o/ | 13:02 |
| redrobot | #link https://etherpad.openstack.org/p/barbican-weekly-meeting | 13:03 |
| redrobot | Good mornin' y'all! | 13:03 |
| * redrobot is moving a little slow from lack of coffee | 13:03 | |
| redrobot | Still awake rm_work ? | 13:04 |
| redrobot | Ok, let's get started | 13:04 |
| redrobot | #topic Action Items from last meeting | 13:04 |
| *** openstack changes topic to "Action Items from last meeting (Meeting topic: barbican)" | 13:04 | |
| moguimar | o/ | 13:04 |
| redrobot | #link http://eavesdrop.openstack.org/meetings/barbican/2019/barbican.2019-02-19-13.00.html | 13:04 |
| redrobot | There was only one action item | 13:05 |
| redrobot | redrobot to follow up with Ade about Castellan Feature Freeze this Friday | 13:05 |
| redrobot | I did look into that. | 13:05 |
| redrobot | Thanks to moguimar we got a Castellan release | 13:05 |
| moguimar | thanks to bnemec =P | 13:05 |
| moguimar | I think he released it yesterday | 13:06 |
| redrobot | #link https://pypi.org/project/castellan/#history | 13:06 |
| redrobot | moguimar, :) | 13:06 |
| redrobot | moguimar, looks like it was 13 hours ago | 13:07 |
| redrobot | probably still warm from the oven | 13:07 |
| moguimar | so not yesterday in my local time xD | 13:07 |
| redrobot | And that reminds me | 13:07 |
| redrobot | let's talk about Castellan | 13:07 |
| redrobot | #topic Castellan | 13:07 |
| *** openstack changes topic to "Castellan (Meeting topic: barbican)" | 13:07 | |
| redrobot | I honestly don't think Castellan is ready for prod use | 13:08 |
| redrobot | My main concern is about how much access a single instance of Castellan has to a Vault backend | 13:08 |
| redrobot | Originally we needed a root token, which is an anti-pattern | 13:09 |
| jamespage | anything specific? that was the purpose of some of my changes re approle and backend configuration options | 13:09 |
| 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:09 |
| moguimar | well, it doesn't need to be a root token | 13:10 |
| 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 |
| jamespage | no its a token issued via the approle, which will have a very specific policy for access if done correctly | 13:10 |
| rm_work | check-box security :P | 13:10 |
| redrobot | jamespage, but the Vault backend still stores secrets under /kv/XXXXXXX | 13:11 |
| redrobot | jamespage, so nothing else can use that same backend | 13:11 |
| jamespage | kv mounts are inexpensive so giving each castellan consuming app a different KV backend provides a level of segregation | 13:11 |
| redrobot | unless I'm completely misunderstanding approles | 13:11 |
| moguimar | if you use it read only, you can have better policy for tokens | 13:11 |
| moguimar | but there is no way to predict new secret ids to get policies to match that | 13:12 |
| moguimar | unless we can change the mount point | 13:12 |
| moguimar | and there is no option to update a secret | 13:12 |
| redrobot | jamespage, hmm... does typical use of Vault include creating dozens of KV mountpoints? | 13:12 |
| redrobot | because each app that uses Castellan would need its own KV mountpoint to get its own policy | 13:13 |
| 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 |
| moguimar | depends on what you call mount point | 13:13 |
| redrobot | #link https://review.openstack.org/#/c/638742/ | 13:13 |
| jamespage | well not dozens | 13:13 |
| jamespage | some - in my use case its 2 | 13:14 |
| moguimar | you can mount to secrets/vm-0001 | 13:14 |
| redrobot | let's say I wanted to keep my octavia and cinder secrets separate so that each service cannot access the other | 13:14 |
| redrobot | right now I'd nead once KV mountpoint for each one. | 13:14 |
| moguimar | secrets/octavia and secrets/cinder | 13:15 |
| moguimar | different tokens with different policies | 13:15 |
| jamespage | I think the point is that barbican is providing that isolation, not vault | 13:15 |
| redrobot | well, now it would be octavia/ and cider/ right now. IIRC. secrets/ is the default KV mountpoint. | 13:15 |
| jamespage | the KV is associated to barbican via castellan | 13:15 |
| redrobot | Castellan is typically used when you don't want to use Barbican though | 13:16 |
| jamespage | right - so in that case you would have a KV mountpoint for each castellan consumer | 13:16 |
| redrobot | which brings me to point #2 why Castellan is not ready for prod: | 13:16 |
| redrobot | right, which would result in potentially dozens of mountpoints ... | 13:17 |
| moguimar | so you wanna state that on the project readme? | 13:17 |
| redrobot | with that patch I linked you could have arbitrary paths in a single KV mountpoint | 13:17 |
| rm_work | i don't know that it's "if you don't want barbican" | 13:17 |
| rm_work | it's a way to be generic | 13:17 |
| moguimar | rm_work +1 | 13:17 |
| rm_work | so people CAN use barbican ... OR just vault | 13:17 |
| rm_work | depending on their needs | 13:17 |
| moguimar | or be ready for the next one to come | 13:17 |
| rm_work | some providers really don't need to enforce that level of isolation | 13:18 |
| redrobot | so you could have a policy for secrets/cinder/* and secrets/octavia/*, etc | 13:18 |
| rm_work | IE, non-public-clouds, with basically one group using it | 13:18 |
| *** dpawlik has joined #openstack-barbican | 13: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 |
| redrobot | Heh yea | 13:19 |
| redrobot | but then why not use simple crypto? | 13:19 |
| redrobot | in any case, point #2 | 13:20 |
| redrobot | Castellan behaves differently if you have Barbican vs Vault backends | 13:20 |
| jamespage | I agree that the security of the backend is entirely dependent on the approles, policy and backend configuration | 13:20 |
| redrobot | jamespage, do you think being able to use arbitrary paths for secret storage is helpful? | 13:20 |
| redrobot | i.e. not stuffing everything in root | 13:20 |
| 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:21 |
| jamespage | some level of isolation between apps is good; however whether thats N KV mountpoints or subpaths within a single KV mountpoint | 13:22 |
| redrobot | cool, I'm going to continue working on that patch | 13:22 |
| jamespage | the security is related to the paths applied via policy to the approle | 13:22 |
| jamespage | rather than the use of distinct mountpoints | 13:22 |
| 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 |
| jamespage | redrobot: I think your patch is a useful enhancement but not a blocker for marking castellan/vault as ready for production | 13:23 |
| redrobot | that's just point #1 :) | 13:23 |
| redrobot | point #2: | 13:23 |
| redrobot | Castellan behaves differently when using Barbican backend vs Vault backend | 13:23 |
| redrobot | most notably, the Vault backend completely ignores the context being passed in | 13:24 |
| jamespage | OK this is an implementation detail I'm not familiar with | 13:24 |
| redrobot | #link https://bugs.launchpad.net/castellan/+bug/1776989 | 13:24 |
| openstack | Launchpad bug 1776989 in castellan "Vault backend does not check contex for authorization" [Medium,New] - Assigned to Douglas Mendizábal (dougmendizabal) | 13:24 |
| redrobot | #link http://git.openstack.org/cgit/openstack/castellan/tree/castellan/key_manager/vault_key_manager.py#n330 | 13:25 |
| redrobot | Right now it checks that a context was passed in, but doesn't do anything with it | 13:25 |
| redrobot | I can literally pass in the string 'bogus' as the context and the Vault backend doesn't care. | 13:26 |
| rm_work | i mean, isn't the point of using barbican partially the integration with openstack auth mechanisms like keystone and such? | 13:26 |
| redrobot | Also, we had this bug which was fixed by moguimar: | 13:26 |
| rm_work | without it... there IS no auth that can be done? | 13:27 |
| rm_work | I thought | 13:27 |
| moguimar | 🧐 we have a context object, LGTM | 13:27 |
| rm_work | what is in that / what would it check with? | 13:27 |
| moguimar | that's the vault km | 13:27 |
| redrobot | #link https://bugs.launchpad.net/castellan/+bug/1817248 | 13:27 |
| 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:27 |
| redrobot | Honestly, there is no way to fix that. It's got keystone roles and suck | 13:28 |
| redrobot | *such | 13:28 |
| redrobot | that Vault would not be able to use anyway | 13:28 |
| redrobot | the only way to fix it is to remove the context from the interface altogether | 13:29 |
| redrobot | which brings me to point #3 | 13:29 |
| * moguimar needs to read the barbican km | 13:29 | |
| redrobot | I don't think there's a way to write code that can use both Vault or Barbican right now. | 13:29 |
| redrobot | Cinder/Octavia only work because Vault ignores the context | 13:30 |
| rm_work | hmmm i thought octavia could | 13:30 |
| rm_work | ah | 13:30 |
| rm_work | lolk | 13:30 |
| redrobot | and because they both have easy access to either 1) their own keystone credentials or 2) the request context | 13: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 |
| 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:30 |
| redrobot | IOW the credential factory does not work with the Vault backend | 13:31 |
| redrobot | #link http://git.openstack.org/cgit/openstack/castellan/tree/castellan/common/utils.py#n95 | 13:31 |
| redrobot | right now it only checks for keystone bits in the config | 13:31 |
| redrobot | In any case, I just wanted to put this out there so folks can start thinking about it for the Denver Summit | 13:32 |
| * jamespage thinks | 13:34 | |
| jamespage | alot | 13:34 |
| 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:34 |
| redrobot | #link https://governance.openstack.org/tc/reference/base-services.html#current-list-of-base-services | 13:35 |
| moguimar | will the barbican km survive without the context? | 13:35 |
| redrobot | unfortunately that would be a backwards-incompatible change. | 13:35 |
| 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:36 |
| rm_work | if castellan starts supporting keystone auth and such ... wouldn't that just ... make it barbican? | 13:37 |
| redrobot | rm_work, right, that's why I'm pushing for getting rid of context in Castellan :) | 13:37 |
| rm_work | lolk | 13:37 |
| 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 |
| redrobot | Anyway... food for thought... I'm sure y'all will have awesome ideas next time we talk about this. | 13:38 |
| redrobot | rm_work, haha, yes | 13:38 |
| redrobot | ok, moving on | 13:38 |
| redrobot | #topic Denver Forum Sessions - Ideas, etc | 13:39 |
| *** openstack changes topic to "Denver Forum Sessions - Ideas, etc (Meeting topic: barbican)" | 13:39 | |
| redrobot | Obvs, we should definitely take some time to talk about Castellan | 13:39 |
| redrobot | we desperately need better gate tests | 13:39 |
| redrobot | esp. tests that will find discrepancies between different backends | 13:39 |
| rm_work | yeah, testing leaves some things to be desired | 13:40 |
| rm_work | i recently ran into some unit tests that are really not unit tests <_< | 13:40 |
| rm_work | (dogtag tests) | 13:40 |
| redrobot | I was shocked no one ever found that bits vs bytes issue | 13:40 |
| redrobot | rm_work, heh | 13:40 |
| 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 |
| redrobot | I mean we _do_ want to unit test that backend | 13:41 |
| rm_work | and explode if you don't have *configuration properly set* | 13:41 |
| rm_work | yes but not by connecting to one? <_< | 13:41 |
| redrobot | lol, ok that's bad | 13:41 |
| rm_work | maybe mocks lol | 13:41 |
| rm_work | like normal units | 13:41 |
| rm_work | put the existing ones in functional if you want | 13:41 |
| redrobot | sounds good to me | 13:41 |
| rm_work | anyway, you can replicate -- run units, go into the tox env, install the dogtag lib, and then try running tests | 13:41 |
| rm_work | it explodes at *discovery* | 13:42 |
| redrobot | rm_work, wanna add a story to storyboard to track it? | 13:42 |
| rm_work | not really :P | 13:43 |
| rm_work | but uhh | 13:43 |
| rm_work | I guess I could maybe | 13:43 |
| redrobot | 😁😁😁 | 13:43 |
| redrobot | #action rm_work to add a story about fixing the dogtag unit tests | 13:43 |
| redrobot | Any other ideas for Denver Forum Sessions? | 13:44 |
| rm_work | hmmm not sure what went through / if i missed anything, just got bumped when my VPN died | 13:44 |
| rm_work | i was trying to say "not really, but i guess i could maybe do that" :P | 13:45 |
| redrobot | rm_work, all you missed was me assigning an action item to you for doing that | 13:46 |
| rm_work | kk | 13:46 |
| rm_work | maybe i'll even remember when i wake up ;) | 13:46 |
| redrobot | Oh man, I guess we could talk about content-types :trollface: | 13:46 |
| redrobot | but really though, content types are still a mess | 13:47 |
| redrobot | especially when it comes to the cli | 13:47 |
| redrobot | and I'd like to deprecate defaulting to opaque in the cli at some point | 13:47 |
| redrobot | because I have a feeling EVERYTHING EVERYONE STORES is opaque at this point | 13:47 |
| redrobot | do y'all have things to talk about at the summit? | 13:48 |
| redrobot | ~summit~ forum? | 13:48 |
| * redrobot thinks his slack-fu is showing | 13:48 | |
| rm_work | lol not really from me | 13:49 |
| 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:49 |
| redrobot | right on | 13:50 |
| redrobot | oh another Castellan point | 13:50 |
| 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 |
| redrobot | moguimar, reminded me about hvac the other day | 13:50 |
| * redrobot looks | 13:50 | |
| 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:51 |
| redrobot | ok, well, keep thinking about the Forum and possible topics | 13:52 |
| redrobot | and we can re-visit it next week | 13:52 |
| redrobot | #topic Open Discussion | 13:52 |
| *** openstack changes topic to "Open Discussion (Meeting topic: barbican)" | 13:52 | |
| redrobot | any other topics? | 13:52 |
| rm_work | ah, the one i put there ^^ | 13:52 |
| rm_work | jumped the gun a minute | 13:52 |
| redrobot | rm_work, added to my review queue | 13:52 |
| redrobot | seems pretty straight-forward | 13:53 |
| *** dave-mccowan has joined #openstack-barbican | 13:54 | |
| * redrobot waves at dave-mccowan | 13:54 | |
| 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 |
| dave-mccowan | hi redrobot | 13:55 |
| redrobot | dave-mccowan, you caught the tail-end of the meeting | 13:55 |
| redrobot | dave-mccowan, any last minute topics? | 13:55 |
| dave-mccowan | nothing from me | 13:55 |
| redrobot | cool cool | 13:56 |
| redrobot | ok, just about out of time | 13:58 |
| redrobot | thanks for coming everyone! | 13:58 |
| redrobot | #endmeeting | 13:58 |
| *** openstack changes topic to "OpenStack PTG Denver - https://etherpad.openstack.org/p/barbican-stein-ptg" | 13:58 | |
| openstack | Meeting ended Tue Feb 26 13:58:33 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 13:58 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/barbican/2019/barbican.2019-02-26-13.01.html | 13:58 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/barbican/2019/barbican.2019-02-26-13.01.txt | 13:58 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/barbican/2019/barbican.2019-02-26-13.01.log.html | 13:58 |
| cmurphy | redrobot: hi, can you help me with my request above ^ it's starting to feel like we're going to have to carry this patch forever | 14:06 |
| redrobot | hi cmurphy | 14:07 |
| redrobot | cmurphy, oh dang, sorry I missed that | 14:07 |
| redrobot | cmurphy, I'll take a look right now | 14:07 |
| cmurphy | thanks so much redrobot | 14:08 |
| *** ade_lee has joined #openstack-barbican | 14:25 | |
| *** dave-mccowan has quit IRC | 14:34 | |
| *** Luzi has quit IRC | 15:17 | |
| *** dpawlik has quit IRC | 16:11 | |
| *** dave-mccowan has joined #openstack-barbican | 16:28 | |
| *** jmlowe has quit IRC | 16:32 | |
| *** pcaruana has quit IRC | 16:32 | |
| *** graeb has quit IRC | 16:42 | |
| *** moguimar has quit IRC | 16:59 | |
| *** jmlowe has joined #openstack-barbican | 17:40 | |
| *** dayou has quit IRC | 19:20 | |
| *** dayou has joined #openstack-barbican | 19:21 | |
| *** jmlowe has quit IRC | 20:49 | |
| *** jmlowe has joined #openstack-barbican | 21:06 | |
| ade_lee | redrobot, ping | 21:29 |
| redrobot | ade_lee, pong | 21:29 |
| ade_lee | redrobot, so right now the pkek rewrap happens even if the old and new labels are the same | 21:30 |
| redrobot | ade_lee, yeah, that's a lot of wasted effort | 21:30 |
| ade_lee | redrobot, I think we want to add a check to see if they are the same or not -- and if so, not do it | 21:30 |
| ade_lee | of course - if the wrapping is somehow messed up , we might want a force mode to do it anyways | 21:31 |
| ade_lee | of course if the wrpping is messed up , then we'll just get gibberish .. | 21:31 |
| ade_lee | on the decode .. | 21:31 |
| ade_lee | redrobot, so - ok (and not api breaking) to make it check and skip by default? | 21:32 |
| *** raildo has quit IRC | 21:33 | |
| redrobot | ade_lee, I don't think so. I'd say it's a bug in the implementation | 21:33 |
| ade_lee | ok cool | 21:33 |
| *** whoami-rajat has quit IRC | 21:41 | |
| ade_lee | redrobot, didn't you say someone reported rewrap being broken somehow ? | 21:44 |
| ade_lee | redrobot, as part of the hsm changes we made? | 21:45 |
| ade_lee | redrobot, I think you said Luzi reported something? | 21:45 |
| ade_lee | maybe for safenet | 21:45 |
| redrobot | ade_lee, https://review.openstack.org/#/c/635736/ | 21:47 |
| redrobot | It's Utimaco HSM | 21:48 |
| ade_lee | redrobot, gotcha | 21:49 |
| ade_lee | redrobot, we should prob review this soon .. | 21:49 |
| *** openstackgerrit has joined #openstack-barbican | 22:19 | |
| openstackgerrit | Ade Lee proposed openstack/barbican master: Make rewrap not rewrap needlessly https://review.openstack.org/639455 | 22:19 |
| ade_lee | redrobot, ^^ | 22:19 |
| *** dave-mccowan has quit IRC | 22:33 | |
| *** dave-mccowan has joined #openstack-barbican | 23:19 | |
| *** ade_lee has quit IRC | 23:27 | |
| *** ade_lee has joined #openstack-barbican | 23:56 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!