Friday, 2016-01-08

*** dimtruck is now known as zz_dimtruck00:04
*** stanzi has joined #openstack-barbican00:07
*** stanzi has quit IRC00:11
*** mixos has joined #openstack-barbican00:12
*** stanzi has joined #openstack-barbican00:21
*** openstackgerrit has quit IRC00:32
*** openstackgerrit has joined #openstack-barbican00:33
*** stanzi has quit IRC00:42
*** zz_dimtruck is now known as dimtruck00:49
*** stanzi has joined #openstack-barbican00:54
*** woodster_ has quit IRC00:56
*** cheneydc has joined #openstack-barbican01:02
*** stanzi has quit IRC01:03
*** stanzi has joined #openstack-barbican01:03
*** mixos has quit IRC01:06
*** mixos has joined #openstack-barbican01:07
*** stanzi_ has joined #openstack-barbican01:11
*** stanzi has quit IRC01:11
*** stanzi_ has quit IRC01:14
*** stanzi has joined #openstack-barbican01:14
*** mixos has quit IRC01:16
*** ccneill has quit IRC01:22
*** NazcaLines has quit IRC01:28
*** mixos has joined #openstack-barbican01:49
*** jaosorior has quit IRC02:35
*** jaosorior has joined #openstack-barbican02:35
*** fredyx10 has joined #openstack-barbican02:56
*** gyee has quit IRC03:04
*** stanzi has quit IRC03:12
*** stanzi has joined #openstack-barbican03:15
*** yuanying has quit IRC03:26
*** yuanying has joined #openstack-barbican03:37
*** yuanying has quit IRC04:05
*** yuanying has joined #openstack-barbican04:07
*** stanzi has quit IRC04:24
*** fredyx10 has quit IRC05:09
*** mixos has quit IRC05:20
*** jamielennox is now known as jamielennox|away05:27
*** yfujioka has joined #openstack-barbican05:35
*** mragupat has joined #openstack-barbican05:40
*** mragupat has quit IRC05:42
*** mragupat has joined #openstack-barbican05:42
*** jaosorior has quit IRC05:47
*** dave-mccowan has quit IRC05:49
*** yuanying_ has joined #openstack-barbican06:00
*** yuanying has quit IRC06:01
*** yuanying_ has quit IRC06:01
*** yuanying has joined #openstack-barbican06:01
*** jorgem has quit IRC06:08
*** jillysciarilly has quit IRC06:08
*** notmyname has quit IRC06:09
*** notmyname has joined #openstack-barbican06:10
*** jorgem has joined #openstack-barbican06:10
*** jillysciarilly has joined #openstack-barbican06:17
openstackgerritVishal kumar mahajan proposed openstack/kite: Fix the parameter order of assertEqual in api test.  https://review.openstack.org/26509706:19
*** jaosorior has joined #openstack-barbican06:21
openstackgerritMerged openstack/barbican: Use assertTrue/False instead of assertEqual(T/F)  https://review.openstack.org/26421506:27
*** dimtruck is now known as zz_dimtruck06:28
*** mragupat has quit IRC06:45
openstackgerritOpenStack Proposal Bot proposed openstack/barbican: Updated from global requirements  https://review.openstack.org/26441106:49
*** jaosorior has quit IRC08:16
*** jaosorior has joined #openstack-barbican08:16
*** f13o has joined #openstack-barbican08:30
*** cheneydc has quit IRC10:02
*** jaosorior has quit IRC10:37
*** jaosorior has joined #openstack-barbican10:38
*** mixos has joined #openstack-barbican12:37
*** mixos has quit IRC12:43
*** stanzi has joined #openstack-barbican13:12
*** stanzi has quit IRC13:37
*** cheneydc has joined #openstack-barbican13:47
*** fredyx10 has joined #openstack-barbican13:53
*** stanzi has joined #openstack-barbican13:57
*** fredyx10 has quit IRC13:58
*** jaosorior has quit IRC14:02
*** stanzi has quit IRC14:02
*** cheneydc has quit IRC14:09
*** dave-mccowan has joined #openstack-barbican14:13
*** rellerreller has joined #openstack-barbican14:26
*** lisaclark has joined #openstack-barbican14:26
*** fredyx10 has joined #openstack-barbican14:35
*** ajc_ has joined #openstack-barbican14:38
*** ajc_ has quit IRC14:38
*** stanzi has joined #openstack-barbican14:39
*** mixos has joined #openstack-barbican14:42
*** stanzi has quit IRC14:43
*** fredyx10 has quit IRC14:44
*** fredyx10 has joined #openstack-barbican14:44
*** nelsnelson has quit IRC14:47
*** jmckind has joined #openstack-barbican15:00
*** spotz_zzz is now known as spotz15:03
*** stanzi has joined #openstack-barbican15:04
*** rellerreller has quit IRC15:08
*** stanzi has quit IRC15:08
*** stanzi has joined #openstack-barbican15:09
*** zz_dimtruck is now known as dimtruck15:09
*** stanzi has quit IRC15:12
*** stanzi has joined #openstack-barbican15:12
*** peter-hamilton has joined #openstack-barbican15:14
*** mp1 has joined #openstack-barbican15:17
*** peter-hamilton has quit IRC15:18
*** rellerreller has joined #openstack-barbican15:21
*** lisaclark has quit IRC15:22
*** lisaclark has joined #openstack-barbican15:25
*** stanzi has quit IRC15:30
*** fredyx10 has quit IRC15:35
*** silos has joined #openstack-barbican15:36
*** fredyx10 has joined #openstack-barbican15:37
*** mragupat has joined #openstack-barbican15:38
*** stanzi has joined #openstack-barbican15:41
*** jmckind_ has joined #openstack-barbican15:41
*** fredyx10 has quit IRC15:41
*** fredyx10 has joined #openstack-barbican15:41
*** jmckind has quit IRC15:44
openstackgerritChristopher Solis proposed openstack/barbican: Create Orders Documentation  https://review.openstack.org/23612315:47
*** kebray has joined #openstack-barbican15:49
*** lisaclark has quit IRC15:58
*** stanzi has quit IRC15:59
*** lisaclark has joined #openstack-barbican16:09
*** zigo has quit IRC16:09
*** zigo has joined #openstack-barbican16:10
*** kfarr has joined #openstack-barbican16:11
arunkantrellerreller: ping16:25
*** mp1 has quit IRC16:31
*** mixos has quit IRC16:31
*** ccneill has joined #openstack-barbican16:33
*** nelsnelson has joined #openstack-barbican16:38
rellerrellerarunkant pong16:39
arunkantrellerreller: I have question on the concern you mentioned in https://review.openstack.org/#/c/263972/16:39
rellerrellerarunkant sure16:39
rellerrellerarunkant I don't want my review to think it is impossible or bad idea, but there are lots of details to work through.16:40
*** gyee has joined #openstack-barbican16:40
arunkantI have yet to go through trasnport key logic in detail..but looks like the concern you have to know which backend transport key is stored in ?16:40
rellerrellerarunkant we will need definitely need to address some of the issues you mentioned.16:41
rellerrellerarunkant correct16:41
rellerrellerarunkant when the keys depend upon each other then you will likely need to know where it is stored.16:42
arunkantrellerreller: In the spec, I have added something global preferred secret store backend..this is the backend which is used when project level backend is not specified/used16:42
rellerrellerOtherwise you could have an unencrypted key in Barbican when the user's policy does not allow that.16:42
arunkantrellerreller: We can always store transport key in that backend. Will that work ?16:43
rellerrellerarunkant I don't think so. The transport keys are provided by a key management device.16:44
rellerrellerarunkant they provide a path for the secret to be encrypted from the user all the way to the device.16:44
rellerrellerarunkant the goal is to not let Barbican read the secret.16:45
rellerrellerarunkant I have been thinking about the restriction that a project must have one and only one secret store.16:46
*** f13o has quit IRC16:46
*** mp1 has joined #openstack-barbican16:46
arunkantOkay..understood..so if we know its going to be always stored in HSM device..then use that backend...we can ask customer or deployment to have a preferred backend for transport key16:46
rellerrellerarunkant that may provide enough of a restriction to eliminate most if not all of my concerns. I'm still trying to work through it.16:47
*** kebray has quit IRC16:47
*** edtubill has joined #openstack-barbican16:48
arunkantrellereller: Storing transort key in customer specified backend (in case multiple secret store is enabled)..will that work?16:49
rellerrellerarunkant my last comment was with regards to the restriction that a project must have secret store.16:49
rellerrellerarunkant the transport keys are provided by the backend and do not leave the backend, at least the private part of it.16:50
arunkantrellerreller: Ideally, we don't need to have that (as each secret has metadata about backend)..but that's just to limit the amount of work to be done in first iteration of this feature16:51
*** lisaclark has quit IRC16:51
rellerrellerarunkant there is the problem about policy dictating that certain keys should not leave a backend device unencrypted.16:52
rellerrellerIf I have a symmetric that meets this requirement and I want to send it back to a user wrapped with their public key then how do we guarantee that the key does not enter Barbican unencrypted.16:53
rellerrellerIf the public key is stored in a different backend.16:53
*** stanzi has joined #openstack-barbican16:55
arunkantrellerreller: containers or groups of secrets/keys  are generally tied to same project..so indirectly which means they will be stored in same backend. Will there be situation for above case16:55
*** f13o has joined #openstack-barbican16:56
*** jmckind has joined #openstack-barbican16:56
rellerrellerarunkant it depends upon the restriction of how many secret stores can be created and what is their mapping to projects and users. I'm not sure yet.16:56
rellerrellerarunkant I'm still not convinced that >1 secret store will be possible without exposing keystore backend storage location to user.16:57
arunkantrellereller: I don't forsee there are going to be many backends..as barbican has only 2-3 secret store options ..16:58
rellerrellerarunkant even if restricted 1:1 project:secret_store then what if I want to send a symmetric key from one project to a user in another project? We would have to work through that.16:58
*** stanzi has quit IRC16:58
*** stanzi has joined #openstack-barbican16:59
*** lisaclark has joined #openstack-barbican16:59
*** mragupat has quit IRC16:59
rellerrellerarunkant there could be lots of backend instances. Consider a public cloud with lots of customers bringing their own KMIP devices. We will have to keep track of where each instance resides and how to contact it.17:00
*** jmckind_ has quit IRC17:00
arunkantrellerreller: Yes..I am sure there are certain aspects of this needs to be ironed out .17:00
*** mragupat has joined #openstack-barbican17:00
*** lisaclark has quit IRC17:02
arunkantrellerreller: I am not sure Barbican has that kind of support but even if it does in future, there should not issue with having multiple secret_store and project mapping. Actually in those secnraios, we want to have support for multiple backends on project level.17:03
*** lisaclark has joined #openstack-barbican17:04
*** lisaclark has quit IRC17:06
arunkantrellerreller: Having global preferred transport key backend should address the concern you mentioned in review..what do you think ?17:07
*** f13o has quit IRC17:08
rellerrellerarunkant that would not work. The idea is to have the private transport key generated on the backend device and never leave it. How do you envision the global transport key working?17:08
*** silos has quit IRC17:09
rellerrellerarunkant let's consider the case of two backends for a project. The backends are A and B. The user wants to retrieve symmetric key foo, which is stored in B. How would that work without exposing the storage backend to the user?17:09
*** stanzi has quit IRC17:10
arunkantrellerreller: As you mentioned, a deployment will want to store transport key in a device..so barbican configuration will define what backend to use for transport key..it can be HSM backend (where it does not leave device)17:10
*** stanzi has joined #openstack-barbican17:11
arunkantrellerreller: So as part of barbican configuration, deployer will specify that, let's say, B is global preferred backend for secret store. And now lets say secret (symmetric key) is stored under project p1.17:12
rellerrelleractually for retrieval case it would not be wrapped with transport key17:12
arunkantIf project specific backend is not specified, then barbican will look for secret data in backend B as that's the global preferred backend .17:13
rellerrellerarunkant but what if A is preferred backend?17:14
arunkantif for project p1, backend A is specified as preferred project level backend..then secret will be looked into backend A first17:14
rellerrellerarunkant the user first make a call to Barbican to get transport key17:15
rellerrellerthen the user uses the transport key to encrypt a wrapping key that the backend device will use to encrypt the symmetric for the user.17:15
arunkantOkay..for transport key..we can specify a global preferred transport key store backend..which can be B (if it happens to map to HSM device)..and use that to retrieve transport key.17:16
rellerrellerThe user then makes a call to Barbican to retrieve the symmetric key and passes it the transport wrapped session key (twsk).17:16
rellerrellerThe backend then receives the twsk, decrypts it, wraps the symmetric key, and returns the key back to barbican and then the user.17:17
rellerrellerarunkant how does Barbican know which transport key to return to the user when it makes a request to get it?17:17
*** f13o has joined #openstack-barbican17:18
rellerrellerNo matter which one you choose I can always say the desired key is in the other backend.17:18
arunkantrellerreller: Based on global preferred backend for transport key..it will look for project related transport key..17:18
rellerrellerarunkant there is no project related transport key. The transport key is per backend instance.17:19
*** fredyx10 has quit IRC17:20
arunkantOkay...in that case..can we transport key maintain per backend..so based on the backend where we are goin to store the secret, we use that transport key.17:21
arunkantI meant...can we maintain transport key per backend17:22
rellerrellerarunkant yes, there can be a transport key per backend, but how does a user know which backend for key retrieval? The first step in returning a wrapped key is to retrieve the transport key.17:23
*** nelsnels_ has joined #openstack-barbican17:24
rellerrellerarunkant the current API always returns the same transport key because their can only be one.17:24
rellerrellerarunkant so now you must change this api to allow the user to specify a specific transport key, say for backend A or B.17:25
arunkantrellereller: The user will know which backend they want to use for secret storage..is not it ? ..We can always derive project specific backend information from keystone token..17:25
rellerrellerarunkant but then the user must somehow know where their key is stored, in A or B, so they know which transport key to request. That would be another API change to allow the user to query that information.17:25
rellerrellerarunkant the user does not know which backend is being used. They only know which Barbican instance to call.17:26
arunkantSo based on keystone token..if project does not have project level backend specified, then we can use trannsport key which is for global preferred backend (backend B from above example)17:26
*** silos has joined #openstack-barbican17:26
rellerrellerarunkant there is nothing in the API to say store this key in this backend.17:26
*** nelsnelson has quit IRC17:27
rellerrellerarunkant forget about global preferred backend. You said earlier that you wanted >1 backends per project.17:27
arunkantrellerreller: No...I don't want more than one backend per project..we want to have option of specifiying preferred backend for a project17:28
arunkantrellereller: Actually..that's something I have mentioned in spec as out-of-scope topic for this spec17:29
rellerrellerarunkant at 12:03 you said, "we want to have support for multiple backends on project level." I took that to mean >1 backend per project. So that is not what you are saying?17:30
arunkantrellerreller: I meant..having support for multiple backends..where backend is specified at project level.  So yes, currently we don't want to have multiple backend specified within a project.17:32
rellerrellerarunkant so that will certainly help, and as I said before it might work. I'm just not sure yet.17:33
rellerrellerarunkant I'm trying to think about retrieving a secret from a different project and using transport key. I think that still has issues.17:34
*** kebray has joined #openstack-barbican17:34
arunkantrellereller: As you correctly identifiied.. I can clearly see there are certain aspects where details need to be sorted out.17:34
rellerrellerBasically the same ones that I outlined above.17:34
rellerrellerWe spent a lot of hours debating this at one of the summits until we finally said, "This is really hard. Let's just support one secret store and have multiple Barbican instances."17:35
*** edtubill has quit IRC17:35
*** mp1 has quit IRC17:36
rellerrellerI think it's worthy of a revisit. There are definitely pros and cons to both solutions. I'm not certain which is better.17:36
arunkantrellerreller: As transport keys are backend level..so it should be quite straightforward..if there is project level backend specified, then provide transport key for that backend to user otherwise use from default backend (global preferred one)17:36
rellerrellerAnd we need to solve the problems you outlined sooner rather than later.17:36
rellerrellerarunkant but what if the key I want to retrieve is in another project stored in a different backend that has a different transport key?17:37
*** diazjf has joined #openstack-barbican17:37
arunkantrellereller: Yes..we certainly need to have discussion on this.. Will it be possible for you to remove -2 as that just literally stops the review process..other people in community would not even look into it.17:38
arunkantrellerreller: As you mentioned earlier, transport key and secret store backend has to be same. We will definitely avoid cases to allow that if it can happen..may be allow only for new projects.17:41
*** mp1 has joined #openstack-barbican17:41
arunkantrellerreller: What do you say?17:42
rellerrellerarunkant I don't know how that works. I don't want it to accidentally get accepted somehow. See what redrobot says I'll do whatever he says.17:43
arunkantrellerreller: It would not be accepted without discussion. I am not core and have that kind of influence :-) ... But just requesting to have discussion going which will likley not happen with -2.17:45
arunkantrellerreller: Also as this is a new feature..like earlier Barbican guidelines..this will be kept disabled by default and deployment wish to you will have to enable it.17:47
rellerrellerarunkant let's see what redrobot says.17:48
arunkantrellerreller: Okay...as per this discussion..looks like there is possible path for transport key wrapping issue. Its just need to be documented (which I will do in next patch).17:50
rellerrellerarunkant sounds good.17:51
arunkantrellerreller: thanks for your inputs on this.17:51
rellerrellerarunkant np. Sorry if it seems frustrating.17:52
rellerrellerThis one in particular has a lot of minute details with it.17:52
*** ccneill has quit IRC17:53
arunkantIts alright..totally agree. So I am expecting these kind of finer details to come out of this spec..with community discussion. I have tried to be detailed in spec..but will update once we have some resolution on -2 issue.17:54
*** ccneill has joined #openstack-barbican17:54
rellerrellerarunkant so you cannot update spec with a -2 on it?17:59
rellerrellerarunkant I thought -2 would just carryover to next revision.17:59
*** jmckind has quit IRC17:59
*** mragupat_ has joined #openstack-barbican18:02
*** mp1 has quit IRC18:04
*** kfarr has quit IRC18:04
*** mragupat has quit IRC18:06
*** jmckind has joined #openstack-barbican18:07
*** silos has quit IRC18:08
*** stanzi has quit IRC18:16
*** dimtruck is now known as zz_dimtruck18:18
*** zz_dimtruck is now known as dimtruck18:42
*** ccneill has quit IRC18:45
*** ccneill has joined #openstack-barbican18:49
arunkantrellerreller: Are you coming for mid-cycle ?18:52
rellerrellerarunkant I will not be there, but kfarr will be.18:52
*** stanzi has joined #openstack-barbican18:54
arunkantrellerreller: Okay..I was hoping to discuss this in mid-cycle. Hopefully it can still be discussed with -2 on it.18:54
rellerrellerarunkant there is no reason it cannot be discussed. It should be discussed.18:56
arunkantHopefully yes..it should not be the case that as it has -2 from you so it needs to be cleared from you first.18:58
openstackgerritFernando Diaz proposed openstack/barbican: Warning about tox not working in Vagrant setup  https://review.openstack.org/26432519:17
*** mp1 has joined #openstack-barbican19:20
*** jmckind_ has joined #openstack-barbican19:23
*** lisaclark has joined #openstack-barbican19:25
*** silos has joined #openstack-barbican19:25
*** jmckind has quit IRC19:26
*** mp1 has quit IRC19:30
*** mp1 has joined #openstack-barbican19:32
*** lisaclark has quit IRC19:36
*** darrenmoffat has quit IRC19:42
*** darrenmoffat has joined #openstack-barbican19:43
*** lisaclark has joined #openstack-barbican19:46
*** kebray has quit IRC19:46
*** diazjf has quit IRC19:51
*** kebray has joined #openstack-barbican20:06
*** silos has quit IRC20:08
*** mp1 has quit IRC20:10
*** mp1 has joined #openstack-barbican20:11
*** lisaclark1 has joined #openstack-barbican20:15
*** lisaclark has quit IRC20:16
*** nelsnels_ has quit IRC20:25
*** phschwartz has joined #openstack-barbican20:35
*** diazjf has joined #openstack-barbican20:36
phschwartzWhen creating a client object what sets the endpoint? I am using os-client-config to load a cloud.yaml and the url for barbican is a valid https url in the service catalog, but when I print out client.secret._api.get_endpoint() it returns an http url20:36
*** Daviey has joined #openstack-barbican20:38
*** nelsnelson has joined #openstack-barbican20:42
arunkantrellerreller: I have tried to capture the main aspect of our todays discussion..can you please comment to see if my understanding is correct and then I can address them in next patch. ..https://review.openstack.org/#/c/26397220:43
*** stanzi has quit IRC20:46
*** silos has joined #openstack-barbican20:50
*** fredyx10 has joined #openstack-barbican21:09
*** jmckind_ has quit IRC21:16
*** jmckind has joined #openstack-barbican21:17
*** lisaclark1 has quit IRC21:19
arunkantredrobot: ping21:26
*** rhagarty has joined #openstack-barbican21:29
*** rellerreller has quit IRC21:30
*** rhagarty_ has quit IRC21:31
*** lisaclark has joined #openstack-barbican21:35
*** rhagarty_ has joined #openstack-barbican21:37
openstackgerritJason Fritcher proposed openstack/barbican: Reimplement p11_crypto and pkcs11 modules  https://review.openstack.org/24329121:38
*** jmckind_ has joined #openstack-barbican21:38
*** fredyx10 has quit IRC21:38
*** fredyx10 has joined #openstack-barbican21:38
*** rhagarty has quit IRC21:39
*** diazjf has quit IRC21:39
*** lisaclark has quit IRC21:40
*** jmckind has quit IRC21:41
*** fredyx10 has quit IRC21:43
*** fredyx10 has joined #openstack-barbican21:44
*** jmckind has joined #openstack-barbican22:09
*** jmckind_ has quit IRC22:12
*** silos has left #openstack-barbican22:12
*** nelsnelson has quit IRC22:16
*** rhagarty has joined #openstack-barbican22:18
*** rhagarty_ has quit IRC22:21
*** mixos has joined #openstack-barbican22:23
*** rhagarty has quit IRC22:24
*** rhagarty has joined #openstack-barbican22:24
redrobotarunkant pong22:27
*** rhagarty_ has joined #openstack-barbican22:27
*** jmckind has quit IRC22:28
*** rhagarty has quit IRC22:29
arunkantredrobot: still there?22:31
* redrobot waves at arunkant 22:32
arunkantredrobot: Can you check out the spec https://review.openstack.org/#/c/263972 .. Had discussion with rellerreller in morning about this. And he mentioned that he will wait for your comments and feedback on this.22:33
arunkantredrobot: I am hoping that this can be discussed in mid-cycle.22:35
*** kebray has quit IRC22:37
redrobotarunkant yes, I'm hoping we can get a lot of BPs approved next week.22:37
redrobotarunkant I'll try to take a look at it over the weekend.22:37
*** kebray has joined #openstack-barbican22:37
arunkantredrobot: thanks22:37
*** rhagarty has joined #openstack-barbican22:47
*** diazjf has joined #openstack-barbican22:47
*** rhagarty_ has quit IRC22:49
*** stanzi has joined #openstack-barbican22:50
*** rhagarty has quit IRC22:51
*** mragupat_ has quit IRC22:55
*** mp1 has quit IRC23:01
*** diazjf has quit IRC23:02
*** mp1 has joined #openstack-barbican23:02
*** rhagarty has joined #openstack-barbican23:05
*** mp1 has quit IRC23:05
*** rhagarty_ has joined #openstack-barbican23:07
*** rhagarty has quit IRC23:10
*** dimtruck is now known as zz_dimtruck23:12
*** stanzi has quit IRC23:22
*** stanzi has joined #openstack-barbican23:22
*** stanzi has quit IRC23:25
*** stanzi has joined #openstack-barbican23:26
*** stanzi has quit IRC23:31
*** stanzi has joined #openstack-barbican23:31
*** stanzi has quit IRC23:37
*** spotz is now known as spotz_zzz23:38

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