| *** ccneill_ has quit IRC | 00:04 | |
| *** ccneill_ has joined #openstack-barbican | 01:59 | |
| *** su_zhang has joined #openstack-barbican | 02:01 | |
| *** ccneill_ has quit IRC | 02:18 | |
| *** everjeje has quit IRC | 02:27 | |
| *** kebray has joined #openstack-barbican | 02:34 | |
| *** su_zhang has quit IRC | 02:52 | |
| *** yuanying has quit IRC | 03:22 | |
| *** yuanying has joined #openstack-barbican | 04:07 | |
| *** dave-mccowan has quit IRC | 04:11 | |
| *** kebray has quit IRC | 04:14 | |
| *** kebray has joined #openstack-barbican | 04:15 | |
| *** kebray has quit IRC | 04:52 | |
| *** kebray has joined #openstack-barbican | 04:56 | |
| *** jamielennox is now known as jamielennox|away | 04:57 | |
| *** jamielennox|away is now known as jamielennox | 05:24 | |
| *** su_zhang has joined #openstack-barbican | 05:25 | |
| *** yfujioka has joined #openstack-barbican | 06:15 | |
| yfujioka | hello, can I ask about deployment? | 06:28 |
|---|---|---|
| yfujioka | we have no plan for provide CA. in this case, barbican-worker is no need? | 06:30 |
| *** su_zhang has quit IRC | 06:50 | |
| *** mixos has quit IRC | 07:17 | |
| *** mixos has joined #openstack-barbican | 07:36 | |
| *** yfujioka has quit IRC | 07:43 | |
| *** yfujioka has joined #openstack-barbican | 07:44 | |
| *** zigo has quit IRC | 08:16 | |
| *** zigo has joined #openstack-barbican | 08:19 | |
| *** kebray has quit IRC | 08:34 | |
| *** yuanying has quit IRC | 08:36 | |
| *** yuanying has joined #openstack-barbican | 08:36 | |
| *** jamielennox is now known as jamielennox|away | 08:42 | |
| *** jaosorior has joined #openstack-barbican | 09:01 | |
| *** shohel has joined #openstack-barbican | 09:04 | |
| *** everjeje has joined #openstack-barbican | 09:10 | |
| *** openstack has joined #openstack-barbican | 09:18 | |
| *** mixos has quit IRC | 09:26 | |
| *** jaosorior has quit IRC | 10:24 | |
| *** jaosorior has joined #openstack-barbican | 10:24 | |
| *** jaosorior has quit IRC | 10:25 | |
| *** jaosorior has joined #openstack-barbican | 10:25 | |
| *** shohel has quit IRC | 10:46 | |
| *** shohel has joined #openstack-barbican | 11:32 | |
| *** shohel has quit IRC | 11:37 | |
| *** shohel has joined #openstack-barbican | 11:38 | |
| *** peter-hamilton has joined #openstack-barbican | 12:06 | |
| *** ig0r__ has joined #openstack-barbican | 12:17 | |
| *** shohel has quit IRC | 12:35 | |
| *** shohel has joined #openstack-barbican | 12:50 | |
| *** _elmiko is now known as elmiko | 13:20 | |
| jaosorior | ping alee | 13:30 |
| *** shohel has quit IRC | 13:30 | |
| *** shohel has joined #openstack-barbican | 13:31 | |
| *** su_zhang has joined #openstack-barbican | 14:04 | |
| *** shohel has quit IRC | 14:07 | |
| *** dave-mccowan has joined #openstack-barbican | 14:23 | |
| *** su_zhang has quit IRC | 14:30 | |
| *** su_zhang has joined #openstack-barbican | 14:38 | |
| *** su_zhang has quit IRC | 14:40 | |
| *** spotz_zzz is now known as spotz | 14:50 | |
| *** stevemar_ has joined #openstack-barbican | 15:13 | |
| *** kfarr has joined #openstack-barbican | 15:14 | |
| *** openstackgerrit has quit IRC | 15:17 | |
| *** openstackgerrit has joined #openstack-barbican | 15:17 | |
| *** jhfeng has joined #openstack-barbican | 15:17 | |
| *** silos has joined #openstack-barbican | 15:27 | |
| *** rellerreller has joined #openstack-barbican | 15:32 | |
| *** jmckind has joined #openstack-barbican | 15:44 | |
| jaosorior | ping alee, alee_ | 15:44 |
| redrobot | yfujioka if you don't have a barbican-worker you won't be able to provision new keys either. | 15:55 |
| *** shohel has joined #openstack-barbican | 15:57 | |
| *** woodster_ has joined #openstack-barbican | 16:07 | |
| *** darrenmoffat has quit IRC | 16:11 | |
| *** darrenmoffat has joined #openstack-barbican | 16:13 | |
| alee_ | jaosorior, pong | 16:14 |
| *** _edmund has joined #openstack-barbican | 16:15 | |
| *** diazjf has joined #openstack-barbican | 16:16 | |
| dave-mccowan | alee_ ping | 16:17 |
| alee_ | dave-mccowan, pong | 16:17 |
| dave-mccowan | barbican + cinder is working in liberty, right? | 16:17 |
| *** kebray has joined #openstack-barbican | 16:18 | |
| *** ccneill_ has joined #openstack-barbican | 16:18 | |
| *** ccneill_ is now known as ccneill | 16:19 | |
| *** mixos has joined #openstack-barbican | 16:19 | |
| *** kebray has quit IRC | 16:19 | |
| *** kebray has joined #openstack-barbican | 16:20 | |
| alee_ | dave-mccowan, yup | 16:20 |
| alee_ | dave-mccowan, barbican + nova + cinder | 16:20 |
| alee_ | dave-mccowan, though I did have to add some config to both nova and cinder | 16:21 |
| dave-mccowan | alee_ 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/rippowam | 16:23 |
| alee_ | dave-mccowan, in particular -- the barbican config is in .. | 16:23 |
| alee_ | dave-mccowan, just a sec .. | 16:24 |
| *** diazjf has quit IRC | 16:28 | |
| openstackgerrit | Jeff Feng proposed openstack/barbican: Using session pool for p11 opertions https://review.openstack.org/243202 | 16:28 |
| alee_ | dave-mccowan, so in the last link - rippowam, I'm setting up a bunch of stuff | 16:33 |
| alee_ | dave-mccowan, in particular, I'm setting up barbican to talk to dogtag | 16:33 |
| alee_ | dave-mccowan, and setting up barbican behind haproxy so that we are using SSL endpoints | 16:34 |
| alee_ | which means I need to define configs | 16:34 |
| alee_ | dave-mccowan, all the config for barbican takes place in https://github.com/vakwetu/rippowam/tree/master/roles/packstack/tasks | 16:35 |
| alee_ | dave-mccowan, in particular you should look at barbican.yml, barbican-haproxy.yml | 16:35 |
| alee_ | dave-mccowan, test-encrypted-volumes.yml | 16:36 |
| alee_ | and service-auth.yml | 16:36 |
| *** diazjf has joined #openstack-barbican | 16:37 | |
| dave-mccowan | alee_ awesome. thanks! | 16:37 |
| alee_ | dave-mccowan, its also using an older version of barbican, I need to update it | 16:38 |
| dave-mccowan | alee_ 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 kilo | 16:39 |
| alee_ | dave-mccowan, rellerreller might be able to answer that better | 16:40 |
| alee_ | dave-mccowan, and yes - each volume has its own encryption key | 16: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 pleasure | 16:41 |
| dave-mccowan | alee_ very nice! i'm sorry i missed you at the booth to get the live version :-) | 16:46 |
| *** _edmund has quit IRC | 16:47 | |
| *** gyee has joined #openstack-barbican | 16:48 | |
| alee_ | dave-mccowan, :) | 16:57 |
| jaosorior | Got 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 jmckind | 17:00 | |
| *** su_zhang has joined #openstack-barbican | 17:01 | |
| *** shohel has quit IRC | 17:02 | |
| *** diazjf has quit IRC | 17:03 | |
| *** jorge_munoz has joined #openstack-barbican | 17:03 | |
| *** edtubill has joined #openstack-barbican | 17:06 | |
| *** edtubill has quit IRC | 17:08 | |
| *** edtubill has joined #openstack-barbican | 17:08 | |
| *** nkinder has joined #openstack-barbican | 17:13 | |
| *** jmckind is now known as jmckind_ | 17:18 | |
| *** su_zhang has quit IRC | 17:21 | |
| *** jmckind_ is now known as jmckind | 17:21 | |
| *** su_zhang has joined #openstack-barbican | 17:21 | |
| *** su_zhang has quit IRC | 17:28 | |
| *** maxabidi has joined #openstack-barbican | 17:37 | |
| *** edtubill has quit IRC | 17:38 | |
| *** diazjf has joined #openstack-barbican | 17:45 | |
| *** edtubill has joined #openstack-barbican | 17:47 | |
| *** maxabidi has quit IRC | 17:47 | |
| *** stevemar_ has quit IRC | 17:48 | |
| *** silos has left #openstack-barbican | 17:49 | |
| openstackgerrit | Merged openstack/python-barbicanclient: Remove invalid skipping of tests https://review.openstack.org/199608 | 17:51 |
| openstackgerrit | Merged openstack/barbican: Change unit tests in test_utils.py and test_contaiers.py to use CONF.set_override https://review.openstack.org/234398 | 18:09 |
| *** jaosorior has quit IRC | 18:09 | |
| rellerreller | dave-mccowan what was the question? | 18:10 |
| rellerreller | dave-mccowan which Nova/Cinder code? | 18:11 |
| *** jmckind is now known as jmckind_ | 18:11 | |
| rellerreller | dave-mccowan I think we implemented cinder volume encryption in Havana. | 18:12 |
| rellerreller | dave-mccown joel-coffman just confirmed it was in Havana | 18:15 |
| dave-mccowan | rellerreller thanks. that was the question. | 18:19 |
| *** su_zhang_ has joined #openstack-barbican | 18:25 | |
| *** _edmund has joined #openstack-barbican | 18:30 | |
| *** peter-hamilton has quit IRC | 18:54 | |
| *** ccneill_ has joined #openstack-barbican | 18:54 | |
| *** ccneill__ has joined #openstack-barbican | 18:55 | |
| *** ccneill has quit IRC | 18:56 | |
| *** ccneill_ has quit IRC | 18:59 | |
| *** su_zhang_ has quit IRC | 19:01 | |
| *** rellerreller has quit IRC | 19:03 | |
| openstackgerrit | Fernando Diaz proposed openstack/barbican: Add User Metadata Functions to Barbican API https://review.openstack.org/243263 | 19:04 |
| *** stevemar_ has joined #openstack-barbican | 19:05 | |
| *** rellerreller has joined #openstack-barbican | 19:08 | |
| *** su_zhang has joined #openstack-barbican | 19:15 | |
| dave-mccowan | A 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-barbican | 19:24 | |
| *** kebray has quit IRC | 19:46 | |
| *** everjeje has quit IRC | 19:47 | |
| *** _edmund1 has joined #openstack-barbican | 19:55 | |
| *** jmckind_ is now known as jmckind | 19:57 | |
| *** _edmund has quit IRC | 19:59 | |
| *** pdesai has joined #openstack-barbican | 20:00 | |
| *** rellerreller has quit IRC | 20:01 | |
| *** rellerreller has joined #openstack-barbican | 20:01 | |
| openstackgerrit | Jason Fritcher proposed openstack/barbican: Reimplement p11_crypto and pkcs11 modules https://review.openstack.org/243291 | 20:10 |
| *** ccneill has joined #openstack-barbican | 20:15 | |
| *** ccneill__ has quit IRC | 20:17 | |
| *** su_zhang has quit IRC | 20:22 | |
| *** su_zhang has joined #openstack-barbican | 20:23 | |
| *** pdesai has quit IRC | 20:24 | |
| *** pdesai has joined #openstack-barbican | 20:26 | |
| *** everjeje has joined #openstack-barbican | 20:28 | |
| *** su_zhang has quit IRC | 20:30 | |
| *** su_zhang has joined #openstack-barbican | 20:32 | |
| *** kebray has joined #openstack-barbican | 20: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 IRC | 20:54 | |
| *** _edmund1 has quit IRC | 20:55 | |
| *** jmckind is now known as jmckind_ | 20:55 | |
| *** _edmund has joined #openstack-barbican | 20:55 | |
| *** maxabidi has joined #openstack-barbican | 21:01 | |
| *** silos has left #openstack-barbican | 21:02 | |
| rellerreller | elmiko haha I caught your message on the meeting ;) | 21:02 |
| edtubill | ping rellerreller | 21:02 |
| rellerreller | edtubill pong | 21:02 |
| edtubill | rellerreller I wanted to see if you could look at https://github.com/edtubillara/federated-barbican/blob/master/spec/federated-castellan.rst | 21:02 |
| edtubill | And I wanted to see how crazy the #Type 2 idea was. | 21:03 |
| edtubill | rellerreller: For automaping tenants to barbican hosts... | 21:03 |
| rellerreller | edtubill I can look at it, not a problem. | 21:03 |
| edtubill | rellerreller: cool thx | 21:03 |
| rellerreller | edtubill I'll pull in kfarr as well. | 21:04 |
| elmiko | rellerreller: sigh... totally fumbled that one =( | 21:04 |
| elmiko | and dave-mccowan even called it in channel earlier | 21:04 |
| kfarr | edtubill, rellerreller, you're just talking about type 2 yeah? | 21:05 |
| edtubill | kfarr: yeah I just wanted some feedback on type 2 | 21:05 |
| *** jmckind_ is now known as jmckind | 21:06 | |
| kfarr | edtubill rellerreller, I like the part about keeping the Barbican API the same | 21:10 |
| kfarr | I can't really speak much about scoped tokens because I'm not that familiar with them | 21:11 |
| kfarr | it's an interesting idea to have the mappings in a config file, but concerned about calling it castellan-policy | 21:11 |
| *** spotz is now known as spotz_zzz | 21:12 | |
| kfarr | because then you're tightly coupling Barbican to Castellan, which isn't necessarily a requirement now | 21:13 |
| *** jmckind is now known as jmckind_ | 21:13 | |
| diazjf | the scoped-token will pretty much be the X-Auth-Token thats scoped towards the project on the Barbican we are Federating to | 21:13 |
| edtubill | kfarr: 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 coupled | 21:14 |
| kfarr | edtubill, I'm only concerned about it for the people who may have integrated Barbican without Castellan | 21:17 |
| rellerreller | edtubill I think I have similar concerns to kfarr | 21:18 |
| rellerreller | edtubill The first is that it seems like a new Castellan API will need to be created specifically for Barbican. | 21:18 |
| kfarr | One thing I'm not clear on is what is going to be reading and acting on that policy file? | 21:19 |
| rellerreller | edtubill 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 |
| edtubill | kfarr, rellerreller: Oh I see, so for people who don't use castellan but use a custom application that calls barbican | 21:19 |
| rellerreller | edtubill we have use cases that will not use Barbican at all. | 21:20 |
| redrobot | edtubill more like people who use Castellan who don't use Barbican at all | 21:20 |
| rellerreller | edtubill some people want a private cloud that has a KMIP device for all key management. | 21:20 |
| edtubill | The thing that would be reading and acting on the policy file would be a 'federated' keymanager that is a subclass from the keymanager | 21:21 |
| rellerreller | edtubill 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 jmckind | 21:21 | |
| rellerreller | edtubill in walking through the use case of cinder volume encryption I do not believe a lot of this is necessary. | 21:21 |
| rellerreller | edtubill 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 |
| edtubill | And 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 file | 21:22 |
| edtubill | rellerreller: I was just proposing a solution to change other services as least as possible | 21:23 |
| *** maxabidi has quit IRC | 21:23 | |
| rellerreller | edtubill what services have this problem now? | 21:23 |
| edtubill | I also had a question on if Castellan was going to be used in nova/cinder? | 21:23 |
| rellerreller | edtubill we are integrating Castellan into Nova and Cinder this release. | 21:24 |
| rellerreller | They currently have the old key manager code, so we are already kind of there. | 21:24 |
| *** spotz_zzz is now known as spotz | 21:24 | |
| edtubill | rellerreller: I guess you make a good point :) since they don't use Castellan yet. | 21:24 |
| diazjf | rellerreller, 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 |
| edtubill | rellerreller: 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 changes | 21:25 |
| rellerreller | edtubill 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_zzz | 21:26 | |
| rellerreller | So 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 |
| edtubill | rellerreller: oh I see and that became Casetellan? | 21:26 |
| *** spotz_zzz is now known as spotz | 21:26 | |
| edtubill | *Castellan | 21:26 |
| rellerreller | edtubill 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 |
| rellerreller | edtubill correct. | 21:27 |
| rellerreller | edtubill the first release of Castellan KeyManager contained the code from Cinder. | 21:27 |
| rellerreller | diazjf I'm behind on reviews. Ping me tomorrow to get on that. | 21:28 |
| diazjf | rellerreller, no worries, appreciate it | 21:29 |
| rellerreller | diazjf You have a bunch of reviews. Could you provide a prioritized list? | 21:29 |
| rellerreller | diazjf 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 |
| diazjf | rellerreller, yeah I'll make an etherpad with some descriptions and their urgency | 21:30 |
| rellerreller | diazjf thanks! | 21:30 |
| diazjf | read my mind! | 21:30 |
| rellerreller | diazjf and edtubill I need to run now. Have a good evening :) | 21:30 |
| diazjf | same to you :) | 21:31 |
| *** su_zhang has joined #openstack-barbican | 21:31 | |
| edtubill | rellerreller and kfarr: thx for the feedback and info! | 21:31 |
| kfarr | whoa diazjf, so it's not just Castellan that needs to accept keystone middleware tokens, but Barbican as well? | 21:34 |
| diazjf | kfarr, not Barbican, but Barbican Client I believe. | 21:35 |
| diazjf | kfarr, Barbican can use other auth systems, but they must have variables like project_id etc. | 21:36 |
| diazjf | redrobot: any input that you can give on the above | 21:37 |
| redrobot | diazjf kfarr you are correct in that Barbican does not require Keystone tokens. | 21:40 |
| *** kebray has quit IRC | 21:40 | |
| redrobot | The Authentication/Authorization requirement for Barbican is that a request to Barbican has to include the "X-Project-Id" and "X-Roles" headers | 21:40 |
| *** rellerreller has quit IRC | 21:40 | |
| redrobot | the easiest way to provide those headers is to put Keystone Middleware in the request pipeline right before barbican. | 21:41 |
| redrobot | Keystone 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 |
| redrobot | Barbican does not care what AuthZ/AuthN service you use, as long as that service injects the required headers before passing the request to Barbican | 21:43 |
| diazjf | redrobot, 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 Keymaster | 21:43 |
| diazjf | since many swift users dont necessarily rely on keystone. | 21:44 |
| kfarr | diazjf, 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 well | 21:45 |
| redrobot | for ACLs to work anyway | 21:45 |
| *** kebray has joined #openstack-barbican | 21:45 | |
| diazjf | kfarr, still need to figure that one out. But we would need to support something like: http://docs.openstack.org/developer/swift/development_auth.html | 21:46 |
| diazjf | redrobot, would it be correct to say that certain features wont work with certain auth systems, or full Barbican API is always required. | 21:47 |
| kfarr | diazjf https://review.openstack.org/#/c/235671/ is only a temporary fix then? | 21:47 |
| diazjf | kfarr, yup. In the future all of that will be changed. But its good to have for the meantime | 21:48 |
| kfarr | diazjf okk just checking | 21:48 |
| diazjf | kfarr thanks :) | 21:49 |
| kfarr | diazjf also sorry I've been sorta slow to review your patches lately! I'll get on that this week | 21:50 |
| diazjf | kfarr, no worries, I know I've put up alot :/ thanks for taking the time :) | 21:51 |
| arunkant | kfarr: ping. | 21:52 |
| kfarr | arunkant pong | 21:52 |
| arunkant | kfarr: question about https://bugs.launchpad.net/nova/+bug/1505930 | 21:52 |
| openstack | Launchpad 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 |
| arunkant | kfarr: You mentioned that there is plan to rework key manager..what kind of changes are planned ? | 21:53 |
| kfarr | arunkant, 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 Castellan | 21:54 |
| arunkant | kfarr: Okay. What is the approx. timeline for those changes? We need nova ephermal encryption working and were planning to internally backport the fix for liberty | 21:56 |
| kfarr | arunkant, well, the plan was to get it up by m-2 | 21:56 |
| kfarr | I already see a few quirks that are going to happen with the replacement, but hopefully I will get it done much sooner than that | 21:57 |
| notmyname | diazjf: acoles is likely out this week. he got called to jury duty. something I can help with? | 21:58 |
| arunkant | kfarr, 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 IRC | 22:00 | |
| kfarr | complete replacement | 22:00 |
| diazjf | notmyname, just wondering if someone from the swift-side could go over https://review.openstack.org/#/c/241068/ | 22:00 |
| diazjf | notmyname, in order to see what exactly are the requirements to get Castellan into the Swift Keymaster | 22:01 |
| diazjf | notmyname, thanks for the reply :) | 22:01 |
| notmyname | diazjf: what are the requirements barbican has now? or castellan specifically? is it currently depending on code or functionality provided by keystone? | 22:01 |
| arunkant | kfarr, okay. So does castellan now provide another plugin option other than barbicanclient ? | 22:01 |
| *** jmckind has quit IRC | 22:02 | |
| kfarr | arunkant, no, but the key manager in Nova doesn't either. Unless you wrote one? | 22:02 |
| diazjf | notmyname, 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 |
| diazjf | notmyname, for Barbican Key Manager, Castellan requires those things as well | 22:04 |
| notmyname | ah, right. castellan is a client-side thing, right? so yeah it has to send keystone headers if the barbican key manager is being used | 22:04 |
| arunkant | kfarr: 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 |
| diazjf | notmyname, correct! | 22:05 |
| arunkant | kfarr: thanks. | 22:06 |
| diazjf | notmyname, 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 |
| diazjf | notmyname, by KeyManager I mean swift KeyMaster | 22:07 |
| redrobot | diazjf 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.context | 22:09 |
| redrobot | diazjf my assumption is that most projects would have an oslo.context readily available | 22:09 |
| redrobot | diazjf is that not the case for Swift? | 22:09 |
| notmyname | diazjf: so castellan today requires keystone headers no matter the key manager backed? | 22:10 |
| notmyname | redrobot: swift does not use oslo.context | 22:10 |
| notmyname | (nor am I even sure what that does) | 22:10 |
| diazjf | notmyname, just for the Barbican backend, it believe it is currently the only implemented one. kfarr, you may be able to better answer this | 22:11 |
| redrobot | diazjf Castellan should not be backend-specific | 22:12 |
| *** mixos has quit IRC | 22:12 | |
| redrobot | diazjf the current interface requires an instance of oslo.context regardless of backend being used | 22:12 |
| kfarr | Yeah, 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 it | 22:13 |
| redrobot | notmyname they KeyMaster in Swift requires some sort of auth parameters to be passed? or does it just return keys willy-nilly ? | 22:14 |
| diazjf | redrobot, I mean like in https://github.com/openstack/castellan/blob/master/castellan/key_manager/barbican_key_manager.py#L132 | 22:14 |
| diazjf | the barbican backend looks specifically for keystone | 22:14 |
| redrobot | diazjf note that the oslo.context instance is being passed into that method | 22:14 |
| diazjf | redrobot, ohh gotcha | 22:15 |
| redrobot | diazjf the Barbican implementation does assume Keystone, but it requires that oslo.context to be able to build a client with the right keystone credentials | 22:15 |
| redrobot | diazjf it should be possible to build an alternative Barbican implementation that uses a different auth system if needed | 22:16 |
| diazjf | redrobot, gotcha, but we will still require project_id, etc. | 22:16 |
| redrobot | diazjf well, those are guaranteed to be present in an oslo.context instance | 22:16 |
| redrobot | diazjf ... 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 request | 22:17 |
| redrobot | diazjf I would like to pick kfarr 's brain about what a possible KMIP impl would look like | 22:18 |
| diazjf | redrobot, I see, but since swift doesn't use oslo.context we run into a dilema | 22:18 |
| redrobot | diazjf indeed | 22:18 |
| redrobot | diazjf 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 device | 22:19 |
| redrobot | diazjf an alternative that I've considered before is that Castellan may need to define Auth objects | 22:20 |
| kfarr | redrobot, 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 tokens | 22:20 |
| notmyname | from 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-barbican | 22:22 | |
| redrobot | kfarr hmmm... I had envisioned a smart KMIP impl that is able to map oslo.context to a KMIP auth object | 22:22 |
| redrobot | kfarr s/auth object/credential object | 22:24 |
| kfarr | redrobot, 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 work | 22:24 |
| diazjf | notmyname: 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 |
| redrobot | diazjf Barbican already has pluggable auth... I think the question should be whether Castellan needs to implement generic auth objects | 22:26 |
| redrobot | diazjf ... but then we still have the problem of mapping a generic auth object to a kmip credential | 22:27 |
| redrobot | kfarr I guess it's because oslo.context wouldn't have enough info to create a kmip credential? | 22:27 |
| diazjf | redrobot, I'll update the spec to include the change | 22:28 |
| redrobot | diazjf I guess it comes down to ownership of the key material... | 22:30 |
| redrobot | diazjf as in, who owns the key that Swift is storing in the KeyMaster? | 22:30 |
| notmyname | it depends ;-) | 22:30 |
| redrobot | diazjf 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 |
| notmyname | in our first version the key will be owned by swift | 22:31 |
| redrobot | notmyname that's my favorite security question :D | 22:31 |
| redrobot | notmyname i mean, "it depends" is my favorite security answer | 22:31 |
| * redrobot feels like a real security professional when answering "it depends" ;) | 22:31 | |
| notmyname | or more specifically, it depends on the keymaster and the first keymaster that we will have upstream will have the cluster own the key | 22:31 |
| notmyname | actually, as of the summit, the first version will very likely not use castellan. later versions likely will, though | 22:32 |
| redrobot | diazjf 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 |
| diazjf | redrobot. notmyname, that was the idea in the Keymaster I was working on that relied on Keystone | 22:34 |
| redrobot | diazjf which idea? that Swifts owns the keys? | 22:36 |
| diazjf | redrobot, correct, it was an IBM prototype. | 22:37 |
| diazjf | not swift | 22:37 |
| diazjf | I mean the user who owns the container in swift | 22:38 |
| *** jamielennox|away is now known as jamielennox | 22:38 | |
| diazjf | or actually user who owns the account | 22:38 |
| redrobot | diazjf 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 |
| kfarr | redrobot, swift stores all the user info in a keystone middleware object | 22:39 |
| diazjf | redrobot, 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 place | 22:40 |
| diazjf | kfarr, notmyname, even with temp_auth, etc. | 22:40 |
| diazjf | If thats the case then https://review.openstack.org/#/c/235671/ may be sufficient | 22:41 |
| notmyname | just 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 |
| kfarr | if it's public data, then what's the benefit of encrypting it? | 22:46 |
| notmyname | in all cases, this is for server-side encryption of data on a drive | 22:48 |
| notmyname | no, it might not make sense to encrypt public data | 22:48 |
| notmyname | but that's one example | 22:49 |
| *** stevemar_ has quit IRC | 22:49 | |
| notmyname | another 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 key | 22:49 |
| *** _edmund has joined #openstack-barbican | 22:50 | |
| notmyname | another 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 |
| notmyname | point 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 functionality | 22:52 |
| redrobot | notmyname makes sense | 22:53 |
| kfarr | Yeah, that's a tricky point | 22:56 |
| diazjf | So Castellan should be able to use Unathenticated Context | 22:58 |
| redrobot | diazjf what backend do you want to use that doesn't require authentication? | 22:58 |
| diazjf | redrobot, I would like to see it with Barbican | 22:59 |
| redrobot | diazjf I want to make sure I understand your use case | 23:01 |
| redrobot | diazjf so, you're working with a cloud where Keystone is not used for authentication... | 23:01 |
| redrobot | diazjf in that cloud, you want to deploy Barbican | 23:01 |
| redrobot | diazjf for argument's sake you're using an auth service called XXX | 23:02 |
| diazjf | redrobot, 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 IRC | 23:03 | |
| diazjf | notmyname, is what was mentioned in my above comment, what is necessary for Castellan use in the swift keymaster? | 23:03 |
| redrobot | diazjf that's a really broad use case | 23:04 |
| *** jhfeng has quit IRC | 23:04 | |
| redrobot | so, as I understand it, Swift is most commonly deployed with a non-keystone auth front end, yes? | 23:04 |
| notmyname | that is a common deployment model | 23:05 |
| redrobot | but it CAN be deployed behind Keystone? | 23:06 |
| *** mixos has quit IRC | 23:06 | |
| diazjf | redrobot, it could | 23:07 |
| redrobot | what's the abstraction in Swift that can deal with both Keystone and the commonly-used-not-keystone-auth ? | 23:07 |
| notmyname | the 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 authorized | 23:08 |
| redrobot | notmyname hmm... interesting... | 23:10 |
| openstackgerrit | Jason Fritcher proposed openstack/barbican: Reimplement p11_crypto and pkcs11 modules https://review.openstack.org/243291 | 23:12 |
| redrobot | diazjf 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 |
| diazjf | redrobot, exactly! | 23:13 |
| *** jmckind has joined #openstack-barbican | 23:13 | |
| diazjf | that way if a company already had another auth system in place they can just add Barbican without keystone support | 23:14 |
| diazjf | redrobot, notmyname, and thats since its a requirement from swift to get Castellan into the Keymaster | 23:15 |
| diazjf | ^ from the swift community | 23:15 |
| redrobot | diazjf 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 |
| diazjf | redrobot, exactly | 23:18 |
| redrobot | diazjf ok, so to do this in a way that Swift ends up owning all the keys is easy | 23:20 |
| redrobot | diazjf 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 about | 23:20 |
| redrobot | for the first case (swfit + barbican + some-other-auth) you woud need: | 23:21 |
| redrobot | 1. 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 |
| redrobot | 2. An account in that some-other-auth that is owned by Swift | 23:22 |
| redrobot | 3. Swift would need to build an oslo.context using the credentiasl for that some-other-auth account. | 23:22 |
| redrobot | 4. 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 IRC | 23:24 | |
| redrobot | for the second case (swift + kmip device + some-other-auth) you would need: | 23:24 |
| redrobot | 1. Credentials in the KMIP device that are owned by Swift | 23:24 |
| redrobot | 2. Swift would need to build an oslo.context using the credentials for that kmip device account | 23:25 |
| redrobot | 3. 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 credentials | 23:26 |
| redrobot | I 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 |
| redrobot | then the credential objects woudl be built and passed to castellan, and the impls would have to use those to talk to the respective backends | 23:28 |
| diazjf | redrobot, 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 IRC | 23:29 | |
| *** spotz is now known as spotz_zzz | 23:29 | |
| *** su_zhang has joined #openstack-barbican | 23:30 | |
| diazjf | ^ wsgi middlewares = some-other-auth | 23:30 |
| redrobot | diazjf 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 |
| diazjf | redrobot, notmyname, so auth-systems like temp-auth would need to be re written then :( | 23:33 |
| notmyname | I'm not sure. mostly because of my own ignorance on the barbican/castellan side | 23:33 |
| notmyname | however, since castellan integration is further down the road for swift, it's not a time-sensitive question from our side | 23:34 |
| redrobot | notmyname 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 |
| notmyname | I'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 request | 23:36 |
| diazjf | notmyname, like redrobot discussed in case1, but my worry is how are we going to make currently used auth systems compatible. | 23:43 |
| yfujioka | redrobot: thank you for your response. and sorry, I have not understood about new key. | 23:45 |
| yfujioka | is that /v1/orders? | 23:45 |
| redrobot | yfujioka hi! ... yes, all requests to /v1/orders are processed by the barbican-worker | 23:46 |
| redrobot | yfujioka this includes both orders for Certs, which are sent to a CA and orders for keys which are sent to the secret-store | 23:46 |
| redrobot | yfujioka you can deploy Barbican without barbican-worker (we're actually doing just that at Rackspace) | 23:46 |
| redrobot | yfujioka but we did have to block the /v1/orders endpoint altogether | 23:47 |
| diazjf | redrobot, 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 |
| redrobot | yfujioka which means you lose the capability of ordering symmetric and asymmetric keys. | 23:47 |
| notmyname | yeah, I've got to run too | 23:47 |
| diazjf | notmyname, redrobot, I'll ping you guys tomorrow, Thanks! | 23:48 |
| yfujioka | redrobot: thank you. honestly, I don't understand about /v1/orders. is this need for Neutron LBaaS V2 with TLS? | 23:51 |
| yfujioka | redrobot: my understanding is /v1/secrets and /v1/orders are need for LBaaS. | 23:52 |
| redrobot | yfujioka no, I believe LBaaS only uses the /v1/secrets and /v1/containers endpoints | 23:52 |
| redrobot | yfujioka if you only want to suport the LBaaS use cases then you should be ok without barbican-worker | 23:53 |
| yfujioka | redrobot: really thank you! | 23:54 |
| redrobot | yfujioka you're welcome! | 23:55 |
| *** diazjf has quit IRC | 23:57 | |
| yfujioka | redrobot: 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!