Thursday, 2015-08-13

*** SheenaG has quit IRC00:24
openstackgerritDave McCowan proposed openstack/barbican: Implement Models and Repositories for Resource Quotas
*** gyee has quit IRC00:40
*** crc32 has joined #openstack-barbican00:49
*** crc32 has quit IRC00:52
*** jvrbanac has quit IRC00:58
*** jvrbanac has joined #openstack-barbican01:00
*** crc32 has joined #openstack-barbican01:02
*** chlong has joined #openstack-barbican01:04
openstackgerritPradeep Kumar Singh proposed openstack/barbican: Make tests in barbican.tests.tasks py3 compatible
openstackgerritPradeep Kumar Singh proposed openstack/barbican: Make tests in barbican.tests.tasks py3 compatible
*** dimtruck is now known as zz_dimtruck01:31
*** tkelsey has joined #openstack-barbican01:36
*** vivek-ebay has quit IRC01:39
*** tkelsey has quit IRC01:40
openstackgerritPradeep Kumar Singh proposed openstack/barbican: Make tests in barbican.tests.model py3 compatible
*** vivek-ebay has joined #openstack-barbican02:06
*** SheenaG has joined #openstack-barbican02:07
openstackgerritOpenStack Proposal Bot proposed openstack/barbican: Updated from global requirements
*** woodster_ has quit IRC02:10
*** edtubill has joined #openstack-barbican02:13
*** zz_dimtruck is now known as dimtruck02:15
openstackgerritZhenyu Zheng proposed openstack/barbican: Drop downgrade field in alembic and version
*** SheenaG has quit IRC02:38
*** xaeth_afk is now known as xaeth02:53
*** elmiko has quit IRC02:53
*** elmiko has joined #openstack-barbican02:55
*** vivek-ebay has quit IRC02:55
*** vivek-ebay has joined #openstack-barbican02:56
*** dave-mccowan has quit IRC03:46
*** dimtruck is now known as zz_dimtruck04:11
*** vivek-ebay has quit IRC04:12
*** vivek-ebay has joined #openstack-barbican04:21
*** xaeth is now known as xaeth_afk04:51
*** xaeth_afk is now known as xaeth05:01
*** vivek-ebay has quit IRC05:15
*** tkelsey has joined #openstack-barbican05:37
*** tkelsey has quit IRC05:41
*** crc32 has quit IRC05:44
*** Nirupama has joined #openstack-barbican05:53
*** nickrmc83 has joined #openstack-barbican05:58
*** edtubill has quit IRC06:00
*** shohel has joined #openstack-barbican06:12
*** shohel has quit IRC06:33
*** shohel has joined #openstack-barbican06:33
*** vivek-ebay has joined #openstack-barbican06:58
*** vivek-ebay has quit IRC07:02
*** nickrmc83 has quit IRC07:06
*** therve has quit IRC07:25
*** therve has joined #openstack-barbican07:25
*** openstackgerrit has quit IRC07:41
*** xaeth has quit IRC07:41
*** jkf has quit IRC07:41
*** openstackgerrit has joined #openstack-barbican07:43
*** xaeth has joined #openstack-barbican07:43
*** jkf has joined #openstack-barbican07:43
*** jkf has quit IRC07:45
*** shohel has quit IRC07:45
*** openstackgerrit has quit IRC07:45
*** shohel has joined #openstack-barbican07:45
*** xaeth has quit IRC07:46
*** xaeth has joined #openstack-barbican07:51
*** jkf has joined #openstack-barbican07:52
*** rm_work is now known as rm_work|away07:56
*** rm_work|away is now known as rm_work07:58
*** openstackgerrit has joined #openstack-barbican08:00
*** rm_work is now known as rm_work|away08:00
*** rm_work|away is now known as rm_work08:03
*** everjeje has quit IRC08:12
*** chlong has quit IRC08:13
*** tkelsey has joined #openstack-barbican08:19
*** rm_work is now known as rm_work|away08:25
*** rm_work|away is now known as rm_work08:25
*** rm_work is now known as rm_work|away08:28
*** rm_work|away is now known as rm_work08:29
*** nickrmc83 has joined #openstack-barbican08:48
*** everjeje has joined #openstack-barbican09:11
*** tkelsey has quit IRC10:18
*** shohel1 has joined #openstack-barbican11:02
*** shohel has quit IRC11:02
*** chlong has joined #openstack-barbican11:04
*** peter-hamilton has joined #openstack-barbican11:18
*** ajc_ has joined #openstack-barbican11:43
*** ajc_ has quit IRC11:43
*** alee_ has quit IRC11:57
*** dave-mccowan has joined #openstack-barbican12:00
*** shohel1 has quit IRC12:03
*** rellerreller has joined #openstack-barbican12:35
*** Nirupama has quit IRC12:55
*** openstackgerrit has quit IRC13:01
*** openstackgerrit has joined #openstack-barbican13:02
*** everjeje has quit IRC13:02
*** atiwari1 has joined #openstack-barbican13:13
*** atiwari has quit IRC13:14
*** shohel has joined #openstack-barbican13:20
*** lisaclark1 has joined #openstack-barbican13:20
hockeynutlooking thru our scripts - I see we still use keystone command (which is deprecated) as opposed to openstack command.  Anyone done any work in this area yet?13:20
*** peter-hamilton has quit IRC13:26
*** peter-hamilton has joined #openstack-barbican13:27
*** SheenaG has joined #openstack-barbican13:29
dave-mccowanhockeynut i made it worse by adding more keystone commands :-) but haven't done anything to move to the openstack command.13:31
hockeynutLOL - I am looking at other projects to see what they do (or if we're all in the same deprecated boat)13:32
*** xaeth is now known as xaeth_afk13:35
*** alee_ has joined #openstack-barbican13:40
openstackgerritMerged openstack/castellan: Remove copy_key operation
*** lisaclark1 has quit IRC13:43
*** peter-hamilton has quit IRC13:46
*** lisaclark1 has joined #openstack-barbican13:50
*** peter-hamilton has joined #openstack-barbican13:53
*** DTadrzak has quit IRC13:55
*** diazjf has joined #openstack-barbican13:59
*** zz_dimtruck is now known as dimtruck14:03
*** pglass has joined #openstack-barbican14:05
*** spotz_zzz is now known as spotz14:08
*** lisaclark1 has quit IRC14:11
rellerrellerdiazjf Here is the link to the swift spec that is creating the KeyMaster,
rellerrellerdiazjf at the summit you and solis said you might be willing to talk with them to try and integrate Castellan instead of creating KeyMaster.14:14
*** edtubill has joined #openstack-barbican14:17
*** lisaclark1 has joined #openstack-barbican14:17
*** DTadrzak has joined #openstack-barbican14:21
*** xaeth_afk is now known as xaeth14:25
*** silos has joined #openstack-barbican14:31
rellerrellerDoes anyone have expert knowledge of utils.parameterized_dataset? Adding attributes does not appear to stick with the parameterized function.14:40
rellerrellerjvrbanac you know about ^14:40
jvrbanacrellerreller, I know quite a bit about it14:41
jvrbanacrellerreller, what do you mean by "do not appear to stick"?14:43
*** vivek-ebay has joined #openstack-barbican14:50
rellerrellerjvrbanac I added a "non-standard-algorithm' attribute to a method.14:52
rellerrellerjvrbanac in particular to the functional test_secret_create_valid_algorithms14:53
rellerrellerjvrbanac If I run nosetests and apply the extra parameter "--attr='non-standard-algorithm'" then no tests are run14:53
rellerrellerjvrbanan the test test_secret_create_valid_algorithms is a parameterized function test.14:54
*** morgan_404 is now known as morgan_30214:55
rellerrellerIf I remove the parameterized.data_set attribute from the function and hard code in the one example value ("invalid" in this case) then rerun nosetests with attribute parameter then one test is run.14:55
jvrbanacrellerreller, so I haven't used nose attributes. I'm not sure if testr supports that either.14:56
rellerrellerjvrbanac My guess is that when building the new parameterized functions that the other decorators on the function are lost.14:56
rellerrellerjvrbanac correct. I had to import nosetests attributes14:56
rellerrellerThere was a 'positive' attribute but that attribute was imported from testtools, but we do not run our tests with test tools, so I changed it to nosetests attribute14:57
diazjfrellerreller, correct, Janie Richling wants to move forward with Castellan instead of the Trivial Keymaster, but she will have to convince the swift-cores14:58
*** vivek-ebay has quit IRC14:59
rellerrellerdiazjf thanks for the update. That would be great if swift integrates with Castellan.14:59
diazjfrellerreller, I'll let you know as soon as I hear more15:00
diazjfredrobot, wanna do hangouts today at 1:00PM CST to go over
jvrbanacrellerreller, so if we're running this in the gate it does need to support testr. So one of the reasons we have our own parameterized piece is that it supports nose, pytest, and testr15:11
jvrbanacrellerreller, however when we start supporting tagging, we'll need to make sure we pass through the information on new methods. Which sounds like the issue you're seeing right now15:12
openstackgerritNathan Reller proposed openstack/barbican: Made Functional Test Key 256 Bits
openstackgerritNathan Reller proposed openstack/barbican: Integrated with PyKMIP Pie API
diazjfrm_work, just took a look at I like the idea15:13
rellerrellerjvrbanac That is correct. Right now I am not able to pass command line arguments to tox to limit tests by attribute. Unless I am doing something wrong, which is possible :)15:14
rellerrellerAn easy review with only one line change,
*** SheenaG has quit IRC15:21
*** arunkant_ has joined #openstack-barbican15:22
*** kfarr has joined #openstack-barbican15:23
*** SheenaG has joined #openstack-barbican15:24
*** arunkant_ has quit IRC15:31
*** vivek-ebay has joined #openstack-barbican15:32
*** arunkant_ has joined #openstack-barbican15:33
*** darrenmoffat has quit IRC15:37
*** darrenmoffat has joined #openstack-barbican15:38
redrobotdiazjf sounds good15:43
diazjfredrobot, perfect, send me your hangouts email15:44
*** woodster_ has joined #openstack-barbican15:57
*** SheenaG has left #openstack-barbican15:59
*** SheenaG has joined #openstack-barbican15:59
dave-mccowanredrobot: are transport keys supposed to be associated with a project?  for now, the project_id is not stored in the transport key repo.  any admin can see all the transport keys.  is that right?  should the transport keys be per-plugin only, or per-project+plugin?16:01
dave-mccowanalee_ ^^^16:03
alee_dave-mccowan, right now, I believe they are plugin specific16:13
alee_dave-mccowan, the idea is that the traansport key is related to the backend16:13
alee_dave-mccowan, so in the case of dogtag, we have one transport key for the kra16:13
dave-mccowanalee_ so it does not make sense to enforce project level quotas on them, right?16:14
alee_dave-mccowan, sure - I'd agree with that16:14
alee_(until we add support for transport key per project)16:15
alee_if we ever do)16:15
*** diazjf has quit IRC16:20
*** lisaclark1 has quit IRC16:20
*** gyee has joined #openstack-barbican16:22
*** diazjf has joined #openstack-barbican16:30
*** openstackgerrit has quit IRC16:31
*** openstackgerrit has joined #openstack-barbican16:32
*** crc32 has joined #openstack-barbican16:33
*** lisaclark1 has joined #openstack-barbican16:34
*** lisaclark1 has quit IRC16:34
*** lisaclark1 has joined #openstack-barbican16:34
*** shohel has quit IRC16:36
dave-mccowanalee_  by the way, i ran into a spurious failure in the dogtag gate check16:41
alee_dave-mccowan, what is it?16:41
dave-mccowanin the secret tests, there is a create_then_expire check.  it goes:  create(5 second expiry), check-for-ok, wait for 10 seconds, check-for-gone16:42
dave-mccowanwhen running in parallel mode with the dogtag plugin, at least one time, it took over five seconds between create and check-for-ok.16:43
dave-mccowanalee_ i could fix (or hide) this by cranking up the expiry time.  or try to come up with a better ideas.16:44
*** jamielennox is now known as jamielennox|away16:45
*** silos has left #openstack-barbican16:52
alee_dave-mccowan, gotcha16:53
alee_yeah - let me noodle a not on that16:54
alee_a bit that is16:54
dave-mccowanalee_ the parallel running tests messed up some of the quotas tests that use shared resources.  i started a skip list in my last CR.  so another option to consider is to not run timing sensitive tests through the parallel run.16:56
*** kfarr has quit IRC17:04
*** rellerreller has quit IRC17:07
*** tkelsey has joined #openstack-barbican17:08
dave-mccowanalee_ back to transport keys: since those are deployment wide resources, shouldn't it require service level (not just project admin level) privileges to operate them?  seems like an admin for project-a could impact project-b pretty easily.17:08
*** vivek-ebay has quit IRC17:08
*** vivek-ebay has joined #openstack-barbican17:32
*** vivek-ebay has quit IRC17:32
*** edtubill has quit IRC17:33
*** diazjf has quit IRC17:41
*** diazjf has joined #openstack-barbican17:50
*** vivek-ebay has joined #openstack-barbican17:53
*** vivek-ebay has quit IRC17:54
*** edtubill has joined #openstack-barbican17:55
*** silos has joined #openstack-barbican17:57
*** rm_work is now known as rm_work|away17:58
*** rm_work|away is now known as rm_work18:00
rm_workthanks diazjf -- we'll see if it pans out18:00
diazjfrm_work np18:00
diazjfredrobot, gonna start the hangout18:00
redrobotdiazjf cool18:00
rm_workalee_: commented18:05
*** rellerreller has joined #openstack-barbican18:09
rm_worklike three times, because i kept missing various concerns18:11
rm_workrellerreller: you're killing me18:11
rellerrellerrm_work sorry18:12
rm_workrellerreller: np, just giving you a hard time in return :P take a look at
rm_workthe comments, not the trivial changes18:12
rm_workrellerreller: "Why is creating a container required? Why can't a normal KeyManager be used store each of the items?"18:13
rm_workrellerreller: the normal Keymanager COULD be used to store each of the items -- in fact i have a generic implementation in mind that will use KeyManager to actually handle 100% of the storage interaction18:14
rm_workMaybe what I need to do is just write it up and include it18:14
rellerrellerrm_work that sounds great. Problem solved!18:14
rm_workrellerreller: i mean, I have an implementation of CertManager that works in that way :P18:15
rm_workbut you're commenting on the interface, not the implementations, which is why I am confused18:15
rm_workthe interface itself doesn't REQUIRE anything specific as far as storage18:15
openstackgerritAdam Harwell proposed openstack/castellan: Officially add Certificate Management to scope
rellerrellerrm_work my comments are on the interface because I am thinking of future implementations.18:17
rellerrellerrm_work the concept of a container is related to Barbican. If it is the only thing that supports a container then maybe an interface is not required.18:17
rm_workEVERYTHING supports a container18:18
rellerrellerrm_work I know that you could plug in a bunch of different implementations behind it if you hacked things together, but I feel like that is not the best approach.18:18
rm_workthere's no restriction that things have a "specific concept of a container" to support groupings18:18
rm_workas long as we have one consistent definition of how that works18:19
rm_workfor each bqackend18:19
rellerrellerrm_work when you say everything supports a container then you mean that it is possible to store a group of objects together.18:19
rellerrellerrm_work In your mind a CertificateManager implementation that writes a blob of data to file and returns UUID is a valid certificate manager. I think that is a bit of a hack to make it support containers.18:20
rm_workrellerreller: i think it doesn't matter18:20
rm_workrellerreller: i think we could also shove everything into PKCS12 and store THAT in the device18:20
rm_workif the device supports PKCS1218:20
*** SheenaG has quit IRC18:20
rm_workthere are quite a few ways to do it18:20
rm_worksure, some are hackier than others18:21
rm_workbut none of them are so hacky that I think they aren't a reliable approach here18:21
*** kfarr has joined #openstack-barbican18:21
rellerrellerrm_work I agree that you could use PKCS12 like that, but that is kind of hiding objects in the key manager.18:21
rellerrellerrm_work I feel that a common interface for key managers should be fairly intuitive as to the operations it performs.18:22
rm_workso you absolutely want to keep objects stored individually in the keymanager, but you absolutely don't want to see a grouping of objects?18:22
rellerrellerrm_work for instance store easily maps to register in KMIP and some similar operation in PKCS11.18:22
rellerrellerKMIP does not support grouping objects together, and I do not know how much support is provided by PKCS11 for that.18:23
rm_workrellerreller: maybe it makes sense for there to be a KMIP implementation, maybe it doesn't?18:23
rm_worki think that's really off track18:23
rm_workso maybe we don't make a KMIP impl18:23
rm_worki am saying it is 100% possible to do, but maybe we don't need or want one18:23
rm_workhell, one use-case for this is just barbican_v1 -> barbican_v2 apparently18:24
rellerrellerrm_work what other implementations have a container concept?18:24
rm_workthe whole point is that we don't care what backends have a container, we want to be able to make a logical grouping at a higher level18:24
rellerrellerrm_work it matters in terms of what implementations we think can support it and how easy it will be to do that.18:25
rellerrellerrm_work for instance KMIP would have a difficult time doing that. Most implementations will not support opaque objects.18:26
rm_workand as I said, I can make an implementation that will work with literally any backend18:26
rm_workyou just don't like the way it works18:27
rellerrellerrm_work it also matters in terms of auditability. If we are creating blobs of data on highly sensitive key management devices then we should know what data reside on them.18:27
rm_workshould you?18:27
rm_workor is the whole point of the KMD that the data is opaque end-to-end?18:28
rellerrellerrm_work that is not true. Not all devices support opaque objects, so I know many KMIP devices that will not support this.18:28
rm_worki thought that the whole point was that a user could be secure in the knowledge that no one can read what they put in18:28
rm_workaccording to what I have read about KMIP, the ability to store arbitrary data is not in question18:29
rm_worki also find it interesting that with all the assertions that Certificates aren't secret data18:29
rm_workKMIP protocol defines interactions with Certificates explicitly18:30
rellerrellerrm_work check out opaque data types and notice that nothing is defined.18:30
rellerrellerrm_work I have no problem storing certificates.18:30
rellerrellerrm_work I have a meeting.18:31
rm_work"A KMIP server stores and controls Managed Objects such as Symmetric and Asymmetric keys, Certificates, and user defined objects."18:31
rm_work"The types of managed object that are managed by KMIP include:-"18:31
*** tkelsey has quit IRC18:31
rm_work""Opaque Data for client and server defined extensions."18:31
rm_work"Secret Data (passwords)."18:31
rm_workif you can store a password, I can store anything I want, because any string could be a password18:32
openstackgerritAdam Harwell proposed openstack/castellan: Add barbican implementation of CertManager
openstackgerritAdam Harwell proposed openstack/castellan: Copy octavia.certmgr to Castellan
rm_work^^ rebases18:33
rm_work^^ rebases18:33
*** edtubill has left #openstack-barbican18:34
*** rellerreller has quit IRC18:35
*** kfarr has quit IRC18:40
*** gyee has quit IRC18:45
*** diazjf has left #openstack-barbican18:48
*** nkinder has joined #openstack-barbican18:49
*** atiwari1 has quit IRC18:49
*** nkinder has quit IRC18:50
*** lisaclark1 has quit IRC18:54
*** lisaclark1 has joined #openstack-barbican18:57
*** lisaclark1 has quit IRC18:59
openstackgerritAdam Harwell proposed openstack/castellan: Example implementation for a GENERIC CertManager
rm_work^^ VERY quick example of how a generic CertManager implementation would work18:59
rm_workalee_ / rellerreller: ^^18:59
rm_workmaybe now I can stop explaining this :P18:59
*** SheenaG has joined #openstack-barbican19:02
*** rellerreller has joined #openstack-barbican19:02
*** lisaclark1 has joined #openstack-barbican19:05
rm_workwrote up an example really quick19:08
rellerrellerrm_work I see that.19:09
rellerrellerrm_work why not store the metadata in a common service instead of the key manager?19:10
rm_workwhich common servce?19:10
rm_workI understand what you're saying, my question is more rhetorical19:10
rellerrellerrm_work you are creating the container with Service A then storing that URL to the container in some common place. THen Service B comes along, uses the container ID to get all of the different components.19:11
rm_workbut *what* common service? some DB somewhere?19:11
rellerrellerrm_work so why not store a URL for each secret instead of a container?19:11
rm_workthe keyManager *is* the common service19:11
rm_workrellerreller: so, if you read the comments on the higher level CR i did ask that question19:12
rm_work" If the general consensus is that the usability improvement is so trivial between this method and having no logical grouping system, then I guess I would have to cede to that view. Personally, I think there are numerous advantages to a logical grouping, not the least of which is that as a user you can more easily keep track of which Secrets link with what. If I have 20 Private Keys and 60 different X509 Certs that go with them,19:12
rm_work and passphrases for them and Intermediates for them -- how the heck do I keep track of that easily as a user?"19:12
rm_workbecause kfarr asked the same thing you did19:13
rm_workbut I *don't* think that's the consensus19:13
rm_workI think so far that's you and her in the minority :)19:13
rellerrellerrm_work In cinder volume encryption you create a key with Cinder and then Nova reads the key. The metadata is stored with the volume.19:13
rm_workrellerreller: that's a totally different case19:13
rm_workthere's no analogue here19:13
rellerrellerrm_work your use case is for VPNaaS or something. You create keys with one entity and then some other entity reads them and uses them.19:13
rm_workthe *user* creates the certbundle19:14
rellerrellerrm_work where are your slides from your presentation. I can show you.19:14
rm_workand then SEVERAL services read them19:14
rm_workthere's no common place for metadata storage between LBaaS, VPNaaS, FWaaS, HEAT19:14
rm_workbesides the KeyManager19:15
rm_workthat's the point19:15
rellerrellerrm_work look at your slides
rm_workok, which slide19:15
rellerrellerrm_work the one entitle "Neutron/LBaaS + Barbican"19:16
rm_workI am on that slide19:16
rellerrellerThe user creates container in Barbican and then stores container ID in Neutron LBaaS.19:16
rellerrellerrm_work why not store each item and then store each URL to each secret in Neutron19:16
rm_workyou want the user to create individual keys in Barbican and store 3-4 refs in Neutron-LBaaS19:17
rm_workI get that19:17
rm_workand my response to that is:19:17
rm_work" If the general consensus is that the usability improvement is so trivial between this method and having no logical grouping system, then I guess I would have to cede to that view. Personally, I think there are numerous advantages to a logical grouping, not the least of which is that as a user you can more easily keep track of which Secrets link with what. If I have 20 Private Keys and 60 different X509 Certs that go with them,19:17
rm_work and passphrases for them and Intermediates for them -- how the heck do I keep track of that easily as a user?"19:17
rm_workyou are asking the exact same question kfarr asked19:17
rm_workif this is something we can standardize and abstract, why would we not want to do that?19:18
rm_workwe can provide quite a bit of utility around the CertBundle concept19:19
*** edtubill has joined #openstack-barbican19:19
rellerrellerrm_work because it is much easier to store 3 URLs as metadata as opposed to creating a new interface with new implementations of which only Barbican has a good mapping.19:19
rm_workthings that aren't there yet, but could be eventually -- validation, parsing, etc19:19
rm_workrellerreller: I would want this even if Barbican had no Container mapping19:19
rm_workin fact I am on the warpath here again in part because it's possible Barbican won't, in the future19:20
rm_workand we *need* to standardize this grouping19:20
rm_workearly, before end-users start utilizing these services19:21
rellerrellerYou keep highlighting need and emphasizing that, but I just showed that you don't need it.19:21
rellerrellerIt is possible to do LBaaS without a CetificateManager interface as you have defined it.19:21
* peter-hamilton is eating popcorn19:22
rm_worki think you're underestimating how much the user story improves19:22
rm_workrellerreller: oh yes, definitely19:22
rm_worki said as much19:22
rm_worki also said it would be annoying as all hell for the users19:22
rellerrellerrm_work why is it annoying?19:23
rm_workthere's no way I would want to individually track all of this stuff when the system can easily do it for me19:23
rm_workrellerreller: imagine you have 20 private keys and 60 certificates and many of them have different intermediate chains19:23
rellerrellerrm_work I create lots of keys for volume encryption and image encyption and signing.19:23
rm_workok, how do you keep track of them?19:23
rellerrellerI associate them with an object, like a volume or image.19:23
rm_workexcept they need to be associated with EACH OTHER19:23
rellerrellerThen I query the image and it returns the 1 or 2 items that are associated with it.19:24
rm_workthat is fine if everything is independent19:24
rellerrelleri.e. my many images that are encrypted, but each image only has 1 or 2 items associated with it. That is easy to manage.19:24
rm_workso you're saying if the user wants to set up a new VPN, they should find one of their LoadBalancers that happens to use the correct Cert/Key combo and query it and get their data back?19:24
rm_workthat is nuts19:24
rellerrellerWhen you call Neutron what is the container associated with?19:25
rm_worka Loadbalancer19:25
rellerrellerWhat is the API call?19:25
rellerrellerwhat is the method signature?19:26
rm_workGET http://myurl/neutron-lbaas/loadbalancers/<lb_id>/tls19:26
rellerrellerCan you send link to API call?19:26
rellerrellerI don't know what the expected input and output parameters are.19:27
rm_workfor a GET?19:27
rellerrellerSomething like this
rm_workour docs aren't done yet19:28
rm_worki am hoping we have something semi-useful tho19:28
rellerrellerWhat is neutron client code method signature?19:29
rm_worknot sure TLS has been added to that yet19:29
rellerrellerSo basically you are associating a container ID to LB ID, correct?19:30
rm_workit's one field19:30
rm_workso like, LBID 1234519:31
rm_workmight have an extra json element19:31
rm_work"certificate_ref": "<cert_ref>"19:31
rm_workin its return data structure19:31
rellerrellerSo if I wanted to know the private key, public key, and certificate associated with a LB then I would query Neutron and say GET for LB.19:31
rellerrellerThen that would return 3 URLs for where private key, public key, and certificate are located.19:32
rellerrellerThat seems just as easy to manage as one for container, or maybe I am missing something.19:32
rm_workand that is a retarded workflow for tracking which PK/Certs are associated with each other in your KeyManager19:32
rellerrellerSo while I may have 100s or 1000s of keys I can easily see how they are related by viewing the metadata for a LB19:33
rm_workthat is ...19:33
rm_worki don't even know how to respond to that19:33
rm_workcan someone help me out here?19:33
* peter-hamilton is still eating popcorn19:33
rm_workLBs are just one service19:34
rellerrellerPlease do not say that is retarded. That is not helpful.19:34
rellerrellerI'm trying to work through this.19:34
rm_workyeah, sorry, i am having trouble because I feel like at a fundamental level there is something you're missing19:34
rm_workbut i can't figure out how to explain it19:34
* redrobot pokes head in19:35
rm_workand the fact that i can't figure out how to explain it is almost more frustrating19:35
rellerrellerI would like to know if I am missing something because this is how keys and other secrets are managed in Nova, Cinder, and soon Glance.19:35
redrobotrm_work who's the user you keep arguing for?  devs in other projects using api to talk to lbass?  or end users of a cloud provider (or private cloud)?19:36
rm_workother keys are standalone things19:36
rellerrellerSahara is also looking to use KeyManager and managing secrets in a similar way.19:36
rm_workend users19:36
rellerrellerI do have to leave in a minute.19:36
rm_workif you had a standalone key and it was associated with some CBS volume19:36
redrobotso you're arguing for openstack users19:36
rm_workit makes KINDOF a sort of sense19:37
redrobotand in that case, I would say that I do see value in grouping those things for them in the openstack key manager19:37
rm_workthat if you forgot which key it was you needed, you could look up the CBS Volume that you know uses it19:37
rm_workbut when you have a series of objects that are closely tied to each other, it does not make sense to rely on looking in another system to see how they are grouped19:37
redrobotwhere I'm having trouble is figuring out why this belongs in Castellan19:38
rm_workbecause they are meaningful outside of the other system19:38
rm_workif you were to delete all of your LBs, you would have no way to track which things belonged with each other19:38
redrobotsince castellan's purpose is to allow devs to use other key managers besides the openstack key manager19:38
rm_workwhereas if you deleted all your CBS Volumes, each key is still technically useful because you can still make use of it by itself19:39
redrobotrm_work what other non-barbican key managers do you need to support?19:39
rm_workredrobot: i am more concerned with barbican_v1 vs barbican_v2 at the moment19:39
rm_workwhich an interface like this also helps to mitigate :P19:39
rm_workpersonally as RAX, we don't need a different key manager19:40
rellerrellerMy last point and I have to leave19:40
rellerrellerrm_work "if you were to delete all of your LBs, you would have no way to track which things belonged with each other"19:40
rellerrellerrm_work how would you do that with just certificate URL? The problem seems the same.19:40
rm_workrellerreller: the "certificate_bundle_url"19:40
rellerrellerThat is a reference problem and not a container problem.19:40
rellerrellerBut if you delete LB then metadata is gone so have no certificate bundle URL.19:41
rm_workit'd be in the keymanager19:41
rm_workyou don't even track the keys, you track the certificatebundles19:41
rm_workwhich link together the certs with their appropriate keys and intermediates19:42
redrobotrm_work why not put this in python-barbicanclient if your main concern is openstack user experience?19:42
redrobotrm_work my understanding was your main use case for a non-barbican solution was testing?19:43
rm_workfor US19:43
rm_worknot necessarily for any other place wanting to run LBaaS19:43
rm_workapparently any government facility needs to not use Barbican?19:43
rm_workper how I understand JHU's problem19:44
rm_workso any gov. linked entity running openstack-lbaas would need to use a different impl19:44
rm_workit's the exact same issue19:44
*** rellerreller has quit IRC19:45
rm_workI am honestly not often thinking of RAX when working on this stuff, but openstack as a whole19:45
redrobotbut if the barbicanclient impl uses castellan then there is no issue19:46
rm_workuhhh what19:46
rm_workwhy would Barbican-Client use Castellan to use KMIP? >_>19:46
redrobotno idea, I didn't think that one through19:46
rm_workthe whole point is that Castellan is the generic interface19:47
redrobotthe problem is where to store the association19:47
rm_workwhich i don't think is a problem19:47
redrobotif the deployment is using barbican, then barbican can store it19:47
rm_workif the deployment is using anything that can store data, then that system can store it19:47
* peter-hamilton is out of popcorn19:49
elmikorm_work: i have to admit, the use case is going over my head (aside from the convenience angle), but the change requests lgtm codewise.19:51
peter-hamiltonrm_work: tbh, this sounds like something that should sit on top of castellan or barbican (containers-as-a-service)19:53
rm_workif only that name weren't already in use :P19:54
peter-hamiltonrm_work: :)19:54
*** peter-hamilton has quit IRC19:54
rm_workBasically, I don't see any better place to put it, i think it has enough ties to what Castellan does to make sense having it there, and i DEFINITELY don't see the harm it would cause by being there (while it seems other people see it as an End Of The World scenario)19:55
rm_workthe best arguments I've seen that I can't instantly debunk are that "it doesn't seem to add much", but the amount of people I have talked to that think it DOES add enough to be worthwhile is a significantly larger pool... i am starting to wonder what the fight is even about19:56
rm_workare people opposed to this simply out of habit?19:56
redrobotI just want to understand more of the non-barbican implications19:57
redrobotlike, will someone really deploy a cloud with netron-lbass talking directly to a kmip device19:58
rm_workwell, it sounds like soon Barbican won't have a containers concept either19:58
rm_workand THEN what happens to us? :?19:58
redrobotone argument against storing metadata as a string in the kmip device is that storage is usually very limited in HSMs19:59
rm_workthat's valid20:00
rm_workhow limited are we talking?20:01
redrobotrm_work I don't remember the exact limit, but it was in the MBs20:01
redrobotrm_work we had to re-architect the pcks#11 plugin to deal with the storage limits20:02
rm_workwell, I would imagine the "container" secret is fairly minimal compared to any of the parts20:02
rm_worki guess the concern would be even storing the certs in there would be large20:02
redrobotyeah, it would only really work for tiny clouds20:03
*** pglbutt has joined #openstack-barbican20:03
rm_workif that's the case, then even rellerreller's alternative solution (passing three refs) doesn't help20:04
rm_workbecause it has the same problem20:04
rm_workthe "metadata secret" is trivially small comparatively20:04
*** pglass has quit IRC20:05
rm_workand in that case, you could make another implementation of CertManager, that uses split backends, HSM for the PK/passphrase, and some other backend (a db even) for the other data20:06
rm_workit's not as simple, but it works20:06
rm_workyou can do an implementation of the interface that does almost anything you can think of20:06
rm_workmost of the arguments against this are against people's visions of specific implementations and their restrictions, nothing related to the interface itself20:07
rm_workredrobot: ^^20:07
rm_workwould you agree?20:07
*** lisaclark1 has quit IRC20:07
*** pglass has joined #openstack-barbican20:10
redroboteh... not sure20:13
*** pglbutt has quit IRC20:14
rm_workif i go back and look at the arguments against, i pretty much only see stuff that's related to specific implementations (and people's assumptions about how they would work)20:14
rm_workI could hack up a split-backend example really quickly, if that would help20:14
openstackgerritOpenStack Proposal Bot proposed openstack/barbican: Updated from global requirements
*** lisaclark1 has joined #openstack-barbican20:21
*** lisaclark1 has quit IRC20:21
*** tkelsey has joined #openstack-barbican20:24
redrobotrm_work so, the way I see it, I don't really care about the end user story, but I do care about the deployment story20:32
rm_workpoor end-users T_T20:32
redrobothorizon could store the key to container associations in a UI if all we care about is end users20:32
redrobot* key to cert20:32
rm_workif all you care about is UI end-users20:33
redrobotyeah, and I do see value in storing that _somewhere_ for openstack use20:33
redrobotbut adding a new interface with its sets of plugins complicates deployment20:33
rm_workbut simplifies interoperability and changes in base services :/20:34
*** pglass has quit IRC20:34
rm_work(ie, changes in how barbican handles storing containers)20:34
*** pglass has joined #openstack-barbican20:35
redrobotI don't think services passing a single reference vs may references really makes a difference20:38
* redrobot can't type today20:38
rm_workwell, as you were saying, it may not even be an option to store cert data in HSMs20:39
rm_workwhich is where Castellan CertManager using a split-backend implementation would come in useful20:40
rm_workbut yes, technically LBaaS/etc could just use CastellanKeyManager and take three refs...20:41
rm_workI think it's a significantly worse end-user experience20:41
rm_workbut it would work in a technical sense20:41
rm_workif that's what it comes to20:41
*** edtubill has quit IRC20:44
*** tkelsey has quit IRC20:44
redrobotI think it would make for a better non-barbican story20:45
rm_workI actually think an interface like this that allows for things like split-backend would prevent issues down the road if we decide we DO want to change the way Certs are stored (like changing it so they're just metadata on PKs even in Barbican)20:45
rm_workbecause it's inherently *not something the services care about*20:47
rm_workso by abstracting it away, it makes it much easier for YOU to control the story20:47
rm_workas opposed to leaving it up to the individual services to choose the details of how things are stored20:48
rm_workredrobot: ^^20:48
rm_workfor instance right now we store everything in Barbican, and you don't have any way to control that. if it were to be a problem in the future, you'd have to get any services to change the way they work internally, as opposed to just tweaking the CertManager impl :P20:49
*** woodster_ has quit IRC20:50
*** woodster_ has joined #openstack-barbican20:54
redrobotI don't like the split-backend idea, because you're basically deploying a new service just to hold cert metadata.... might as well deploy barbican at that point.20:56
rm_workunless you can't deploy barbican :P20:56
rm_workand not just cert metadata20:56
rm_workunless you consider the actual x509 to be "metadata"20:56
redrobotno, the actual X.509 is already covered by the current key_manager interface20:57
rm_workredrobot: unless you have limited space in an HSM20:57
rm_workwhich is the other major argument i'm hearing20:58
redrobotlimited space argument is for storing the key->cert association20:58
redrobotin the device20:58
alee_redrobot, I'm not sure I understand the whole "limited space in the HSM" argument.  Aren't you only storing the project KEKs in the HSM?20:58
rm_workyou can't say "the HSM has limited space, so you can't store a trivially small association" but also say "the HSM has more than enough space to store very large Certs and Intermediate Lists"20:58
redrobotalee_ the proposed kmip implementation would stuff the association into a password and store it in the device20:59
redrobotalee_ *cert_manager impl for kmip that is20:59
rm_workyes, which is negligible in size to the actual data being stored21:00
alee_redrobot, oh - I didn't see that - but yeah - thats totally whacked ..21:00
rm_workthe cert alone is 10x the size of the association21:00
rm_workor more21:00
redrobotrm_work yes, but it would be storing objects in the device that don' belong there21:00
alee_rm_work, why does the association need to be stored as a password?21:00
rm_workalee_: it's just an example21:01
rm_worksince people keep saying it isn't possible21:01
rm_workredrobot: according to you and others, certs don't belong there either21:01
rm_worksince they aren't secret data21:01
alee_rm_work, see my last post on the CR21:02
*** silos has left #openstack-barbican21:02
alee_rm_work, if you want to say that this is an extension to the initial vision of castellan and that therefore kmip devices need not implement it, then that makes sense to me.21:02
rm_worki think that's valid21:03
alee_rm_work, if you are trying to shoehorn something like kmip to implement it- then that makes no sense to me21:03
rm_workas i have said here before, whether or not there is a KMIP implementation is a little bit beyond the point21:03
redrobotwell, there has to be some other non-barbican implementation for this to make sense for Castellan21:03
rm_workredrobot: there could practically be two *barbican* implementations21:04
rm_workin fact since secrets support metadata *currently*, i could make another one right now21:04
redrobotrm_work but your concern is deployments of lbass without barbican, right?21:04
rm_workthat doesn't use containers21:04
alee_rm_work, well the point is that you are trying to expand the original vision of castellan - and that needs to be spelled out.21:04
rm_workalee_: the original vision of Castellan that *I* remember did include certificates >_<21:05
rm_workalee_: so that is where we get a little bit lost21:05
rm_workbut yes21:05
redrobotcastellan does include certs21:05
alee_rm_work, maybe but its not what evolved as the vision of castellan21:05
alee_redrobot, really? where?21:05
rm_worktechnically there is a certificate object now21:05
rm_workthough humorously enough the barbican implementation doesn't support it :P21:06
redrobotalee_ ^^21:06
alee_redrobot, and where is this used?21:07
rm_workthough realistically it's this:
rm_workwhich is the only current implementation of Certificate21:07
rm_workalso the only one I can think of -- aren't certificates exclusively x509?21:07
redrobotrm_work gpg keys are technically certs as well, I think21:08
alee_yes -- so this is a little redundant/confusing to say the least21:08
rm_worki am not really sure why that was abstracted as an additional layer21:09
rm_workbut you'll note that the CertManager returns a CertificateBundle which *includes* Certificate and PrivateKey and Passphrase classed objects21:09
rm_workif you look at either implementation I added21:10
alee_rm_work, I agree that the interface is useful.  I do think that you attempting to create a kmip version confuses things.21:10
rm_workit's just an example21:10
rm_workand it's not KMIPCertManager21:10
rm_workit's GenericCertManager21:10
rm_workwould work with LDAP or others too :P21:10
alee_rm_work, yes and not a good one because it implies that something like KMIP would be required to implement this.21:11
rm_worki think you're reading a bit much into one implementation existing21:12
rm_worklike it precludes others somehow?21:12
rm_workbut that's fine21:12
alee_rm_work, no - I'm just making the point that this is new and that it expands the perceived definition of castellan21:13
alee_and that there is really only one implementation right now21:13
alee_which would be barbican21:13
rm_workmaybe i misunderstood -- what do you mean "it implies something like KMIP would be required"21:13
alee_and so the question would be -- if there is only one real implementation of this -- why should it reside in castellan as opposed to barbican client21:14
redrobotthe answer is that lbass doesn't want a hard barbican dependency21:15
redrobotbut bundling certs with keys is a barbican feature21:15
rm_workredrobot: and an anything else feature >_>21:15
rm_worksee: PKCS1221:15
rm_workthe association of "bundling certs with keys" with "barbican feature" is absurd to me21:16
redrobotrm_work the kmip protocol itself does not bundle certs21:16
rm_workno, but the concept of bundling certs with keys is a common one21:16
alee_redrobot, why is that relevant?21:16
rm_workbarbican didn't invent the idea, it just decided to implement it because it was already such a common idea :P21:17
redrobotalee_ trying to convince rm_work  that bundling is not an "anything else" feature21:17
rm_workin fact if you think back a bit, LBaaS was the driving factor for you even having Typed Containers originally21:17
rm_workIIRC we were the first to ask for them and CertContainer was the first to exist21:17
alee_rm_work, if its a common idea, I'm sure you can find a service that creates pkcs12 somewhere ..21:18
redrobotthey're mostly used by Microsoft21:18
rm_workthe idea is that they are used together21:18
rm_workthey're a logical grouping21:18
rm_workPKCS12 is just the existing proof of that21:18
rm_workit's also "one implementation"21:18
alee_redrobot, the idea of having some object that contains certs and keys has been around for awhile21:18
redrobotyeah, but I don't know of any key store that stores them as a bundle21:19
redrobotwhich is where we're all getting stuck on this21:19
rm_workredrobot: I look at that as a deficiency that we are in a position to resolve O_o21:20
rm_worknot a blocker21:20
rm_workat some point nothing did anything, until someone decided it needed to do something, and made it so21:20
rm_workmaybe the objection is that I'm taking a middle-out approach instead of bottom-up or top-down21:21
alee_rm_work, redrobot I have to go.  please add comments to the CR.  I think we are making progress precisely because this is all finally being written down.21:21
redrobotyeah, i have to get going here pretty soon too.21:22
* alee_ thinks rm_work should have written a formal spec long ago.21:22
rm_workI think I suffer from "it is so obvious in my head that how could it need a written spec" syndrome21:23
rm_worki can't even imagine where to start21:23
rm_workbut you are probably correct21:23
alee_that perhaps is precisely the problem ..21:23
rm_workmaybe you could help me get a spec started for this? :P21:24
rm_workif nothing else it'd be more productive use of time than just arguing about it constantly :)21:24
alee_I think thats exactly what I did in asking questions on the CR :/21:24
alee_redrobot, so yeah please comment on the CR21:25
redrobotalee_ will do21:25
*** alee_ is now known as alee_going_home21:26
*** tkelsey has joined #openstack-barbican21:27
*** tkelsey has quit IRC21:31
*** alee_going_home has quit IRC21:32
*** lisaclark1 has joined #openstack-barbican21:38
*** gyee has joined #openstack-barbican21:42
*** lisaclark1 has quit IRC21:43
*** lisaclark1 has joined #openstack-barbican21:45
*** lisaclark1 has quit IRC21:49
*** SheenaG has quit IRC21:52
*** lisaclark1 has joined #openstack-barbican21:53
*** lisaclark1 has quit IRC21:59
*** alee_ has joined #openstack-barbican22:02
*** morgan_302 has quit IRC22:04
*** morganfainberg has joined #openstack-barbican22:07
*** gyee is now known as gyee_50022:12
*** SheenaG has joined #openstack-barbican22:13
*** xaeth is now known as xaeth_afk22:20
*** dimtruck is now known as zz_dimtruck22:21
*** vivek-ebay has joined #openstack-barbican22:26
*** SheenaG has quit IRC22:33
*** jamielennox|away is now known as jamielennox22:33
*** vivek-ebay has quit IRC22:46
*** vivek-ebay has joined #openstack-barbican22:46
*** pglass has quit IRC22:47
*** spotz is now known as spotz_zzz22:51
*** zz_dimtruck is now known as dimtruck22:52
*** morganfainberg is now known as morgan_40422:57
*** woodster_ has quit IRC23:00
*** dimtruck is now known as zz_dimtruck23:04
*** jamielennox is now known as jamielennox|away23:18
*** zz_dimtruck is now known as dimtruck23:22
*** tkelsey has joined #openstack-barbican23:28
*** dimtruck is now known as zz_dimtruck23:32
*** tkelsey has quit IRC23:32
*** jamielennox|away is now known as jamielennox23:47
*** zz_dimtruck is now known as dimtruck23:54

Generated by 2.14.0 by Marius Gedminas - find it at!