20:00:24 <redrobot> #startmeeting barbican
20:00:25 <openstack> Meeting started Mon Nov 16 20:00:24 2015 UTC and is due to finish in 60 minutes.  The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:29 <openstack> The meeting name has been set to 'barbican'
20:00:37 <redrobot> #topic Roll Call
20:00:43 <notmyname> here
20:00:46 <jvrbanac> sort o/
20:00:47 <elmiko> o/
20:00:49 <silos1> \o/
20:00:51 <edtubill> o/
20:00:52 <jrichli> o/
20:00:53 <jvrbanac> sorta o/
20:00:54 <jvrbanac> lol
20:00:56 <diazjf> o/
20:01:10 <rellerreller> o/
20:01:14 <kfarr> o/
20:01:20 <jkf> o/
20:01:21 <arunkant> o/
20:01:22 <redrobot> as usual, the agenda can be found here:
20:01:30 <redrobot> #link https://wiki.openstack.org/wiki/Meetings/Barbican
20:01:47 <jmckind> o/
20:01:47 <redrobot> a good amount of barbicaneers here! :)
20:02:13 <redrobot> #topic Action Items from last meeting
20:02:23 <redrobot> #link http://eavesdrop.openstack.org/meetings/barbican/2015/barbican.2015-11-09-20.00.html
20:02:41 <redrobot> kfarr so I asked the Release Managers about the Mitaka-1 release
20:03:21 <redrobot> kfarr apparently they will be changing the previous process (ping the ptl and ask) with a newer process that sends a patch to openstack/releases
20:03:32 <redrobot> kfarr there should be more information coming on the ML
20:03:38 <kfarr> redrobot, ok!
20:03:41 <redrobot> (or maybe already there... I haven't checked the ML)
20:04:01 <redrobot> kfarr basically one Patch with the SHA for the release to openstack/releases
20:04:10 <redrobot> kfarr and then one more patch to openstack/barbican to bump the version
20:04:27 <kfarr> redrobot, sounds reasonable
20:04:40 <redrobot> kfarr so you're on-board for releasing Mitaka-1 while I'm gone??? :D
20:04:47 <spotz> o/ late:)
20:04:49 <kfarr> redrobot, sure!
20:04:50 * elmiko gasps
20:04:52 <elmiko> ;)
20:05:05 <redrobot> #info kfarr will be handling the Mitaka-1 release
20:05:09 <redrobot> kfarr  thanks!  you rock!
20:05:33 <kfarr> that's just barbican and not python-barbicanclient, right?
20:05:38 <redrobot> next, I had an action to look at diazjf use cases for Federation... which I did not get to :(
20:05:58 <redrobot> kfarr  correct, only Barbican needs to be released during the Mitaka-1 release week
20:06:47 <edtubill> we have added use case diagrams to the barbican federation etherpad https://etherpad.openstack.org/p/barbican-federation-use-cases
20:06:49 <redrobot> kfarr also be sure to mention in the CR that you're the official release person for that release, so they know it's coming from the right source.
20:06:49 <diazjf> edtubill, silos1, can you please post the links to the usecases
20:07:00 <woodster_> o/
20:07:01 <kfarr> redrobot, got it!
20:07:35 <redrobot> diazjf  oh nice... looks like there's more stuff there for us to look at
20:07:49 <redrobot> #action redrobot to review updated Federation usecases https://etherpad.openstack.org/p/barbican-federation-use-cases
20:08:11 <redrobot> diazjf  I'll send these to Joe for comments as well
20:08:28 <diazjf> redrobot, sounds good!
20:08:40 <redrobot> ok, that's it for action items
20:08:44 <redrobot> on to today's agenda
20:09:04 <redrobot> #topic Barbican Federation Use-Cases Detailed Overview
20:09:16 <redrobot> diazjf assuming it's the same link as above?
20:09:25 <redrobot> #link https://etherpad.openstack.org/p/barbican-federation-use-cases
20:09:55 <diazjf> redrobot, yup same one
20:10:21 <redrobot> diazjf anything to discuss now, or should we revisit next meeting after everyone gets a chance to review the updated etherpad?
20:10:58 <rellerreller> Is it ok to leave comments there, or should we do that some place else?
20:11:04 <rellerreller> Or wait for discussion?
20:11:24 <edtubill> rellerreller:feel free to leave comments there
20:11:32 <diazjf> redrobot, I would like everyone to have an understanding of the usecases before review, edtubill, silos1 anything else.
20:11:35 <redrobot> edtubill +1 comments in etherpad
20:12:36 <redrobot> diazjf  sounds good, I'll move on to the next topic then
20:12:36 <silos1> nope. I think we covered everything for federation.
20:12:47 <diazjf> also put your irc_name in front of the comment :)
20:12:55 <redrobot> #info everyone please review the federation use cases
20:13:17 <redrobot> #topic Castellan Authentication compatibility for Swift
20:13:37 <diazjf> https://etherpad.openstack.org/p/swifjt-keymaster-with-castellan
20:13:44 <redrobot> So diazjf notmyname and I were talking about this a bit on the barbican channel last week.
20:13:56 <redrobot> #link https://etherpad.openstack.org/p/swifjt-keymaster-with-castellan
20:14:49 <redrobot> Swift is most commonly used with non-Keystone authentication
20:15:18 <diazjf> redrobot, I added my "thoughts" section as to what I think should be done to solve this challenge.
20:15:22 <notmyname> I think that's a red herring, actually
20:15:48 <rellerreller> notmyname which part is a red herring?
20:15:59 <notmyname> the auth system that the end-user uses doesn't/shouldn't matter, at least for the first iteration of the crypto functionality we're building
20:16:17 <redrobot> notmyname  agreed.  Barbican does not necessarily need to have the same Auth system
20:16:29 <redrobot> especially if swift clients won't have access to the Barbican instance
20:16:36 <notmyname> ie we need swift itself to be authorized to get secrets, not the end user. phrased differently, swift owns the secrets
20:17:07 <notmyname> at least in the first iteration of the feature ;-)
20:17:21 <redrobot> So the main question is how does Swift authenticate to Barbican? ... The key point here is that whatever credentials are used to auth to Barbican will be stored as the owner of the keys
20:17:52 <redrobot> so for the first iteration, where Swift owns all keys, Swift would only need a single set of credentials to auth to Barbican
20:18:01 <arunkant> notmyname..so all secrets are owned by a single tenant/account. So no multi-tenancy support is needed ?
20:18:13 <alee> notmyname, does swift have a service user?
20:18:32 <diazjf> redrobot, correct, I was thinking of using a username/password to authenticate to Barbican. That way swift can have it stored in the conf or wherever and pass that to castellan.
20:18:58 <notmyname> arunkant: it's orthogonal. swift still has multi-tenancy support
20:19:02 <rellerreller> Should we assume that Keystone does not exist?
20:19:18 <notmyname> diazjf: one reason I like that idea is the ease of testing
20:19:18 <rellerreller> Or at least that Keystone is optional?
20:19:26 <diazjf> rellerreller, correct. Most swift deployments dont use keystone
20:19:45 <notmyname> alee: maybe? I'm not sure how that's defined
20:20:38 <redrobot> alee I think service user is a devstack (or keystone) concept...
20:20:55 <rellerreller> Would it be fair to say there are two use cases. 1) Swift can authenticate to Keystone and auth as usual to Barbican. 2) Swift cannot authenticate to Keystone (does not exist) and must authenticate directly to Barbican
20:20:59 <rellerreller> ^ ?
20:21:20 <redrobot> rellerreller that sounds about right.
20:21:25 <notmyname> rellerreller: likely, but case 2 will also be the case for testing (ideally)
20:21:57 <rellerreller> notmyname I do not understand what you mean for the case for testing.
20:21:58 <redrobot> An MVP for Case 2 would require a new middleware that sits in front of Barbican that can provide Authentication.
20:22:14 <redrobot> rellerreller I think they would prefer to test without Keystone
20:22:24 <rellerreller> oh
20:22:38 <alee> notmyname, redrobot right - and can provide the types of things that a keystone token would provide
20:22:42 <notmyname> yeah, that's all. testing is simpler the less external dependencies have to be managed ;-)
20:23:00 <diazjf> redrobot, correct, I am fully supportive of making a new auth middleware for Barbican :)
20:23:20 <rellerreller> +1
20:23:43 <redrobot> alee yup... basically sit in front of Barbican, process Auth using X system, if auth succeeds then add X-Project-Id, X-Roles, and whatever else X-Headers we need
20:23:55 <alee> +1 -- and then the secrets could either all be owned by the switft user - or that user could be added to the acl for the secrets
20:24:03 <alee> yup
20:24:07 <notmyname> redrobot: diazjf: user/pass or shared secret + HMAC or whatever
20:24:36 <redrobot> I think we're all in agreement about that piece of the puzzle
20:24:54 <redrobot> so the next question is how Castellan actually handles the authentication piece
20:25:26 <notmyname> now that's I'm sitting here thinking about it again, I'm wondering if it's the best idea after all
20:25:29 <redrobot> the current interface assumes that there will be an instance of oslo.context that can be used by whatever implementation to build the required auth objects
20:25:48 <redrobot> notmyname if by "best" you mean "easy to implement", then yes. :)
20:26:18 <arunkant> so will this be two step..first authenticate to external auth..and then use that authenticated data (token in keystone world) to make call to barbican ?
20:26:20 <notmyname> redrobot: the concerns from the swift side are that the creds passed to barbican are decoupled from any end-user
20:26:49 <notmyname> redrobot: and that, at least with castellan, it would be *nice* to not require keystone if it's not using barbican
20:27:21 <notmyname> redrobot: and that for tests we can fairly easily sub out auth
20:27:25 <notmyname> *stub
20:27:34 <rellerreller> notmyname the goal of castellan is not to depend on Keystone or any other authentication scheme.
20:27:56 <rellerreller> The intent of the "context" parameter is to be a generic blob that is passed to a KeyManager.
20:28:01 <notmyname> but if a deployer is using barbican and encrypting stuff in swift, it makes sense to use keystone to manage the auth between them
20:28:11 <rellerreller> The KeyManager is then responsible for knowing how to handle the blob.
20:28:20 <diazjf> rellerreller, Keystone is currently required in the barbican-keymanager
20:28:29 <redrobot> rellerreller I don't like that definition of "context"
20:28:36 <notmyname> rellerreller: the KeyManager is on the castellan side, right?
20:28:42 <notmyname> jrichli: did what I just say make sense?
20:28:52 <rellerreller> barbican-keymanager may require it but not all key managers should require it.
20:28:55 <redrobot> rellerreller  it's very specific to the implementation, and I would prefer that it be a well-defined object, such that any impl can use it.
20:29:03 <rellerreller> notmyname yes it is on castellan side
20:29:22 <jrichli> notmyname: still processing
20:29:32 <redrobot> maybe I'm missing something... in my mind "generic blob" != well defined
20:29:40 <rellerreller> redrobot the problem is that some schemes may not be known and generic for all key managers
20:30:11 <rellerreller> for instance what about kerberos tickets or some custom signed messages or something.
20:30:53 <redrobot> This is why I was suggesting that maybe Castellan needs to define Auth objects... sort of similar to KMIP Credential objects
20:31:02 <rellerreller> I think the key manager impls will have to look at the blob and say something like if instance of keystone token then do this; else if instance of .. do this; else I don't know what to do raise exception.
20:31:17 <jrichli> redrobot: +1
20:31:18 <elmiko> redrobot: an interesting thought
20:31:24 <rellerreller> redrobot I think we are saying the same thing.
20:31:38 <rellerreller> redrobot I'm suggesting the top level object be a generic blob.
20:31:44 <notmyname> perhaps. I think my concern isn't that keystone is used for a particular config (ie castellan to barbican). just that keystone might have been required in every use case
20:31:53 <rellerreller> Then subclasses for username/password, keystone token, etc.
20:32:19 <redrobot> rellerreller ah yes... seems we're in violent agreement ;)
20:32:44 <redrobot> notmyname  I'm not opposed to having multiple Barbican implementations of Castellan
20:33:00 <rellerreller> Then I see Barbican key manager say if KeystoneContext then send directly to Barbican; else if PasswordContext take out username/password and pass to barbican; else raise error
20:33:24 <rellerreller> And for KMIP KeyManager it does something similar by mapping to the KMIP objects for authentication
20:33:59 <rellerreller> You should not need multiple implementations of Barbican
20:34:09 <kfarr> but if I'm following correctly, barbican would currently only accept a "keystonecontext" right?
20:34:41 <rellerreller> kfarr yes, but it would not take much to change it
20:35:11 <kfarr> Ok just trying to keep straight what is being proposed and what is currently implemented
20:35:23 <rellerreller> We could write a helper method to transform the Castellan context object into something that can be used by python-barbicanclient
20:36:35 <redrobot> rellerreller sure, a smar impl that can conditionally use Keystone would work
20:36:42 <redrobot> *smart
20:36:56 <redrobot> rellerreller  I think we need to better define the context object
20:37:00 <rellerreller> agreed
20:37:23 <rellerreller> I think a smart implementation for KMIP impl is needed as well
20:37:36 <diazjf> redrobot, rellerreller, So what we have now as an acceptable solution is to do the following?
20:37:36 <diazjf> 1.) username/password middleware for Barbican
20:37:36 <diazjf> 2.) Castellan checks context and decides how to perform auth
20:37:46 <rellerreller> I do not foresee a KMIP device knowing how to handle keystone tokens in the near future but could later
20:38:19 <notmyname> I feel like I should be arguing that barbican (the project) not reimplement auth ;-)
20:38:22 <rellerreller> diazjf 2. Barbican KM in Castellan (just trying to clarify)
20:38:36 <diazjf> rellerreller, correct
20:38:47 <rellerreller> ok, making sure we are on the same page.
20:38:59 <rellerreller> notmyname one of my questions was how swift is doing this
20:39:12 <rellerreller> Is there a library that can be reused?
20:39:27 <notmyname> for what? different auth implementations?
20:39:38 <rellerreller> notmyname yes
20:40:06 <redrobot> diazjf  There's a ton of different ways to achieve 1 ... still not sure we need to provide any/all possiblities with Barbican.
20:40:24 <notmyname> no. auth is done in swift via middleware that conforms to a protocol. swift ships with an auth middleware for testing and a keystone auth middleware. if deployers want something else, they can find or write a different one
20:41:44 <rellerreller> notmyname why can we not apply that same scheme to barbican?
20:42:14 <notmyname> I suppose you could. I'm not familiar enough with your design to know how or if that would work
20:42:26 <redrobot> rellerreller we have a different auth story...  Swift uses callbacks provided by the middlware...  we strictly require the request headers provided by keystonemiddlware.
20:42:52 <rellerreller> interesting
20:43:12 <notmyname> redrobot: close. the middleware can look at whatever headers it wants and does provide a callback. but it's not callbacks vs headers
20:43:16 <redrobot> diazjf is this helping move your spec forward?
20:43:41 <diazjf> redrobot yes, I will update https://review.openstack.org/#/c/241068/
20:43:48 * redrobot only knows about Swift auth from previous discussions
20:43:53 <diazjf> I would really like this feature in the M release :)
20:44:35 <redrobot> so for now, it seems we need to 1. better define the Context object in Castellan
20:44:47 <redrobot> and 2. possibly provide a sample non-keystone auth middleware.
20:44:55 <redrobot> diazjf do you want to work on both of those?
20:45:04 <diazjf> redrobot, Yes
20:45:32 <redrobot> #action diazjf to write blueprint to better define Context in Castellan
20:45:46 <redrobot> #action diazjf to write a non-keystone auth middleware for Barbican
20:45:53 <redrobot> ok, good discussions y'all
20:46:22 <redrobot> still got a few topics, hopefully we can get through those in 15 min.
20:46:30 <redrobot> #topic Barbican Garbage Collector
20:46:52 <edtubill> for this topic I just wanted to ask people to review my spec/blue print
20:46:54 <edtubill> https://review.openstack.org/#/c/243806/
20:46:54 <redrobot> whose topic is this?
20:46:54 <edtubill> https://blueprints.launchpad.net/barbican/+spec/barbican-cron-job-garbage-collector-for-database
20:47:27 <edtubill> redrobot: mine, I forgot to put my name on the agenda
20:47:55 <edtubill> and I also wanted to ask when it would be okay to start working on it, or should I wait till the blue print gets accepted?
20:48:35 <redrobot> edtubill up to you... the risk in working on impl before the spec is accepted is that it may change, thus forcing you to re-work the impl
20:49:58 <redrobot> regarding the "to be discussed" section in L65-68
20:50:23 <redrobot> I think all questions go back to the Soft vs. Hard dilemma
20:50:47 <redrobot> In previous discussions I think the general consensus is that it should be configurable per deployment
20:51:13 <redrobot> for example, at Rackspace, we may want soft deletes to provide "fanatical undelete" ... so you could call one of our support reps and get your key back.
20:51:37 <redrobot> but some other deployer may have a compliance regime that requires them to really delete a key when you ask for a delete operation
20:52:05 <redrobot> edtubill does that make sense?
20:52:28 <edtubill> redrobot, yes that makes sense.
20:52:51 <redrobot> edtubill anything else to discuss now, or just wait for more reviews?
20:53:08 <edtubill> I can wait for more reviews. lets get on to the next topic
20:53:23 <redrobot> #topic Creating a castellan-specs repo
20:53:34 <edtubill> thanks for the input. I'll add it to the spec.
20:53:54 <redrobot> silos1 what benefits would we get from a separate repo as opposed to having a /castellan directory in barbican-specs for example?
20:54:48 <silos1> Hmm In my head it just made sense because we are adding features in castellan that don't really have any dependency on barbican. Like a key_manager interface for kmip.
20:55:21 <redrobot> #vote Should Castellan specs be tracked in barbican-specs or not?
20:55:39 <redrobot> derp
20:55:52 <redrobot> #startvote Should Castellan specs be tracked in barbican-specs or not?
20:55:54 <openstack> Begin voting on: Should Castellan specs be tracked in barbican-specs or not? Valid vote options are Yes, No.
20:55:55 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
20:56:17 <redrobot> to clarify "Yes" means we track in barbican-specs
20:56:27 <redrobot> "No" vote means we should have a castellan-specs repo
20:56:34 <rellerreller> #vote yes
20:56:38 <elmiko> #vote yes
20:56:42 <arunkant> #vote yes
20:56:44 <kfarr> #vote yes
20:56:44 <rellerreller> That means put it under a castellan folder?
20:56:50 <elmiko> rellerreller: yes
20:56:56 <silos1> #vote no :(
20:56:59 <edtubill> #vote No
20:57:10 <woodster_> rellerreller: kfarr do we expect many more changes to castellan?
20:57:12 <kfarr> oh wait
20:57:14 <redrobot> rellerreller yes, a castellan directory ... posbilly with mitaka/ etc directories underneath
20:57:48 <woodster_> if we do expect many more changes, then I vote 'yes'
20:57:59 <rellerreller> Either way is fine with me.
20:58:00 <redrobot> #vote yes
20:58:08 * woodster_ but I doubt many more are needed :)
20:58:12 <kfarr> Well, this generic authentication is one upcoming big one
20:58:17 <kfarr> potentially
20:58:21 <redrobot> #endvote
20:58:22 <openstack> Voted on "Should Castellan specs be tracked in barbican-specs or not?" Results are
20:58:24 <elmiko> kfarr: agreed
20:58:27 <rellerreller> woodster_ why would more changes make you want it in Barbican? I would have thought the other way.
20:58:50 <woodster_> rellerreller: many more changes would be better in a sep repo
20:58:51 * redrobot is in suspense waiting for vote results
20:59:05 <redrobot> I think our voting bot broke :(
20:59:06 <rellerreller> oh, I guess I misread that. My mistake.
20:59:14 <woodster_> I voted yes to a new repo if lots of changes still coming, no other wise
20:59:16 <diazjf> kfarr, already put the spec in Barbican :)
20:59:26 <elmiko> if things get crazy active with castellan specs, nothing precludes moving it out to its own space though... right?
20:59:30 <redrobot> in any case... it looks like we should continue to track in barbican-specs unless it becomes a problem
20:59:34 <woodster_> do we think castellan is stable
20:59:36 <rellerreller> woodster_ yes means no in this case :)
20:59:56 <redrobot> elmiko looks like we won't have time for your topic :(
20:59:56 <silos1> redrobot: ok. just wanted to clear up where to keep the specs.
20:59:56 <woodster_> like those proposition votes at election time!
21:00:04 <elmiko> redrobot: nutz...
21:00:07 <kfarr> woodster_, what do you mean by stable?
21:00:14 <rellerreller> I think there will be more changes; context, barbican authentication, kmip impl
21:00:20 <woodster_> i think we are out of time :\
21:00:24 <rellerreller> I have to run
21:00:25 <redrobot> we're out of time folks... we can continue in our channel
21:00:29 <redrobot> #endmeeting