Monday, 2015-11-09

*** ccneill_ has quit IRC00:04
*** ccneill_ has joined #openstack-barbican01:59
*** su_zhang has joined #openstack-barbican02:01
*** ccneill_ has quit IRC02:18
*** everjeje has quit IRC02:27
*** kebray has joined #openstack-barbican02:34
*** su_zhang has quit IRC02:52
*** yuanying has quit IRC03:22
*** yuanying has joined #openstack-barbican04:07
*** dave-mccowan has quit IRC04:11
*** kebray has quit IRC04:14
*** kebray has joined #openstack-barbican04:15
*** kebray has quit IRC04:52
*** kebray has joined #openstack-barbican04:56
*** jamielennox is now known as jamielennox|away04:57
*** jamielennox|away is now known as jamielennox05:24
*** su_zhang has joined #openstack-barbican05:25
*** yfujioka has joined #openstack-barbican06:15
yfujiokahello, can I ask about deployment?06:28
yfujiokawe have no plan for provide CA. in this case, barbican-worker is no need?06:30
*** su_zhang has quit IRC06:50
*** mixos has quit IRC07:17
*** mixos has joined #openstack-barbican07:36
*** yfujioka has quit IRC07:43
*** yfujioka has joined #openstack-barbican07:44
*** zigo has quit IRC08:16
*** zigo has joined #openstack-barbican08:19
*** kebray has quit IRC08:34
*** yuanying has quit IRC08:36
*** yuanying has joined #openstack-barbican08:36
*** jamielennox is now known as jamielennox|away08:42
*** jaosorior has joined #openstack-barbican09:01
*** shohel has joined #openstack-barbican09:04
*** everjeje has joined #openstack-barbican09:10
*** openstack has joined #openstack-barbican09:18
*** mixos has quit IRC09:26
*** jaosorior has quit IRC10:24
*** jaosorior has joined #openstack-barbican10:24
*** jaosorior has quit IRC10:25
*** jaosorior has joined #openstack-barbican10:25
*** shohel has quit IRC10:46
*** shohel has joined #openstack-barbican11:32
*** shohel has quit IRC11:37
*** shohel has joined #openstack-barbican11:38
*** peter-hamilton has joined #openstack-barbican12:06
*** ig0r__ has joined #openstack-barbican12:17
*** shohel has quit IRC12:35
*** shohel has joined #openstack-barbican12:50
*** _elmiko is now known as elmiko13:20
jaosoriorping alee13:30
*** shohel has quit IRC13:30
*** shohel has joined #openstack-barbican13:31
*** su_zhang has joined #openstack-barbican14:04
*** shohel has quit IRC14:07
*** dave-mccowan has joined #openstack-barbican14:23
*** su_zhang has quit IRC14:30
*** su_zhang has joined #openstack-barbican14:38
*** su_zhang has quit IRC14:40
*** spotz_zzz is now known as spotz14:50
*** stevemar_ has joined #openstack-barbican15:13
*** kfarr has joined #openstack-barbican15:14
*** openstackgerrit has quit IRC15:17
*** openstackgerrit has joined #openstack-barbican15:17
*** jhfeng has joined #openstack-barbican15:17
*** silos has joined #openstack-barbican15:27
*** rellerreller has joined #openstack-barbican15:32
*** jmckind has joined #openstack-barbican15:44
jaosoriorping alee, alee_15:44
redrobotyfujioka if you don't have a barbican-worker you won't be able to provision new keys either.15:55
*** shohel has joined #openstack-barbican15:57
*** woodster_ has joined #openstack-barbican16:07
*** darrenmoffat has quit IRC16:11
*** darrenmoffat has joined #openstack-barbican16:13
alee_jaosorior, pong16:14
*** _edmund has joined #openstack-barbican16:15
*** diazjf has joined #openstack-barbican16:16
dave-mccowanalee_ ping16:17
alee_dave-mccowan, pong16:17
dave-mccowanbarbican + cinder is working in liberty, right?16:17
*** kebray has joined #openstack-barbican16:18
*** ccneill_ has joined #openstack-barbican16:18
*** ccneill_ is now known as ccneill16:19
*** mixos has joined #openstack-barbican16:19
*** kebray has quit IRC16:19
*** kebray has joined #openstack-barbican16:20
alee_dave-mccowan, yup16:20
alee_dave-mccowan, barbican + nova + cinder16:20
alee_dave-mccowan, though I did have to add some config to both nova and cinder16:21
dave-mccowanalee_ did you (or can you) :-) post your config somewhere?16:21
alee_dave-mccowan, so I've been doing this --16:21
alee_dave-mccowan, set up two vanilla vms (ipa and openstack) using https://github.com/vakwetu/rdo-vm-factory  (using the vanilla install)16:23
alee_dave-mccowan, then this : https://github.com/vakwetu/rippowam16:23
alee_dave-mccowan, in particular -- the barbican config is in ..16:23
alee_dave-mccowan, just a sec ..16:24
*** diazjf has quit IRC16:28
openstackgerritJeff Feng proposed openstack/barbican: Using session pool for p11 opertions  https://review.openstack.org/24320216:28
alee_dave-mccowan, so in the last link - rippowam, I'm setting up a bunch of stuff16:33
alee_dave-mccowan, in particular, I'm setting up barbican to talk to dogtag16:33
alee_dave-mccowan, and setting up barbican behind haproxy so that we are using SSL endpoints16:34
alee_which means I need to define configs16:34
alee_dave-mccowan, all the config for barbican takes place in https://github.com/vakwetu/rippowam/tree/master/roles/packstack/tasks16:35
alee_dave-mccowan, in particular you should look at barbican.yml, barbican-haproxy.yml16:35
alee_dave-mccowan, test-encrypted-volumes.yml16:36
alee_and service-auth.yml16:36
*** diazjf has joined #openstack-barbican16:37
dave-mccowanalee_ awesome.  thanks!16:37
alee_dave-mccowan, its also using an older version of barbican, I need to update it16:38
dave-mccowanalee_ two more questions:  Is Liberty the first release with the Nova/Cinder code?  Does each volume have it's own encryption key?16:38
alee_dave-mccowan, no I think the code was in fro kilo16:39
alee_dave-mccowan, rellerreller might be able to answer that better16:40
alee_dave-mccowan, and yes - each volume has its own encryption key16:40
alee_dave-mccowan, let me get you a link to my demo video ..16:40
alee_dave-mccowan, https://vakwetu.fedorapeople.org/encrypted_volumes.webm  for your viewing pleasure16:41
dave-mccowanalee_ very nice!  i'm sorry i missed you at the booth to get the live version :-)16:46
*** _edmund has quit IRC16:47
*** gyee has joined #openstack-barbican16:48
alee_dave-mccowan, :)16:57
jaosoriorGot an easy review for people https://review.openstack.org/#/c/199608/17:00
*** jmckind is now known as jmckind_17:00
*** jmckind_ is now known as jmckind17:00
*** su_zhang has joined #openstack-barbican17:01
*** shohel has quit IRC17:02
*** diazjf has quit IRC17:03
*** jorge_munoz has joined #openstack-barbican17:03
*** edtubill has joined #openstack-barbican17:06
*** edtubill has quit IRC17:08
*** edtubill has joined #openstack-barbican17:08
*** nkinder has joined #openstack-barbican17:13
*** jmckind is now known as jmckind_17:18
*** su_zhang has quit IRC17:21
*** jmckind_ is now known as jmckind17:21
*** su_zhang has joined #openstack-barbican17:21
*** su_zhang has quit IRC17:28
*** maxabidi has joined #openstack-barbican17:37
*** edtubill has quit IRC17:38
*** diazjf has joined #openstack-barbican17:45
*** edtubill has joined #openstack-barbican17:47
*** maxabidi has quit IRC17:47
*** stevemar_ has quit IRC17:48
*** silos has left #openstack-barbican17:49
openstackgerritMerged openstack/python-barbicanclient: Remove invalid skipping of tests  https://review.openstack.org/19960817:51
openstackgerritMerged openstack/barbican: Change unit tests in test_utils.py and test_contaiers.py to use CONF.set_override  https://review.openstack.org/23439818:09
*** jaosorior has quit IRC18:09
rellerrellerdave-mccowan what was the question?18:10
rellerrellerdave-mccowan which Nova/Cinder code?18:11
*** jmckind is now known as jmckind_18:11
rellerrellerdave-mccowan I think we implemented cinder volume encryption in Havana.18:12
rellerrellerdave-mccown joel-coffman just confirmed it was in Havana18:15
dave-mccowanrellerreller  thanks.  that was the question.18:19
*** su_zhang_ has joined #openstack-barbican18:25
*** _edmund has joined #openstack-barbican18:30
*** peter-hamilton has quit IRC18:54
*** ccneill_ has joined #openstack-barbican18:54
*** ccneill__ has joined #openstack-barbican18:55
*** ccneill has quit IRC18:56
*** ccneill_ has quit IRC18:59
*** su_zhang_ has quit IRC19:01
*** rellerreller has quit IRC19:03
openstackgerritFernando Diaz proposed openstack/barbican: Add User Metadata Functions to Barbican API  https://review.openstack.org/24326319:04
*** stevemar_ has joined #openstack-barbican19:05
*** rellerreller has joined #openstack-barbican19:08
*** su_zhang has joined #openstack-barbican19:15
dave-mccowanA reminder to the US based Barbicaneers: with the end of daylight savings time, we begin a period of "oops I missed that IRC meeting".  :-D For the next 6 months, our weekly meeting time is 3pm EST  /  2pm CST.19:17
*** silos has joined #openstack-barbican19:24
*** kebray has quit IRC19:46
*** everjeje has quit IRC19:47
*** _edmund1 has joined #openstack-barbican19:55
*** jmckind_ is now known as jmckind19:57
*** _edmund has quit IRC19:59
*** pdesai has joined #openstack-barbican20:00
*** rellerreller has quit IRC20:01
*** rellerreller has joined #openstack-barbican20:01
openstackgerritJason Fritcher proposed openstack/barbican: Reimplement p11_crypto and pkcs11 modules  https://review.openstack.org/24329120:10
*** ccneill has joined #openstack-barbican20:15
*** ccneill__ has quit IRC20:17
*** su_zhang has quit IRC20:22
*** su_zhang has joined #openstack-barbican20:23
*** pdesai has quit IRC20:24
*** pdesai has joined #openstack-barbican20:26
*** everjeje has joined #openstack-barbican20:28
*** su_zhang has quit IRC20:30
*** su_zhang has joined #openstack-barbican20:32
*** kebray has joined #openstack-barbican20:45
mixos@woodster_: @redrobot: I sent you a fix proposal. Would you check and inform me of your thoughts ?20:50
*** su_zhang has quit IRC20:54
*** _edmund1 has quit IRC20:55
*** jmckind is now known as jmckind_20:55
*** _edmund has joined #openstack-barbican20:55
*** maxabidi has joined #openstack-barbican21:01
*** silos has left #openstack-barbican21:02
rellerrellerelmiko haha I caught your message on the meeting ;)21:02
edtubillping rellerreller21:02
rellerrelleredtubill pong21:02
edtubillrellerreller I wanted to see if you could look at https://github.com/edtubillara/federated-barbican/blob/master/spec/federated-castellan.rst21:02
edtubillAnd I wanted to see how crazy the #Type 2 idea was.21:03
edtubillrellerreller: For automaping tenants to barbican hosts...21:03
rellerrelleredtubill I can look at it, not a problem.21:03
edtubillrellerreller: cool thx21:03
rellerrelleredtubill I'll pull in kfarr as well.21:04
elmikorellerreller: sigh... totally fumbled that one =(21:04
elmikoand dave-mccowan even called it in channel earlier21:04
kfarredtubill, rellerreller, you're just talking about type 2 yeah?21:05
edtubillkfarr: yeah I just wanted some feedback on type 221:05
*** jmckind_ is now known as jmckind21:06
kfarredtubill rellerreller, I like the part about keeping the Barbican API the same21:10
kfarrI can't really speak much about scoped tokens because I'm not that familiar with them21:11
kfarrit's an interesting idea to have the mappings in a config file, but concerned about calling it castellan-policy21:11
*** spotz is now known as spotz_zzz21:12
kfarrbecause then you're tightly coupling Barbican to Castellan, which isn't necessarily a requirement now21:13
*** jmckind is now known as jmckind_21:13
diazjfthe scoped-token will pretty much be the X-Auth-Token thats scoped towards the project on the Barbican we are Federating to21:13
edtubillkfarr: yeah I just wanted to throw the idea out there, the naming convention can be changed. Hmm I guess there should be a solution that isn't tightly coupled21:14
kfarredtubill, I'm only concerned about it for the people who may have integrated Barbican without Castellan21:17
rellerrelleredtubill I think I have similar concerns to kfarr21:18
rellerrelleredtubill The first is that it seems like a new Castellan API will need to be created specifically for Barbican.21:18
kfarrOne thing I'm not clear on is what is going to be reading and acting on that policy file?21:19
rellerrelleredtubill the main goal of Castellan is to provide a generic interface to allow easy replacement of a key manager from Barbican to KMIP to any other key management protocol.21:19
edtubillkfarr, rellerreller: Oh I see, so for people who don't use castellan but use a custom application that calls barbican21:19
rellerrelleredtubill we have use cases that will not use Barbican at all.21:20
redrobotedtubill more like people who use Castellan who don't use Barbican at all21:20
rellerrelleredtubill some people want a private cloud that has a KMIP device for all key management.21:20
edtubillThe thing that would be reading and acting on the policy file would be a 'federated' keymanager that is a subclass from the keymanager21:21
rellerrelleredtubill my other big comment is that I'm not sure this is needed. I would like to see this in the context of a use case that uses a key.21:21
*** jmckind_ is now known as jmckind21:21
rellerrelleredtubill in walking through the use case of cinder volume encryption I do not believe a lot of this is necessary.21:21
rellerrelleredtubill I believe you can solve a lot of this by having the metadata contain the URL and provider type (Barbican, KMIP, etc.) for the key.21:22
edtubillAnd for those who use Castellan that don't use barbican at all... I think I would add an option for keymanager class in the castellan-policy file21:22
edtubillrellerreller: I was just proposing a solution to change other services as least as possible21:23
*** maxabidi has quit IRC21:23
rellerrelleredtubill what services have this problem now?21:23
edtubillI also had a question on if Castellan was going to be used in nova/cinder?21:23
rellerrelleredtubill we are integrating Castellan into Nova and Cinder this release.21:24
rellerrellerThey currently have the old key manager code, so we are already kind of there.21:24
*** spotz_zzz is now known as spotz21:24
edtubillrellerreller: I guess you make a good point :) since they don't use Castellan yet.21:24
diazjfrellerreller, speaking of Castellan integration, I got this spec up: https://review.openstack.org/#/c/241068/ waiting for some swift people to take a look at it.21:25
edtubillrellerreller: So I was thinking if you had to change the services to keep track of the configuration you would have to make a bunch of changes21:25
rellerrelleredtubill we originally tried to put the KeyManager interface into Oslo back in the Grizzly release, but we were rejected. They said we needed to prove that it was common amongst the projects first.21:25
*** spotz is now known as spotz_zzz21:26
rellerrellerSo then we simply put the code twice and hoped oslo would then take us. They didn't. Eventually we decided to start a new library.21:26
edtubillrellerreller: oh I see and that became Casetellan?21:26
*** spotz_zzz is now known as spotz21:26
edtubill*Castellan21:26
rellerrelleredtubill the change would not be big. Right now the code assumes the same type of key manager. We just need to add a few lines to specify a provider type.21:27
rellerrelleredtubill correct.21:27
rellerrelleredtubill the first release of Castellan KeyManager contained the code from Cinder.21:27
rellerrellerdiazjf I'm behind on reviews. Ping me tomorrow to get on that.21:28
diazjfrellerreller, no worries, appreciate it21:29
rellerrellerdiazjf You have a bunch of reviews. Could you provide a prioritized list?21:29
rellerrellerdiazjf like an etherpad page that briefly says what you are trying to do and then lists the reviews in order of how to achieve that.21:30
diazjfrellerreller, yeah I'll make an etherpad with some descriptions and their urgency21:30
rellerrellerdiazjf thanks!21:30
diazjfread my mind!21:30
rellerrellerdiazjf and edtubill I need to run now. Have a good evening :)21:30
diazjfsame to you :)21:31
*** su_zhang has joined #openstack-barbican21:31
edtubillrellerreller and kfarr: thx for the feedback and info!21:31
kfarrwhoa diazjf, so it's not just Castellan that needs to accept keystone middleware tokens, but Barbican as well?21:34
diazjfkfarr, not Barbican, but Barbican Client I believe.21:35
diazjfkfarr, Barbican can use other auth systems, but they must have variables like project_id etc.21:36
diazjfredrobot: any input that you can give on the above21:37
redrobotdiazjf kfarr you are correct in that Barbican does not require Keystone tokens.21:40
*** kebray has quit IRC21:40
redrobotThe Authentication/Authorization requirement for Barbican is that a request to Barbican has to include the "X-Project-Id" and "X-Roles" headers21:40
*** rellerreller has quit IRC21:40
redrobotthe easiest way to provide those headers is to put Keystone Middleware in the request pipeline right before barbican.21:41
redrobotKeystone Middleware expects an "X-Auth-Token" header and then talks to Keystone to validate the token.  If the token is valid, the Keystone response is used to add the X-Project-Id and X-Roles headers to the request.21:42
redrobotBarbican does not care what AuthZ/AuthN service you use, as long as that service injects the required headers before passing the request to Barbican21:43
diazjfredrobot, I'll talk to acoles from swift and see if its acceptable for those fields to be required. kfarr, in the summit the Swift Community proposed that we have pluggable auth in order for Castellan to be used in the Swift Keymaster21:43
diazjfsince many swift users dont necessarily rely on keystone.21:44
kfarrdiazjf, okk, what does pluggable auth look like?  Is it the if/else statement you have in a patch right now?21:44
redrobot...  I think X-User-Id may be required as well21:45
redrobotfor  ACLs to work anyway21:45
*** kebray has joined #openstack-barbican21:45
diazjfkfarr, still need to figure that one out. But we would need to support something like: http://docs.openstack.org/developer/swift/development_auth.html21:46
diazjfredrobot, would it be correct to say that certain features wont work with certain auth systems, or full Barbican API is always required.21:47
kfarrdiazjf https://review.openstack.org/#/c/235671/ is only a temporary fix then?21:47
diazjfkfarr, yup. In the future all of that will be changed. But its good to have for the meantime21:48
kfarrdiazjf okk just checking21:48
diazjfkfarr thanks :)21:49
kfarrdiazjf also sorry I've been sorta slow to review your patches lately!  I'll get on that this week21:50
diazjfkfarr, no worries, I know I've put up alot :/ thanks for taking the time :)21:51
arunkantkfarr: ping.21:52
kfarrarunkant pong21:52
arunkantkfarr: question about https://bugs.launchpad.net/nova/+bug/150593021:52
openstackLaunchpad bug 1505930 in OpenStack Compute (nova) "Fix key manager service endpoints in devstack Nova ephemeral" [Undecided,In progress] - Assigned to Arun Kant (arunkant-uws)21:52
arunkantkfarr: You mentioned that there is plan to rework key manager..what kind of changes are planned ?21:53
kfarrarunkant, so the key manager in Nova was the basis for Castellan, so the plan is to remove all that key manager code and replace it with Castellan21:54
arunkantkfarr: Okay. What is the approx. timeline for those changes? We need nova ephermal encryption working and were planning to internally backport the fix for liberty21:56
kfarrarunkant, well, the plan was to get it up by m-221:56
kfarrI already see a few quirks that are going to happen with the replacement, but hopefully I will get it done much sooner than that21:57
notmynamediazjf: acoles is likely out this week. he got called to jury duty. something I can help with?21:58
arunkantkfarr, so that will be in january timeframe...okay..lets see if the needed fix can land before that.  Also so this will be replacement or additional option to use on nova side ?21:59
*** _edmund has quit IRC22:00
kfarrcomplete replacement22:00
diazjfnotmyname, just wondering if someone from the swift-side could go over https://review.openstack.org/#/c/241068/22:00
diazjfnotmyname, in order to see what exactly are the requirements to get Castellan into the Swift Keymaster22:01
diazjfnotmyname, thanks for the reply :)22:01
notmynamediazjf: what are the requirements barbican has now? or castellan specifically? is it currently depending on code or functionality provided by keystone?22:01
arunkantkfarr, okay. So does castellan now provide another plugin option other than barbicanclient ?22:01
*** jmckind has quit IRC22:02
kfarrarunkant, no, but the key manager in Nova doesn't either.  Unless you wrote one?22:02
diazjfnotmyname, so Barbican relies on X-Project-Id, X-Project-Roles, etc. Other auth systems can be made but must use these fields. redrobot, correct me if I'm wrong/22:03
diazjfnotmyname, for Barbican Key Manager, Castellan  requires those things as well22:04
notmynameah, right. castellan is a client-side thing, right? so yeah it has to send keystone headers if the barbican key manager is being used22:04
arunkantkfarr: okay. Was just checking if there is direct kmip integration added yet ? Last time when I checked, did not see what was the difference. Anyhow looks like need to go through recent castellan code.22:05
diazjfnotmyname, correct!22:05
arunkantkfarr: thanks.22:06
diazjfnotmyname, So in order to have Castellan in the Key Manager, then we need to remove that dependency correct. And we should support auth systems which don't necessarily have X-Project-Id, etc/22:07
diazjfnotmyname, by KeyManager I mean swift KeyMaster22:07
redrobotdiazjf I have thought about the auth problem in Castellan before...  at first, I didn't quite understand what the "context" object was that was required by Castellan.  kfarr cleared that up by explaining that it is supposed to be an instance of oslo.context22:09
redrobotdiazjf  my assumption is that most projects would have an oslo.context readily available22:09
redrobotdiazjf is that not the case for Swift?22:09
notmynamediazjf: so castellan today requires keystone headers no matter the key manager backed?22:10
notmynameredrobot: swift does not use oslo.context22:10
notmyname(nor am I even sure what that does)22:10
diazjfnotmyname, just for the Barbican backend, it believe it is currently the only implemented one. kfarr, you may be able to better answer this22:11
redrobotdiazjf Castellan should not be backend-specific22:12
*** mixos has quit IRC22:12
redrobotdiazjf the current interface requires an instance of oslo.context regardless of backend being used22:12
kfarrYeah, it was my understanding that oslo.context was a global thing, swift is first in OpenStack that needed key management that I've seen use it22:13
redrobotnotmyname they KeyMaster in Swift requires some sort of auth parameters to be passed?  or does it just return keys willy-nilly ?22:14
diazjfredrobot, I mean like in https://github.com/openstack/castellan/blob/master/castellan/key_manager/barbican_key_manager.py#L13222:14
diazjfthe barbican backend looks specifically for keystone22:14
redrobotdiazjf  note that the oslo.context instance is being passed into that method22:14
diazjfredrobot, ohh gotcha22:15
redrobotdiazjf  the Barbican implementation does assume Keystone, but it requires that oslo.context to be able to build a client with the right keystone credentials22:15
redrobotdiazjf  it should be possible to build an alternative Barbican implementation that uses a different auth system if needed22:16
diazjfredrobot, gotcha, but we will still require project_id, etc.22:16
redrobotdiazjf  well, those are guaranteed to be present in an oslo.context instance22:16
redrobotdiazjf ... I think ... the idea was that oslo.context should hold enough info for the key manager backend to be able to auth/deny the key request22:17
redrobotdiazjf I would like to pick kfarr 's brain about what a possible KMIP impl would look like22:18
diazjfredrobot, I see, but since swift doesn't use oslo.context we run into a dilema22:18
redrobotdiazjf  indeed22:18
redrobotdiazjf one huge assumption is that the KMIP implementation of Castellan would be able to use that instance of oslo.context to negotiate authorization with the KMIP device22:19
redrobotdiazjf an alternative that I've considered before is that Castellan may need to define Auth objects22:20
kfarrredrobot, yeah, and that's really the only thing holding us back from the KMIP impl is for a vendor to implement the software side of a KMIP device that would accept keystone tokens22:20
notmynamefrom what I can tell from docs (http://docs.openstack.org/developer/oslo.context/usage.html) and code (http://git.openstack.org/cgit/openstack/oslo.context/tree/oslo_context/context.py) oslo.context is a ... dictionary?22:21
*** mixos has joined #openstack-barbican22:22
redrobotkfarr hmmm... I had envisioned a smart KMIP impl that is able to map oslo.context to a KMIP auth object22:22
redrobotkfarr  s/auth object/credential object22:24
kfarrredrobot, I am not so sure anymore.  The way you propose that sounds so reasonable, but I think there was a reason why that wasn't going to work22:24
diazjfnotmyname: its a Request Object, https://github.com/openstack/oslo.context/blob/master/oslo_context/context.py notmyname, redrobot, so the question is would swift be able to implement oslo.context or should Barbican have pluggable auth.22:25
redrobotdiazjf  Barbican already has pluggable auth...  I think the question should be whether Castellan needs to implement generic auth objects22:26
redrobotdiazjf ... but then we still have the problem of mapping a generic auth object to a kmip credential22:27
redrobotkfarr  I guess it's because oslo.context wouldn't have enough info to create a kmip credential?22:27
diazjfredrobot, I'll update the spec to include the change22:28
redrobotdiazjf  I guess it comes down to ownership of the key material...22:30
redrobotdiazjf as in, who owns the key that Swift is storing in the KeyMaster?22:30
notmynameit depends ;-)22:30
redrobotdiazjf  is it owned by Swift istelf?  or is it owned by the same user who owns the container where they key is used?22:30
notmynamein our first version the key will be owned by swift22:31
redrobotnotmyname  that's my favorite security question :D22:31
redrobotnotmyname i mean, "it depends" is my favorite security answer22:31
* redrobot feels like a real security professional when answering "it depends" ;)22:31
notmynameor more specifically, it depends on the keymaster and the first keymaster that we will have upstream will have the cluster own the key22:31
notmynameactually, as of the summit, the first version will very likely not use castellan. later versions likely will, though22:32
redrobotdiazjf notmyname  so another way to think about the oslo.context being passed to Castellan is that it represents the owner of the key material.22:33
diazjfredrobot. notmyname, that was the idea in the Keymaster I was working on that relied on Keystone22:34
redrobotdiazjf which idea?  that Swifts owns the keys?22:36
diazjfredrobot, correct, it was an IBM prototype.22:37
diazjfnot swift22:37
diazjfI mean the user who owns the container in swift22:38
*** jamielennox|away is now known as jamielennox22:38
diazjfor actually user who owns the account22:38
redrobotdiazjf  I see...  well, to be able to achieve that, Swifts needs to pass on the information about the user making the request (ie. the context)22:39
kfarrredrobot, swift stores all the user info in a keystone middleware object22:39
diazjfredrobot, and since when we make the request for a key it goes through Castellan, Castellan should be able to support the other possible auth system that swift has in place22:40
diazjfkfarr, notmyname, even with temp_auth, etc.22:40
diazjfIf thats the case then https://review.openstack.org/#/c/235671/ may be sufficient22:41
notmynamejust to add something confounding to the mix, think about the case when it's public data that's being requested. where's the identity come from then?22:42
notmyname(which is why the first implementation will have the key owned by the cluster itself)22:44
kfarrif it's public data, then what's the benefit of encrypting it?22:46
notmynamein all cases, this is for server-side encryption of data on a drive22:48
notmynameno, it might not make sense to encrypt public data22:48
notmynamebut that's one example22:49
*** stevemar_ has quit IRC22:49
notmynameanother would be tempurls. where I give you a url that has access to one of my objects. it's not public, but the request also doesn't have any info about my key22:49
*** _edmund has joined #openstack-barbican22:50
notmynameanother is container sync that needs to read the data to send it to another cluster. in that case it's not even done in the context of a request. same with the container reconciler where an object is moved from one storage policy to another.22:50
notmynamepoint is, for the first iteration we'll have something that has 100% functionality and encrypts the data but the cluster owns the key and has access to it. other later keymaster implementations may do something different, but if the key isn't available then you can't have full functionality22:52
redrobotnotmyname  makes sense22:53
kfarrYeah, that's a tricky point22:56
diazjfSo Castellan should be able to use Unathenticated Context22:58
redrobotdiazjf what backend do you want to use that doesn't require authentication?22:58
diazjfredrobot, I would like to see it with Barbican22:59
redrobotdiazjf I want to make sure I understand your use case23:01
redrobotdiazjf so, you're working with a cloud where Keystone is not used for authentication...23:01
redrobotdiazjf  in that cloud, you want to deploy Barbican23:01
redrobotdiazjf  for argument's sake you're using an auth service called XXX23:02
diazjfredrobot, notmyname, so what I want to achieve is that any auth system can be used in order to talk to Castellan using any backend and be able to retrieve a Secret.23:02
*** edtubill has quit IRC23:03
diazjfnotmyname, is what was mentioned in my above comment, what is necessary for Castellan use in the swift keymaster?23:03
redrobotdiazjf  that's a really broad use case23:04
*** jhfeng has quit IRC23:04
redrobotso, as I understand it, Swift is most commonly deployed with a non-keystone auth front end, yes?23:04
notmynamethat is a common deployment model23:05
redrobotbut it CAN be deployed behind Keystone?23:06
*** mixos has quit IRC23:06
diazjfredrobot, it could23:07
redrobotwhat's the abstraction in Swift that can deal with both Keystone and the commonly-used-not-keystone-auth ?23:07
notmynamethe auth middleware (zero or more of which are used at the same time) implements a callback that's put into the wsgi environment. later it's called and the result is used to determine if the request is authorized23:08
redrobotnotmyname hmm... interesting...23:10
openstackgerritJason Fritcher proposed openstack/barbican: Reimplement p11_crypto and pkcs11 modules  https://review.openstack.org/24329123:12
redrobotdiazjf so I guess your requirement is that you have to deploy Barbican alongside Swift where both are sitting behind the commonly-used-not-keystone-auth service?23:13
diazjfredrobot, exactly!23:13
*** jmckind has joined #openstack-barbican23:13
diazjfthat way if a company already had another auth system in place they can just add Barbican without keystone support23:14
diazjfredrobot, notmyname, and thats since its a requirement from swift to get Castellan into the Keymaster23:15
diazjf^ from the swift community23:15
redrobotdiazjf and I assume Castellan is preferred because you may also want to deploy Swift + commonly-used-not-keystone-auth + KMIP device and strictly no barbican?23:18
diazjfredrobot, exactly23:18
redrobotdiazjf ok, so to do this in a way that Swift ends up owning all the keys is easy23:20
redrobotdiazjf  but to do it in a way where the user interacting with Swift owns the keys is going to be tough... mainly because of all the stuff notmyname talked about23:20
redrobotfor the first case (swfit + barbican + some-other-auth) you woud need:23:21
redrobot1. A wsgi middleware that can accept requests that include the some-other-auth credentials and turn those into the X-Whatever headers that Barbican requires.23:21
redrobot2. An account in that some-other-auth that is owned by Swift23:22
redrobot3. Swift would need to build an oslo.context using the credentiasl for that some-other-auth account.23:22
redrobot4. A second Barbican implementation of Castellan that takes the oslo.context created in 3 and then sends requests to Barbican (which are processed by the middleware in 1)23:23
*** kebray has quit IRC23:24
redrobotfor the second case (swift + kmip device + some-other-auth) you would need:23:24
redrobot1. Credentials in the KMIP device that are owned by Swift23:24
redrobot2. Swift would need to build an oslo.context using the credentials for that kmip device account23:25
redrobot3. A KMIP implementation of Castellan that is able to take the oslo.context created in 2, extracts the credentials for account created in 1, and then retrieves the key from the KMIP device using those credentials23:26
redrobotI understand that the Swift community may not want to add support for oslo.context... so an alternative there would be to add generic Auth (or Credential) objects to Castellan.23:27
redrobotthen the credential objects woudl be built and passed to castellan, and the impls would have to use those to talk to the respective backends23:28
diazjfredrobot, thanks that was very helpful! :) My question is would the currently available wsgi middleware's need to be updated. notmyname, for 1st iteration of Castellan in the Keymaster would Swift owning all the keys be acceptable and in the future we add user specific support, or should we start with option 2?23:29
*** su_zhang has quit IRC23:29
*** spotz is now known as spotz_zzz23:29
*** su_zhang has joined #openstack-barbican23:30
diazjf^ wsgi middlewares = some-other-auth23:30
redrobotdiazjf  I would think that the some-other-auth middleware would need to be written from scratch.  It seems that Swift and Barbican are fundamentally different in the way they use the middlewares.23:31
diazjfredrobot, notmyname, so auth-systems like temp-auth would need to be re written then :(23:33
notmynameI'm not sure. mostly because of my own ignorance on the barbican/castellan side23:33
notmynamehowever, since castellan integration is further down the road for swift, it's not a time-sensitive question from our side23:34
redrobotnotmyname Barbican requires a few headers for Authentication...  the headers are provided by keystonemiddleware after processing a keystone token.  We're basically telling people that they can use whatever auth they want in front of barbican as long as the request ends up having those same headers after it's processed by that other auth system.23:35
notmynameI'd anticipate that any request sent to barbican from swift (via castellan or otherwise) would be constructed by swift and sent on. ie not reusing the client's request23:36
diazjfnotmyname, like redrobot discussed in case1, but my worry is how are we going to make currently used auth systems compatible.23:43
yfujiokaredrobot: thank you for your response. and sorry, I have not understood about new key.23:45
yfujiokais that /v1/orders?23:45
redrobotyfujioka hi!  ... yes, all requests to /v1/orders are processed by the barbican-worker23:46
redrobotyfujioka this includes both orders for Certs, which are sent to a CA and orders for keys which are sent to the secret-store23:46
redrobotyfujioka you can deploy Barbican without barbican-worker (we're actually doing just that at Rackspace)23:46
redrobotyfujioka but we did have to block the /v1/orders endpoint altogether23:47
diazjfredrobot, notmyname, thanks for the input. I gotta run, can we continue this discussion tomorrow. I'm hoping to have some work on this done for the M release :)23:47
redrobotyfujioka which means you lose the capability of ordering symmetric and asymmetric keys.23:47
notmynameyeah, I've got to run too23:47
diazjfnotmyname, redrobot, I'll ping you guys tomorrow, Thanks!23:48
yfujiokaredrobot: thank you. honestly, I don't understand about /v1/orders. is this need for Neutron LBaaS V2 with TLS?23:51
yfujiokaredrobot: my understanding is /v1/secrets and /v1/orders are need for LBaaS.23:52
redrobotyfujioka no, I believe LBaaS only uses the /v1/secrets and /v1/containers endpoints23:52
redrobotyfujioka  if you only want to suport the LBaaS use cases then you should be ok without barbican-worker23:53
yfujiokaredrobot: really thank you!23:54
redrobotyfujioka you're welcome!23:55
*** diazjf has quit IRC23:57
yfujiokaredrobot: I feel if this is documented, it is so helpful. I think submit patch if I have time.23:59

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