20:00:51 <redrobot> #startmeeting barbican
20:00:52 <openstack> Meeting started Mon Dec 14 20:00:51 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:53 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:55 <openstack> The meeting name has been set to 'barbican'
20:01:01 <redrobot> #topic Roll Call
20:01:12 <silos> \o/
20:01:19 <rellerreller> o/
20:01:23 <jmckind> o/
20:01:25 <jhfeng> o/
20:01:25 <redrobot> As usual the meeting agenda can be found here:
20:01:26 <woodster_> o/
20:01:26 <redrobot> #link https://wiki.openstack.org/wiki/Meetings/Barbican
20:01:31 <NazcaLines> o/
20:01:32 <diazjf> o/
20:01:33 <maxabidi> o/
20:01:35 <arunkant> o/
20:01:37 <elmiko> o/
20:01:41 <alee> o/
20:01:58 * redrobot waves at maxabidi
20:02:10 <kfarr> o/
20:02:15 <redrobot> maxabidi I don't recognize your nick... mind introducing yourself?
20:02:46 <redrobot> a couple of new Barbicaneers... how exciting! :D
20:02:55 * redrobot feels a little out of the loop still...
20:03:08 <maxabidi> Hello, I am a new member at HPE
20:03:11 <woodster_> redrobot:  still in that honeymoon period?
20:03:19 <redrobot> woodster_  hehe, something like that :)
20:03:20 <arunkant> redrobot: maxabidi is new barbicaneer from hpe
20:03:38 <redrobot> arunkant awesome
20:03:42 <redrobot> welcome maxabidi
20:03:55 <redrobot> I don't recognize NazcaLines either...
20:04:03 <jaosorior> o/
20:04:13 <NazcaLines> I'm a newcomer  :)
20:04:19 <redrobot> welcome NazcaLines !
20:04:34 <NazcaLines> thanks
20:04:39 <redrobot> #topic Action Items from last meeting
20:04:42 <redrobot> #link http://eavesdrop.openstack.org/meetings/barbican/2015/barbican.2015-12-07-20.00.html
20:05:19 <redrobot> alee had an action to advertise his blog post
20:05:22 <redrobot> which he did here
20:05:24 <redrobot> #link http://lists.openstack.org/pipermail/openstack-dev/2015-December/081749.html
20:05:33 <alee> yup
20:05:39 <redrobot> alee good write up!
20:05:52 <alee> looks like I have at one person trying my write up
20:05:57 <alee> at least ..
20:06:04 <dave-mccowan> o/
20:06:20 <stevemar> diazjf: thanks for the heads up
20:06:29 <jhfeng> alee: very useful, thanks
20:06:50 <diazjf> stevemar, no worries
20:06:52 <alee> jhfeng, cool - let me know if anything is wrong/ doesn't work ..
20:06:55 <redrobot> diazjf did you get a chance to update the Barbican Context BP?
20:07:05 <diazjf> redrobot, sure did
20:07:13 <redrobot> diazjf link?
20:07:17 <diazjf> https://review.openstack.org/#/c/241068/
20:07:25 <redrobot> diazjf thanks!
20:07:52 <redrobot> and lastly, I was supposed to clean up the mitaka-1 Launchpad page... which I started doing today
20:07:53 <hockeynut> o/
20:07:56 <redrobot> but I'm not quite done yet
20:08:01 <redrobot> so I'll bump that to next week
20:08:26 <redrobot> #action redrobot to finish cleaning up Launchpad mitaka-1 page
20:08:43 <redrobot> That's it for last week's action items
20:08:47 <redrobot> on to this week's agenda
20:09:09 <redrobot> #topic Barbican SAML Authentication
20:09:11 <redrobot> #link https://review.openstack.org/#/c/241068/
20:09:19 <redrobot> diazjf you want to talk about this?
20:09:57 <stevemar> diazjf: i'm interested in hearing about it :O
20:10:33 <diazjf> Awesome, great to have everyone here.
20:11:03 <diazjf> So as a refresher the reason why this was needed is because there needed to be a way for Swift to use Barbican without Keystone.
20:11:40 <diazjf> The reason being is because most swift deployments come with another authentication system.
20:11:52 <stevemar> so, barbican - right now, can be run without keystone? and it's usable?
20:12:03 * notmyname isn't really here, but wants to respond to that
20:12:43 <redrobot> stevemar the Barbican auth requirement is that X-Project-Id and X-Roles must be present in the request... we don't really care how they get there, but the obvious way to get them there is to use keystonemiddleware
20:12:44 <notmyname> I don't want castellan to be tied to keystone. if the backend requires keystone, that's ok. if the backend doesn't (eg another I write myself) I don't
20:13:08 <jaosorior> stevemar: Yeah, in order to do that we use another context middleware that we ship with the barbican server code
20:13:16 <notmyname> I want castellan to pass on whatever creds are given and the backend interprets it
20:13:18 <elmiko> notmyname: +1
20:13:29 <redrobot> notmyname ack
20:13:41 <jaosorior> stevemar: Basically it requires the client to set the headers redrobot mentioned
20:13:42 <redrobot> notmyname I think that was the general agreement last time we talked about it...
20:13:47 <redrobot> notmyname last time I was here anyway...
20:14:02 <notmyname> I mean, I think it would be swell to use barbican without keystone, but I think that's unreasonable to ask for ;-)
20:14:13 <elmiko> redrobot, yea, i think that is consistent with the last discussion i was involved with
20:14:38 <notmyname> (here's my ignorance of castellan) I want basically some parameter I pass in to go on to the backend. without caring what the type is
20:14:49 <redrobot> not sure how we arrived at a SAML middleware though
20:14:51 <notmyname> eg if barbican needs an oslo.context that works with keystone, ok
20:15:08 <notmyname> if my own needs an hmac and whatever, then I'll pass a dictionary.
20:15:26 <stevemar> whats the relationship between castellan and barbican? castellan depends on barbican?
20:15:42 <elmiko> iirc, castellan is just blindly passing the context object on to the barbicanclient
20:15:57 <elmiko> stevemar: castellan is a keymanager abstraction layer library
20:15:57 <kfarr> stevemar castellan is sort of a wrapper for barbican
20:16:06 <kfarr> or any other key manager back end
20:16:06 <redrobot> stevemar  no, castellan is an interface.  there is a castellan implementation that uses python-barbicanclient
20:16:25 <notmyname> hmm...ok
20:16:37 <redrobot> stevemar idea is that you integrate your project with Castellan, then you pick a castellan implementation at deploy time
20:16:37 <rellerreller> castellan is designed to be a generic key manager interface that can support any key manager implementation
20:17:03 <stevemar> gotcha, generic, can be used with barbican or something else
20:17:04 <rellerreller> the goal is to provide a common interface that easily allows different key management solutions to be used in a plug and play manner
20:17:17 <notmyname> so is castellan the interface or an implementation?
20:17:30 <rellerreller> The context object is designed to be a generic blob. The backend is responsible for interpreting the data.
20:17:31 <notmyname> ie API contract or something I actually import
20:17:32 <redrobot> notmyname the castellan lib includes both the interface and implementations
20:17:47 <rellerreller> Castellan is the name of the library that provides a KeyManager interface
20:18:03 <rellerreller> It also provides a Barbican implementation as redrobot pointed out.
20:18:15 <rellerreller> The plan is to include a KMIP implementation in the future
20:18:18 <redrobot> rellerreller the problem with the "blobl" definintion is that it defeats the purpose of having a pluggable backend.
20:18:35 <redrobot> in any case, we're way off topic from SAML Auth
20:18:45 <redrobot> diazjf did you want to talk about SAML ?
20:18:49 <rellerreller> redrobot yes, I know. We have discussed this in the past. My definition is different than users.
20:19:11 <rellerreller> There will be a common credentials class like KMIP defines and subclasses that implement different types.
20:19:22 <redrobot> rellerreller awesome!
20:19:32 <rellerreller> An example woudl be a UsernamePasswordCredential object that contains username and password
20:19:47 <stevemar> redrobot: i imagine SAML is what diazjf is proposing to chat between swift and castellan
20:19:47 <rellerreller> Another example is KeystoneCredential where you pass it a keystone context.
20:20:06 <diazjf> redrobot, I was thinking it would be necessary for swift not using keystone.
20:20:08 <rellerreller> Yes, I could easily see another Credential for SAML
20:20:45 <redrobot> diazjf do we expect most Swift deployments to be using SAML for auth?
20:20:52 <diazjf> notmyname, I thought originally this is what was needed in order for Castellan to be accepted in Swift's keymaster
20:21:46 <diazjf> redrobot, I had a meeting a while back with alee, kfarr, and elmiko, the SAML assertion will be generated by Barbican Client
20:22:19 <diazjf> So it will be values in the conf or environment the client can use to build an assertion
20:22:24 <diazjf> and gain access to Barbican
20:22:29 <notmyname> diazjf: I think the conversation wandered away from the actual use cases, and we somehow got to SAML (and that's not a critique. it just happend)
20:23:55 <diazjf> notmyname, redrobot, I'm ok with keeping Keystone. Just want to know whats required to get Castellan into the Swift Keymanager
20:24:07 <redrobot> I'm not super familiar with SAML, but as I understand it, the assertion is created by someone with authority...  like a directory service, for example...  not sure what authority barbicanclient has to generate saml assertions?
20:24:14 <alee> notmyname, Its not so much that it veered away from actual use-cases as we started thinking about what would actually be passed through and accepted by barbican.
20:24:30 <panatl> yes, Barbican client generating SAML Assertion .. something is worng
20:24:54 <notmyname> alee: that's fair
20:25:20 <alee> at the time, we started thinking about what would need to implemented on the barbican side.  seems like if we need to implment some kind of auth protocol in the middleware on the barbican sider, then we should do something standard
20:25:26 <alee> and saml is pretty standard
20:25:45 <notmyname> diazjf: from the swift perspective, to use castellan, we need to not have any extra requirements beyond what the backend key manager requires. that will allow us to use barbican or something else in testing and prod
20:26:04 <notmyname> jrichli: does that sound right?
20:26:05 <alee> better yet -- if we implement saml support, then we put barbican behind/ as an apache module, and have apache modules do what we need to do
20:26:12 <jrichli> notmyname: agreed
20:26:30 <redrobot> notmyname iirc, for the first pass at a castellan implementation, it would be limited to a single credential to the keystore.  Basically Swift will own all keys, yes?
20:27:17 <notmyname> redrobot: that is correct. swift owns the keys (except perhaps the root key). and it's swift the service (as opposed to end users) who has the creds to get that root key
20:27:38 <notmyname> redrobot: or rather, swift has creds to get that root key
20:28:32 <alee> redrobot, yes - as a first implementation - that might be ok.  we were thinking beyond that -- can we avoid having an all powerful swift service user that has access to all the keys?
20:29:00 <notmyname> alee: that's up to swift, right?
20:29:10 <alee> true
20:29:29 <notmyname> alee: and at that point, it will probably require that the end user identity management is the same used by the key manager
20:29:51 <notmyname> unless you're proposing some bridge there. and that sounds *really* complicated
20:30:36 <redrobot> yeah, SAML sounds like overkill for a middleware that just needs to verify a single password
20:30:53 <redrobot> for an MVP I think we would need something like a Pre-Shared Key middleware
20:31:13 <rellerreller> redrobot MVP?
20:31:14 <alee> redrobot, for a single password, thats absolutely true.
20:31:25 <redrobot> rellerreller minimum viable product
20:32:19 <notmyname> so I think it sounds like you (barbican peoples) understand the swift needs. are there other questions about that, as it applies to the auth betweent he two?
20:32:32 <notmyname> jrichli: are we missing covering anything?
20:33:13 <jrichli> notmyname: sounds like there is an understanding.
20:33:38 <notmyname> diazjf: alee: redrobot: good from your end?
20:34:06 <redrobot> notmyname  I'm good... may need to sync up with diazjf regarding the SAML blueprint though
20:34:31 <notmyname> redrobot: you may need to or I may need to?
20:34:41 <diazjf> redrobot, sure I'd like to have a talk about what the best step to take forward would be.
20:34:44 <redrobot> notmyname I'll syinc up with him
20:34:48 <notmyname> ok :-)
20:34:51 <alee> notmyname, jrichli - do you guys have any preference in terms of creds ?  user/password, or shared key?
20:35:05 <diazjf> notmyname, thanks for attending, I appreciate it
20:35:20 <diazjf> alee, I think user/pass would be fine
20:35:21 <notmyname> alee: I think that's up to whatever the key manager backend is. why does that actually matter?
20:35:46 <notmyname> alee: ok ok, yeah there are leaky abstractions there
20:35:46 <diazjf> but I have no preference
20:36:16 <alee> notmyname, so here is my understanding on what is needed ..
20:36:17 <redrobot> notmyname I think alee is asking about the barbican-sans-keystone preference
20:36:17 <notmyname> alee: can I write a key manager backend that uses hmac with a shared secret?
20:36:45 <alee> right
20:37:12 <alee> so if we dont have keystone, we need some way for swift to auth to barbican
20:37:33 <alee> and we would have castellan pass through those credentials
20:37:57 <elmiko> alee: wouldn't those just be encapsulated in the context object?
20:37:58 <notmyname> as a first pass, I'm ok with barbican requiring keystone
20:38:20 <notmyname> it might be that pushes me to reimplement something else (unfortunately), but I don't know at this point
20:38:51 <alee> and they would be interpreted by some auth middleware that would convert those params into keystone like options ..
20:39:15 <elmiko> i thought the deepest abstraction for castellan was the context object, and anything in that object would just get passed on to the consumer for them to do with as they please.
20:39:21 <diazjf> elmiko, correct as long as there's a auth-middleware in Barbican that knows what the context is
20:39:22 <notmyname> just as long as I can make FakeKeyManager for castellan in my tests and my own AwesomeKeyManager for castellan in my own deployment
20:39:40 <elmiko> and i'm not saying oslo.context, just some object known as context in cast.
20:39:48 <notmyname> elmiko: oh good :-)
20:39:51 <rellerreller> alee: I thought swift would authenticate with some service and the result of that (SAML assertion) would be passed to Barbican?
20:40:09 <elmiko> notmyname: we implement a custom key manager in sahara, you could do that
20:40:17 <notmyname> elmiko: and the context parameter could be a disctionary. or string. or oslo.context.
20:40:24 <rellerreller> The SAML assertion would live in a SamlCredential object
20:40:41 <elmiko> notmyname: right, whatever you need. it's just an object to castellan that gets forwarded to the key manager impls
20:41:00 <rellerreller> notmyname kfarr, don't we have a basic key manager for testing that always returns the same key?
20:41:16 <notmyname> rellerreller: please let it be 42
20:41:25 <jrichli> :-)
20:41:33 <kfarr> rellerreller, no, that's a fixed key manager.  That was in the original implementations in cinder and nova, but not in Castellan
20:41:34 <elmiko> hmm, i know there is NotImplementedKeyManager, was there also FakeKeyManager?
20:41:46 <rellerreller> notmyname 42?
20:41:48 <alee> rellerreller, yes - but of course thats overkill for a single user/password
20:41:59 <elmiko> notmyname: it would have to ;)
20:42:03 <redrobot> I think we've beaten this to death here...
20:42:04 <alee> rellerreller, the answer to life , the universe and everything ..
20:42:06 <kfarr> there was one in the test directories that has an in-memory database for storing keys
20:42:09 <notmyname> rellerreller: https://en.wikipedia.org/wiki/42_(number)#The_Hitchhiker.27s_Guide_to_the_Galaxy
20:42:10 <redrobot> we can iron out the details over a BP
20:42:25 <elmiko> redrobot: +1
20:42:33 <diazjf> redrobot +1
20:42:49 <redrobot> ok, thanks notmyname and jrichli for stoping by!
20:42:57 <jrichli> yw
20:43:07 <notmyname> you're welcome
20:43:14 <diazjf> thanks everyone :)
20:43:17 <redrobot> moving on...
20:43:25 <redrobot> #topic Add PUT support for Generic Containers
20:43:27 <redrobot> #link https://review.openstack.org/#/c/207249/
20:43:28 <diazjf> redrobot, we can talk more about this sometime this week
20:43:31 <NazcaLines> i add it.
20:43:42 <redrobot> diazjf for sure!
20:43:48 <redrobot> NazcaLines go ahead
20:43:59 <NazcaLines> BP:https://blueprints.launchpad.net/barbican/+spec/api-containers-add-put
20:44:12 <NazcaLines> Commit: https://review.openstack.org/#/c/207249/
20:44:20 <NazcaLines> I'm working on it now.
20:44:31 <NazcaLines> The question is that:
20:44:46 <NazcaLines> i plan to support add new secret ref and delete existing secret ref in a container.
20:45:03 <NazcaLines> but it's different with 'replace-all-refs' committed by @Kevin Bishop at first.
20:45:11 * redrobot senses a PUT vs PATCH debate brewing...
20:45:28 <NazcaLines> what do you think? Is it worth  supporting "add"&"delete"? Maybe "replace-all-refs" is better?
20:45:41 <elmiko> redrobot: lol
20:46:15 <redrobot> I _think_ it comes down to PUT vs PATCH semantics
20:46:43 <redrobot> iirc we decided to do a replace-all for PUT and then punted on PATCH because JSONPATCH looked unfriendly
20:47:05 <dave-mccowan> i was pretty happy with chelsea's last commit (patch set 8). it just needed some clean up. i think "replace all" with PUT is a clean, simple, and sufficient solution.
20:47:24 <redrobot> dave-mccowan do you have the link?
20:47:28 <elmiko> redrobot: that sounds about right, although doing partial updates through PATCH is within the boundaries of reasonable
20:47:56 <elmiko> the key is to choose one way, partial updates or jsonpatch, and stick with it.
20:48:27 <redrobot> elmiko +1
20:48:31 <redrobot> NazcaLines does that make sense?
20:48:54 <dave-mccowan> same link that NazcaLines posted above
20:50:02 <redrobot> dave-mccowan ack, thanks
20:50:49 <NazcaLines> imagine that if we have many secrets in a container and we want to replace some of them. In 'replace-all-refs' mode, we should write all secret_refs into the json request data.
20:50:53 <woodster_> I recall the API team suggesting turning PATCH things into simpler semantics if possible...so DELETE /containers/<container UUID>/secrets/<secrets UUID> to remove one secret (for example)
20:50:59 <redrobot> seems like this would be best to sort out in a spec?
20:51:41 <silos> We could also mirror ACL's and provide both PUT and PATCH? PUT is used to replace the existing ACLS while PATCH is used to update it. At least that's what the documentation shows.
20:51:44 <elmiko> woodster_: i've seen it discussed both ways for PATCH, the best guidance was pick whichever works for your project and be consistent.
20:51:54 <dave-mccowan> NazcaLines I applaud your ambition to do a more robust solution with PATCH and add/deletes, but I don't think it's necessary.  (if we did, then we'd want a spec as it would be an API change.)  With PUT only, it is the same API as a 2-part create, so I don't think a spec would be needed.
20:51:57 <redrobot> silos  +1 for API consistency
20:52:28 <elmiko> silos: that works too
20:53:41 <elmiko> dave-mccowan, NazcaLines, if you want a robust add/delete/update methodology, then just use the jsonpatch stuff through the PATCH method
20:53:56 <elmiko> #link https://tools.ietf.org/html/rfc6902.html
20:53:58 <elmiko> for reference
20:54:30 <elmiko> it's probably more heavyweight than needed though, at a guess
20:54:49 <woodster_> elmiko: yeah that is why I favor the non-PATCH approaches
20:55:10 <elmiko> i kinda do too, much simpler to implement/maintain
20:55:20 <alee> woodster_, +1, PATCH is hard to get right.
20:55:32 <woodster_> alee: agreed
20:55:58 <elmiko> i agree with redrobot thought, we should argue it out on a spec =)
20:56:13 <redrobot> ok, so regarding NazcaLines 's question... I think we should review what ACLs is doing with PATCh/PUT and then write a Spec for the change
20:56:28 <redrobot> NazcaLines would that work for you?
20:56:56 <redrobot> #link http://git.openstack.org/cgit/openstack/barbican-specs/tree/README.rst
20:57:00 <dave-mccowan> i think we're unanimous on use PUT for replace only.  are there any dissenters?
20:57:52 <NazcaLines> Yes. i'd like to do it.
20:58:06 <redrobot> NazcaLines ok, sounds good
20:58:12 <elmiko> dave-mccowan: if that's the consensus, we should review the metadata spec as it allows for deletion through PUT
20:58:13 <redrobot> only a couple of minutes left here
20:58:22 <redrobot> #topic Mitaka Mid-Cycle
20:58:46 <redrobot> Details about the mid-cycle can be found here:
20:58:48 <redrobot> #link https://wiki.openstack.org/wiki/Sprints/BarbicanMitakaSprint
20:58:59 <redrobot> Also, please start adding topics to the etherpad:
20:59:00 <redrobot> #link https://etherpad.openstack.org/p/barbican-mitaka-midcycle
20:59:30 <jhfeng> everyone, please review https://review.openstack.org/#/c/253719/. This should be a simple one
20:59:49 <redrobot> jhfeng will do.
20:59:53 <redrobot> thanks everyone for coming!
20:59:56 <redrobot> #endmeeting