20:06:40 <redrobot> #startmeeting barbican
20:06:41 <openstack> Meeting started Mon Dec 19 20:06:40 2016 UTC and is due to finish in 60 minutes.  The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:06:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:06:44 <openstack> The meeting name has been set to 'barbican'
20:06:52 <redrobot> #topic Roll Call
20:07:01 <dane-fichter> present
20:07:03 <redrobot> I think Dave may be out today
20:07:12 <redrobot> but we do have an agenda:
20:07:17 <redrobot> #link https://wiki.openstack.org/wiki/Meetings/Barbican#Agenda
20:09:27 <redrobot> ok let's get started
20:09:30 <redrobot> #topic Storing Fernet keys in Barbican
20:10:03 <redrobot> Who's topic is this?
20:10:35 <breton> mine
20:10:37 <redrobot> kfarr's topic maybe?
20:10:43 <redrobot> oh cool
20:10:46 <redrobot> hi breton !
20:10:51 <breton> o/
20:11:11 <breton> i work on implementing fernet keys backends in keystone
20:11:36 <breton> and was wondering whether i could use barbican for that
20:11:46 * lbragstad hands breton #link http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ocata/fernet-key-store.html
20:12:18 <breton> there is one thing that stops us from using barbican -- in order to make a query to it we need a token
20:12:28 <breton> lbragstad: thank you
20:12:41 <lbragstad> breton anytime :)
20:13:13 <redrobot> I think I've had hallway conversations about this topic before
20:13:16 <breton> so, can we do something on barbican's side to skip token validation for this case?
20:13:20 <breton> yep
20:13:29 <breton> i talked to some of you at the summit
20:13:43 <breton> (i don't know who, sorry)
20:16:35 <redrobot> basically we need to be able to have a different auth middleware for non-token access to Barbican
20:17:05 <redrobot> I think maybe doing cert-based auth might work
20:17:29 <redrobot> like a middlware that can do x.509 auth and skip the token middlware if x.509 checks out
20:17:45 <breton> we have something like this in keystone
20:18:24 <breton> unfortunatelly, nobody probably uses it.
20:18:53 <redrobot> hehe
20:19:00 <redrobot> I think there may be some more use cases for us
20:19:26 <redrobot> since other project now have to have a service user to get keystone tokens to talk to us
20:19:34 <redrobot> *projects
20:20:29 <breton> what do you think about new api in paste, which would not be protected by authtoken middleware?
20:20:50 <breton> because now keystonemiddleware is drop-in basically
20:21:51 <redrobot> what do you mean by "new api"?
20:22:45 <breton> paste pipeline
20:23:35 <breton> something like
20:23:36 <breton> [pipeline:barbican-api-keystone]
20:23:47 <breton> pipeline = cors http_proxy_to_wsgi our_x509_middleware context apiapp
20:24:05 <breton> * [pipeline:barbican-api-keystone_x509]
20:24:45 <breton> and serve it on /some_new_api/
20:25:58 <redrobot> personally, I would not like to add any new routes to Barbican.  A fernet key is just an encryption key that can be managed with the existing API.  I think it would be more interesting to make the current api work with either a cert or a token.
20:27:29 <redrobot> although, to be honest, I haven't spent a whole lot of time thinking about x.509 auth
20:27:59 <redrobot> the data model we have now requires a project ID, so we'd need a way to translate a cert into a project id
20:28:58 <breton> oh.
20:30:05 <breton> the whole thing looks like barbican is supposed to store user data rather than openstack's data.
20:31:48 <redrobot> well, i think the idea was that the openstack data (or undercloud secrets) or whatever could be saved as its own tenant
20:32:18 <redrobot> which is fine for most projects since we can verify their identity with keystone ;)
20:33:39 <redrobot> definitely sounds like we need more discussions about this.  maybe at the PTG?
20:33:57 <breton> sounds good
20:34:15 <redrobot> I have a feeling there's a lot more to x.509 auth that we might need to do
20:34:24 <redrobot> like cert revocation, rotation, etc
20:34:43 <breton> i agree
20:36:16 <redrobot> I've added the topic to our PTG etherpad
20:36:18 <redrobot> #link https://etherpad.openstack.org/p/ptg-barbican-pike
20:36:30 * redrobot crosses fingers he'll get to go to Atlanta
20:36:54 <redrobot> we can also revisit the topic in a future meeting
20:37:10 <redrobot> maybe take some time to think about what an x.509 auth middleware would look like
20:37:32 <redrobot> so we don't have to wait until the PTG
20:38:22 <breton> ok
20:38:24 <redrobot> any other comments on this before we move on?
20:39:14 <redrobot> ok, moving on
20:39:20 <redrobot> #topic Code review requests
20:39:27 <redrobot> #link https://review.openstack.org/#/c/403604/
20:39:39 <dane-fichter> I also have a couple requests
20:40:08 <redrobot> dane-fichter sure thing, links?
20:40:10 <dane-fichter> https://review.openstack.org/#/c/408278/ and https://review.openstack.org/#/c/411478/
20:40:25 <dane-fichter> the barbican tempest plugin work needs review help
20:40:51 <redrobot> dane-fichter ah yes, I've been meaning to look at that
20:40:59 <dane-fichter> and if anyone knows where koderer is, getting his attention would be appreciated
20:41:16 <redrobot> I was wondering about the client layer
20:41:31 <dane-fichter> yeah that's the first patch
20:41:43 <dane-fichter> implements the key manager client
20:41:48 <redrobot> haven't looked at it yet, but was the client copy/pasted from our existing tests or is it new or ?
20:42:19 <dane-fichter> It is new.
20:42:53 <redrobot> i see
20:43:09 <redrobot> I'm a little apprehensive about having to maintain separate clients like that
20:43:35 <dane-fichter> if you want tempest tests, you need a service client
20:44:16 <redrobot> understood.  but we also have a thin client abstraction that is currently used for our functional tests
20:44:26 <redrobot> and also the thick client (python-barbicanclient)
20:44:53 <dane-fichter> you explicitly can't use something like barbicanclient in a tempest plugin
20:45:24 <dane-fichter> sort of defeats the point of testing the API.
20:45:58 <dane-fichter> I think I looked into the functional test client and decided it was insufficient
20:46:02 <redrobot> I think there may be a way to use a single codebase for the tempest tests in addition to the barbican functional tests
20:46:21 <redrobot> why not improve the functional test client instead of re-writing a new one?
20:46:32 <dane-fichter> To be quite honest I don't really think there's any use in a functional test client
20:47:02 <redrobot> I think the functional test client and the tempest client serve the same purpose:  to generate requests to be sent to the api
20:47:14 <redrobot> while explicitly not using python-barbicanclient
20:47:43 <dane-fichter> The tempest test suite w/ API tests actually increases Barbican's legitimacy
20:48:02 <redrobot> sure, makes sense to me
20:48:09 <redrobot> i'm not opposed to having tempest tests
20:48:32 <redrobot> I'm just concerned about the long term maintenance of thin api clients used for these tests
20:49:00 <redrobot> just trying to reduce code duplication :)
20:50:27 <redrobot> do any other projects re-use their tempest clients?
20:50:47 <dane-fichter> I don't understand the question
20:51:31 <redrobot> is it typical for other projects to have a dedicated client in tempest used only for tempest tests?  do they also have a separate client they use in functional testing?
20:51:38 <redrobot> just trying to understand how other folks are doing things
20:52:03 <dane-fichter> yes it is typical to have a dedicated client in tempest JUST for tempest tests
20:52:19 <dane-fichter> it is standard operating procedure
20:52:41 <dane-fichter> check out the magum or ironic tempest plugins for comparison
20:53:48 <redrobot> k, I'll try to make some time to look at those and the proposed barbican patches
20:55:01 <redrobot> I was hoping to see koderer
20:55:24 <redrobot> I was also working on getting an ID property added to our entities in the API
20:57:03 <kfarr> I have a few review requests, too: https://review.openstack.org/#/c/412558/ https://review.openstack.org/#/c/409978/ and https://review.openstack.org/#/c/400370/
20:57:21 <redrobot> kfarr got them in just in time
20:57:27 <kfarr> :D
20:58:42 <redrobot> alright guys, we're all out of time here
20:58:47 <redrobot> thanks for coming!
20:59:01 <redrobot> #endmeeting