Tuesday, 2019-02-26

*** jaosorior has quit IRC01:20
*** jaosorior has joined #openstack-barbican01:32
*** whoami-rajat has joined #openstack-barbican02:01
*** ade_lee has quit IRC03:33
*** dave-mccowan has quit IRC04:44
*** Luzi has joined #openstack-barbican06:54
*** dpawlik has joined #openstack-barbican07:30
*** Luzi has quit IRC08:18
*** Luzi has joined #openstack-barbican08:32
*** pcaruana has joined #openstack-barbican08:35
*** arunkant has quit IRC09:35
*** arunkant has joined #openstack-barbican09:36
*** dpawlik has quit IRC10:05
*** dpawlik has joined #openstack-barbican11:37
*** Luzi has quit IRC11:54
*** Luzi has joined #openstack-barbican11:55
openstackgerritGhanshyam Mann proposed openstack/barbican master: Set Tempest's service_availability setting for Barbican  https://review.openstack.org/63915312:04
*** raildo has joined #openstack-barbican12:16
*** dayou has quit IRC12:30
*** dpawlik has quit IRC12:30
*** openstackgerrit has quit IRC12:30
*** dpawlik has joined #openstack-barbican12:31
*** dayou has joined #openstack-barbican12:32
*** dpawlik has quit IRC12:50
*** graeb has joined #openstack-barbican12:59
redrobot#startmeeting barbican13:01
openstackMeeting 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
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.13:01
*** openstack changes topic to " (Meeting topic: barbican)"13:01
openstackThe meeting name has been set to 'barbican'13:01
graebo/13:01
redrobot#topic Roll Call13:02
*** openstack changes topic to "Roll Call (Meeting topic: barbican)"13:02
redrobotCourtesy ping for ade_lee hrybacki jamespage Luzi lxkong moguimar raildo rm_work xek13:02
Luzio/13:02
redrobotAs usual our agenda can be found here:13:02
rm_worko/13:02
redrobot#link https://etherpad.openstack.org/p/barbican-weekly-meeting13:03
redrobotGood mornin' y'all!13:03
* redrobot is moving a little slow from lack of coffee13:03
redrobotStill awake rm_work ?13:04
redrobotOk, let's get started13:04
redrobot#topic Action Items from last meeting13:04
*** openstack changes topic to "Action Items from last meeting (Meeting topic: barbican)"13:04
moguimaro/13:04
redrobot#link http://eavesdrop.openstack.org/meetings/barbican/2019/barbican.2019-02-19-13.00.html13:04
redrobotThere was only one action item13:05
redrobotredrobot to follow up with Ade about Castellan Feature Freeze this Friday13:05
redrobotI did look into that.13:05
redrobotThanks to moguimar we got a Castellan release13:05
moguimarthanks to bnemec =P13:05
moguimarI think he released it yesterday13:06
redrobot#link https://pypi.org/project/castellan/#history13:06
redrobotmoguimar, :)13:06
redrobotmoguimar, looks like it was 13 hours ago13:07
redrobotprobably still warm from the oven13:07
moguimarso not yesterday in my local time xD13:07
redrobotAnd that reminds me13:07
redrobotlet's talk about Castellan13:07
redrobot#topic Castellan13:07
*** openstack changes topic to "Castellan (Meeting topic: barbican)"13:07
redrobotI honestly don't think Castellan is ready for prod use13:08
redrobotMy main concern is about how much access a single instance of Castellan has to a Vault backend13:08
redrobotOriginally we needed a root token, which is an anti-pattern13:09
jamespageanything specific? that was the purpose of some of my changes re approle and backend configuration options13:09
redrobotjamespage, 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 mount13:09
moguimarwell, it doesn't need to be a root token13:10
rm_worki think people don't want security -- they want to say they are using "industry acceptable security" and move on with having a working cloud, lol13:10
jamespageno its a token issued via the approle, which will have a very specific policy for access if done correctly13:10
rm_workcheck-box security :P13:10
redrobotjamespage, but the Vault backend still stores secrets under /kv/XXXXXXX13:11
redrobotjamespage, so nothing else can use that same backend13:11
jamespagekv mounts are inexpensive so giving each castellan consuming app a different KV backend provides a level of segregation13:11
redrobotunless I'm completely misunderstanding approles13:11
moguimarif you use it read only, you can have better policy for tokens13:11
moguimarbut there is no way to predict new secret ids to get policies to match that13:12
moguimarunless we can change the mount point13:12
moguimarand there is no option to update a secret13:12
redrobotjamespage, hmm... does typical use of Vault include creating dozens of KV mountpoints?13:12
redrobotbecause each app that uses Castellan would need its own KV mountpoint to get its own policy13:13
redrobotI was working on a patch to get path support so that Castellan doesn't stuff everything in the root of the KV13:13
moguimardepends on what you call mount point13:13
redrobot#link https://review.openstack.org/#/c/638742/13:13
jamespagewell not dozens13:13
jamespagesome - in my use case its 213:14
moguimaryou can mount to secrets/vm-000113:14
redrobotlet's say I wanted to keep my octavia and cinder secrets separate so that each service cannot access the other13:14
redrobotright now I'd nead once KV mountpoint for each one.13:14
moguimarsecrets/octavia and secrets/cinder13:15
moguimardifferent tokens with different policies13:15
jamespageI think the point is that barbican is providing that isolation, not vault13:15
redrobotwell, now it would be octavia/ and cider/ right now. IIRC.  secrets/ is the default KV mountpoint.13:15
jamespagethe KV is associated to barbican via castellan13:15
redrobotCastellan is typically used when you don't want to use Barbican though13:16
jamespageright - so in that case you would have a KV mountpoint for each castellan consumer13:16
redrobotwhich brings me to point #2 why Castellan is not ready for prod:13:16
redrobotright, which would result in potentially dozens of mountpoints ...13:17
moguimarso you wanna state that on the project readme?13:17
redrobotwith that patch I linked you could have arbitrary paths in a single KV mountpoint13:17
rm_worki don't know that it's "if you don't want barbican"13:17
rm_workit's a way to be generic13:17
moguimarrm_work +113:17
rm_workso people CAN use barbican ... OR just vault13:17
rm_workdepending on their needs13:17
moguimaror be ready for the next one to come13:17
rm_worksome providers really don't need to enforce that level of isolation13:18
redrobotso you could have a policy for secrets/cinder/* and secrets/octavia/*, etc13:18
rm_workIE, non-public-clouds, with basically one group using it13:18
*** dpawlik has joined #openstack-barbican13:19
rm_workwhich 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 work13:19
redrobotHeh yea13:19
redrobotbut then why not use simple crypto?13:19
redrobotin any case, point #213:20
redrobotCastellan behaves differently if you have Barbican vs Vault backends13:20
jamespageI agree that the security of the backend is entirely dependent on the approles, policy and backend configuration13:20
redrobotjamespage, do you think being able to use arbitrary paths for secret storage is helpful?13:20
redroboti.e. not stuffing everything in root13:20
redrobotseems less costly to me to add a new path + policy when adding a new castellan+vault client than adding a new KV mountpoint13:21
jamespagesome level of isolation between apps is good; however whether thats N KV mountpoints or subpaths within a single KV mountpoint13:22
redrobotcool, I'm going to continue working on that patch13:22
jamespagethe security is related to the paths applied via policy to the approle13:22
jamespagerather than the use of distinct mountpoints13:22
redrobotyeah, 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
jamespageredrobot: I think your patch is a useful enhancement but not a blocker for marking castellan/vault as ready for production13:23
redrobotthat's just point #1 :)13:23
redrobotpoint #2:13:23
redrobotCastellan behaves differently when using Barbican backend vs Vault backend13:23
redrobotmost notably, the Vault backend completely ignores the context being passed in13:24
jamespageOK this is an implementation detail I'm not familiar with13:24
redrobot#link https://bugs.launchpad.net/castellan/+bug/177698913:24
openstackLaunchpad 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#n33013:25
redrobotRight now it checks that a context was passed in, but doesn't do anything with it13:25
redrobotI can literally pass in the string 'bogus' as the context and the Vault backend doesn't care.13:26
rm_worki mean, isn't the point of using barbican partially the integration with openstack auth mechanisms like keystone and such?13:26
redrobotAlso, we had this bug which was fixed by moguimar:13:26
rm_workwithout it... there IS no auth that can be done?13:27
rm_workI thought13:27
moguimar🧐 we have a context object, LGTM13:27
rm_workwhat is in that / what would it check with?13:27
moguimarthat's the vault km13:27
redrobot#link https://bugs.launchpad.net/castellan/+bug/181724813:27
openstackLaunchpad 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
redrobotHonestly, there is no way to fix that.  It's got keystone roles and suck13:28
redrobot*such13:28
redrobotthat Vault would not be able to use anyway13:28
redrobotthe only way to fix it is to remove the context from the interface altogether13:29
redrobotwhich brings me to point #313:29
* moguimar needs to read the barbican km13:29
redrobotI don't think there's a way to write code that can use both Vault or Barbican right now.13:29
redrobotCinder/Octavia only work because Vault ignores the context13:30
rm_workhmmm i thought octavia could13:30
rm_workah13:30
rm_worklolk13:30
redrobotand because they both have easy access to either 1) their own keystone credentials or 2) the request context13:30
rm_workthough to be fair it's entirely theoretical, i don't think anyone has actually TRIED the driver i wrote :P13:30
redrobotbut, if I wanted to write an app that has to instantiate a context of its own and uses the Vault backend it wouldn't work13:30
redrobotIOW the credential factory does not work with the Vault backend13:31
redrobot#link http://git.openstack.org/cgit/openstack/castellan/tree/castellan/common/utils.py#n9513:31
redrobotright now it only checks for keystone bits in the config13:31
redrobotIn any case, I just wanted to put this out there so folks can start thinking about it for the Denver Summit13:32
* jamespage thinks13:34
jamespagealot13:34
redrobotI 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 be13:34
redrobot#link https://governance.openstack.org/tc/reference/base-services.html#current-list-of-base-services13:35
moguimarwill the barbican km survive without the context?13:35
redrobotunfortunately that would be a backwards-incompatible change.13:35
redrobotmoguimar, yes, it would mean that Castellan->Barbican would behave more like Castellan->Vault where all secrets stored would be owned by a single account13:36
rm_workif castellan starts supporting keystone auth and such ... wouldn't that just ... make it barbican?13:37
redrobotrm_work, right, that's why I'm pushing for getting rid of context in Castellan :)13:37
rm_worklolk13:37
rm_workyeah 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 :D13:38
redrobotAnyway... food for thought... I'm sure y'all will have awesome ideas next time we talk about this.13:38
redrobotrm_work, haha, yes13:38
redrobotok, moving on13:38
redrobot#topic Denver Forum Sessions - Ideas, etc13:39
*** openstack changes topic to "Denver Forum Sessions - Ideas, etc (Meeting topic: barbican)"13:39
redrobotObvs, we should definitely take some time to talk about Castellan13:39
redrobotwe desperately need better gate tests13:39
redrobotesp. tests that will find discrepancies between different backends13:39
rm_workyeah, testing leaves some things to be desired13:40
rm_worki recently ran into some unit tests that are really not unit tests <_<13:40
rm_work(dogtag tests)13:40
redrobotI was shocked no one ever found that bits vs bytes issue13:40
redrobotrm_work, heh13:40
rm_workif you happen to have the dogtag libs installed, it will try to run against a real dogtag instance in the *unit tests*13:41
redrobotI mean we _do_ want to unit test that backend13:41
rm_workand explode if you don't have *configuration properly set*13:41
rm_workyes but not by connecting to one? <_<13:41
redrobotlol, ok that's bad13:41
rm_workmaybe mocks lol13:41
rm_worklike normal units13:41
rm_workput the existing ones in functional if you want13:41
redrobotsounds good to me13:41
rm_workanyway, you can replicate -- run units, go into the tox env, install the dogtag lib, and then try running tests13:41
rm_workit explodes at *discovery*13:42
redrobotrm_work, wanna add a story to storyboard to track it?13:42
rm_worknot really :P13:43
rm_workbut uhh13:43
rm_workI guess I could maybe13:43
redrobot😁😁😁13:43
redrobot#action rm_work to add a story about fixing the dogtag unit tests13:43
redrobotAny other ideas for Denver Forum Sessions?13:44
rm_workhmmm not sure what went through / if i missed anything, just got bumped when my VPN died13:44
rm_worki was trying to say "not really, but i guess i could maybe do that" :P13:45
redrobotrm_work, all you missed was me assigning an action item to you for doing that13:46
rm_workkk13:46
rm_workmaybe i'll even remember when i wake up ;)13:46
redrobotOh man, I guess we could talk about content-types :trollface:13:46
redrobotbut really though, content types are still a mess13:47
redrobotespecially when it comes to the cli13:47
redrobotand I'd like to deprecate defaulting to opaque in the cli at some point13:47
redrobotbecause I have a feeling EVERYTHING EVERYONE STORES is opaque at this point13:47
redrobotdo y'all have things to talk about at the summit?13:48
redrobot~summit~ forum?13:48
* redrobot thinks his slack-fu is showing13:48
rm_worklol not really from me13:49
rm_worki'm mostly doing upgrade projects at the moment, across all of cloud <_< so unable to focus much on specific projects. but13:49
redrobotright on13:50
redrobotoh another Castellan point13:50
rm_worki 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
redrobotmoguimar, reminded me about hvac the other day13:50
* redrobot looks13:50
redrobotso I think long term we may want to rewrite the Vault backend using hvac, so that we're not maintaining our own Vault client13:51
redrobotok, well, keep thinking about the Forum and possible topics13:52
redrobotand we can re-visit it next week13:52
redrobot#topic Open Discussion13:52
*** openstack changes topic to "Open Discussion (Meeting topic: barbican)"13:52
redrobotany other topics?13:52
rm_workah, the one i put there ^^13:52
rm_workjumped the gun a minute13:52
redrobotrm_work, added to my review queue13:52
redrobotseems pretty straight-forward13:53
*** dave-mccowan has joined #openstack-barbican13:54
* redrobot waves at dave-mccowan 13:54
cmurphyhello, I'm wondering (again) if we could get any feedback (positive or negative) on this bugfix https://review.openstack.org/54455713:55
dave-mccowanhi redrobot13:55
redrobotdave-mccowan, you caught the tail-end of the meeting13:55
redrobotdave-mccowan, any last minute topics?13:55
dave-mccowannothing from me13:55
redrobotcool cool13:56
redrobotok, just about out of time13:58
redrobotthanks for coming everyone!13:58
redrobot#endmeeting13:58
*** openstack changes topic to "OpenStack PTG Denver - https://etherpad.openstack.org/p/barbican-stein-ptg"13:58
openstackMeeting ended Tue Feb 26 13:58:33 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)13:58
openstackMinutes:        http://eavesdrop.openstack.org/meetings/barbican/2019/barbican.2019-02-26-13.01.html13:58
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/barbican/2019/barbican.2019-02-26-13.01.txt13:58
openstackLog:            http://eavesdrop.openstack.org/meetings/barbican/2019/barbican.2019-02-26-13.01.log.html13:58
cmurphyredrobot: hi, can you help me with my request above ^ it's starting to feel like we're going to have to carry this patch forever14:06
redrobothi cmurphy14:07
redrobotcmurphy, oh dang, sorry I missed that14:07
redrobotcmurphy, I'll take a look right now14:07
cmurphythanks so much redrobot14:08
*** ade_lee has joined #openstack-barbican14:25
*** dave-mccowan has quit IRC14:34
*** Luzi has quit IRC15:17
*** dpawlik has quit IRC16:11
*** dave-mccowan has joined #openstack-barbican16:28
*** jmlowe has quit IRC16:32
*** pcaruana has quit IRC16:32
*** graeb has quit IRC16:42
*** moguimar has quit IRC16:59
*** jmlowe has joined #openstack-barbican17:40
*** dayou has quit IRC19:20
*** dayou has joined #openstack-barbican19:21
*** jmlowe has quit IRC20:49
*** jmlowe has joined #openstack-barbican21:06
ade_leeredrobot, ping21:29
redrobotade_lee, pong21:29
ade_leeredrobot, so right now the pkek rewrap happens even if the old and new labels are the same21:30
redrobotade_lee, yeah, that's a lot of wasted effort21:30
ade_leeredrobot, I think we want to add a check to see if they are the same or not -- and if so, not do it21:30
ade_leeof course - if the wrapping is somehow messed up , we might want a force mode to do it anyways21:31
ade_leeof course if the wrpping is messed up , then we'll just get gibberish ..21:31
ade_leeon the decode ..21:31
ade_leeredrobot, so - ok (and not api breaking) to make it check and skip by default?21:32
*** raildo has quit IRC21:33
redrobotade_lee, I don't think so.  I'd say it's a bug in the implementation21:33
ade_leeok cool21:33
*** whoami-rajat has quit IRC21:41
ade_leeredrobot, didn't you say someone reported rewrap being broken somehow ?21:44
ade_leeredrobot, as part of the hsm changes we made?21:45
ade_leeredrobot, I think you said Luzi reported something?21:45
ade_leemaybe for safenet21:45
redrobotade_lee, https://review.openstack.org/#/c/635736/21:47
redrobotIt's Utimaco HSM21:48
ade_leeredrobot, gotcha21:49
ade_leeredrobot, we should prob review this soon ..21:49
*** openstackgerrit has joined #openstack-barbican22:19
openstackgerritAde Lee proposed openstack/barbican master: Make rewrap not rewrap needlessly  https://review.openstack.org/63945522:19
ade_leeredrobot, ^^22:19
*** dave-mccowan has quit IRC22:33
*** dave-mccowan has joined #openstack-barbican23:19
*** ade_lee has quit IRC23:27
*** ade_lee has joined #openstack-barbican23:56

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!