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