*** woodster_ has quit IRC | 00:30 | |
*** woodster_ has joined #openstack-barbican | 01:38 | |
*** zz_dimtruck is now known as dimtruck | 01:43 | |
*** dimtruck is now known as zz_dimtruck | 01:43 | |
*** zz_dimtruck is now known as dimtruck | 01:45 | |
*** dimtruck is now known as zz_dimtruck | 02:01 | |
*** alee has quit IRC | 02:13 | |
*** alee has joined #openstack-barbican | 02:28 | |
*** bubbva has quit IRC | 03:30 | |
*** bubbva has joined #openstack-barbican | 03:31 | |
*** ryanpetrello has quit IRC | 03:40 | |
*** ryanpetrello has joined #openstack-barbican | 03:41 | |
*** ayoung is now known as ayoung-ZZZzzz | 03:57 | |
*** kebray has joined #openstack-barbican | 05:02 | |
*** kebray has quit IRC | 05:03 | |
*** kebray has joined #openstack-barbican | 05:04 | |
*** rm_you| has joined #openstack-barbican | 05:07 | |
*** rm_you has quit IRC | 05:09 | |
*** woodster_ has quit IRC | 06:40 | |
*** alee has quit IRC | 07:04 | |
*** jamielennox has joined #openstack-barbican | 07:50 | |
*** davidhadas_ has joined #openstack-barbican | 12:09 | |
*** woodster_ has joined #openstack-barbican | 12:41 | |
*** alee has joined #openstack-barbican | 12:49 | |
*** ametts has joined #openstack-barbican | 13:32 | |
*** lisaclark1 has joined #openstack-barbican | 13:52 | |
*** ametts has quit IRC | 14:06 | |
*** SheenaG1 has joined #openstack-barbican | 14:09 | |
*** ametts has joined #openstack-barbican | 14:16 | |
*** tdink has joined #openstack-barbican | 14:17 | |
*** ayoung-ZZZzzz is now known as ayoung | 14:17 | |
*** nkinder has joined #openstack-barbican | 14:20 | |
*** lisaclark1 has quit IRC | 14:38 | |
*** paul_glass has joined #openstack-barbican | 14:43 | |
*** lisaclark1 has joined #openstack-barbican | 14:43 | |
*** paul_glass1 has joined #openstack-barbican | 14:43 | |
*** jorge_munoz has joined #openstack-barbican | 14:47 | |
*** paul_glass has quit IRC | 14:47 | |
*** lisaclark1 has quit IRC | 14:49 | |
*** jorge_munoz has quit IRC | 14:52 | |
*** jorge_munoz has joined #openstack-barbican | 14:52 | |
*** zz_dimtruck is now known as dimtruck | 14:53 | |
*** davidhadas_ has quit IRC | 14:55 | |
*** kgriffs|afk is now known as kgriffs | 15:03 | |
*** lisaclark1 has joined #openstack-barbican | 15:13 | |
*** lisaclark2 has joined #openstack-barbican | 15:17 | |
*** lisaclark2 has quit IRC | 15:18 | |
*** lisaclark2 has joined #openstack-barbican | 15:18 | |
*** lisaclark1 has quit IRC | 15:20 | |
*** paul_glass1 has quit IRC | 15:33 | |
*** paul_glass has joined #openstack-barbican | 15:37 | |
*** gyee has joined #openstack-barbican | 15:47 | |
*** lisaclark2 has quit IRC | 16:07 | |
*** lisaclark1 has joined #openstack-barbican | 16:10 | |
*** ayoung is now known as ayoung-dogwalkin | 16:18 | |
*** davidhadas has joined #openstack-barbican | 16:24 | |
*** lisaclark1 has quit IRC | 16:28 | |
*** lisaclark1 has joined #openstack-barbican | 16:32 | |
*** jamielennox has quit IRC | 16:37 | |
*** paul_glass has quit IRC | 16:42 | |
*** paul_glass has joined #openstack-barbican | 16:42 | |
*** lisaclark1 has quit IRC | 16:47 | |
rm_work | redrobot: any ideas on timeline for client 3.0? | 16:48 |
---|---|---|
rm_work | woodster_: ^^ ? | 16:48 |
woodster_ | rm_work, I think redrobot mentioned end of this week...good to bring up during IRC today | 16:53 |
*** lisaclark1 has joined #openstack-barbican | 17:01 | |
*** gyee has quit IRC | 17:03 | |
*** jaosorior has joined #openstack-barbican | 17:07 | |
*** davidhadas has quit IRC | 17:11 | |
*** davidhadas_ has joined #openstack-barbican | 17:15 | |
*** atiwari has joined #openstack-barbican | 17:21 | |
*** davidhadas_ is now known as davidhadas | 17:23 | |
alee | atiwari, ping | 17:25 |
*** ayoung-dogwalkin is now known as ayoung | 17:26 | |
*** bdpayne has joined #openstack-barbican | 17:26 | |
*** lisaclark1 has quit IRC | 17:33 | |
atiwari | alee yes | 17:38 |
alee | atiwari, do you know Stanislaw Pitucha / | 17:39 |
alee | ? | 17:39 |
atiwari | alee yes | 17:40 |
alee | atiwari, I'd like to re-submit his https://review.openstack.org/#/c/108429/ for kilo. | 17:40 |
alee | atiwari, or ask him to do it -- its a good start on something we definitely need to do in kilo | 17:40 |
atiwari | ok, let me start | 17:41 |
atiwari | I will let you know | 17:41 |
alee | atiwari, cool thanks | 17:41 |
*** rellerreller has joined #openstack-barbican | 17:41 | |
*** lisaclark1 has joined #openstack-barbican | 17:41 | |
alee | atiwari, also -- take a look at https://review.openstack.org/#/c/127353/ | 17:41 |
alee | atiwari, I think this will give you what you want for pre-user secrets | 17:42 |
atiwari | alee sure, is it regarding the ownership? | 17:42 |
atiwari | great | 17:42 |
alee | atiwari, if stanislaw just wants to resubmit and reference back to the previous one so that folks can see the comments, that will be ok too. | 17:43 |
atiwari | ok | 17:44 |
alee | atiwari, but hopefully we can get some good discussion started on this prior to the summit | 17:44 |
atiwari | sure | 17:44 |
*** lisaclark1 has quit IRC | 17:49 | |
*** lisaclark1 has joined #openstack-barbican | 17:53 | |
*** dimtruck is now known as zz_dimtruck | 18:13 | |
openstackgerrit | Arvind Tiwari proposed a change to openstack/barbican-specs: Spec for certificate REST api addition https://review.openstack.org/129695 | 18:13 |
openstackgerrit | Arvind Tiwari proposed a change to openstack/barbican-specs: Spec for certificate REST api addition https://review.openstack.org/129695 | 18:17 |
*** arunkant has joined #openstack-barbican | 18:20 | |
atiwari | alee, fyi I have moved the spec to kilo and I will own it. | 18:22 |
alee | atiwari, fantastic -thanks | 18:23 |
openstackgerrit | Douglas Mendizábal proposed a change to openstack/python-barbicanclient: Refactored Client to use Keystone Sessions https://review.openstack.org/127862 | 18:28 |
openstackgerrit | Arvind Tiwari proposed a change to openstack/barbican-specs: Spec for certificate REST api addition https://review.openstack.org/129695 | 18:33 |
*** lisaclark1 has quit IRC | 18:41 | |
*** zz_dimtruck is now known as dimtruck | 18:43 | |
*** lisaclark1 has joined #openstack-barbican | 18:45 | |
rm_work | meeting is ... 3pm? or is it 2pm? | 18:52 |
rm_work | redrobot / woodster_ ^^ | 18:52 |
*** ametts has quit IRC | 18:52 | |
redrobot | rm_work 3pm CDT | 18:52 |
rm_work | kk | 18:52 |
*** tdink_ has joined #openstack-barbican | 18:55 | |
*** nkinder has quit IRC | 18:56 | |
*** tdink_ has quit IRC | 18:57 | |
*** tdink_ has joined #openstack-barbican | 18:58 | |
*** tdink has quit IRC | 18:58 | |
*** tdink_ has quit IRC | 19:03 | |
*** tdink has joined #openstack-barbican | 19:05 | |
*** tdink has quit IRC | 19:05 | |
*** kebray has quit IRC | 19:14 | |
*** dimtruck is now known as zz_dimtruck | 19:19 | |
*** zz_dimtruck is now known as dimtruck | 19:23 | |
*** kebray has joined #openstack-barbican | 19:29 | |
*** dimtruck is now known as zz_dimtruck | 19:37 | |
*** tdink has joined #openstack-barbican | 19:45 | |
*** zz_dimtruck is now known as dimtruck | 19:48 | |
*** kaitlin-farr has joined #openstack-barbican | 19:50 | |
*** kaitlin-farr has quit IRC | 19:54 | |
*** kaitlin-farr_ has joined #openstack-barbican | 19:54 | |
*** nkinder has joined #openstack-barbican | 19:57 | |
*** kaitlin-farr__ has joined #openstack-barbican | 19:58 | |
*** kaitlin-farr__ is now known as kaitlin-farr | 19:58 | |
*** kaitlin-farr_ has quit IRC | 19:59 | |
*** kaitlin-farr_ has joined #openstack-barbican | 19:59 | |
*** kaitlin-farr_ has quit IRC | 19:59 | |
*** kaitlin-farr__ has joined #openstack-barbican | 20:00 | |
redrobot | hey it's time for the weekly meeting on #openstack-meeting-alt | 20:01 |
*** kaitlin-farr has quit IRC | 20:03 | |
rm_work | gah | 20:24 |
rm_work | redrobot: just caught up, almost missed it again. this keymanager interface discussion is interesting and promising | 20:27 |
*** lisaclark1 has quit IRC | 20:33 | |
*** lisaclark1 has joined #openstack-barbican | 20:39 | |
*** gyee has joined #openstack-barbican | 20:45 | |
*** ametts has joined #openstack-barbican | 20:52 | |
*** jaosorior has quit IRC | 20:53 | |
*** hyakuhei has joined #openstack-barbican | 21:02 | |
*** tkelsey has joined #openstack-barbican | 21:02 | |
hyakuhei | To continue toe conversation, key-wrapping on HSM is part of the KMIP standard | 21:03 |
hyakuhei | 1.0 and 1.2 | 21:03 |
*** tdink_ has joined #openstack-barbican | 21:03 | |
alee | rellerreller, what I'm confused about -- and I have not looked at the CR really -- is - if the Atalla is so KMIP compliant - why tkelsey and hyakuhei can't use the kmip secret store plugin. | 21:03 |
tkelsey | alee: because KMIP was not part of Barbican at that point, well not implemented. Also libKMIP was not released when we started the work. | 21:04 |
rellerreller | alee We are using the KMIP appliance to store all of the keys in a KMIP server. My guess is they cannot store that many keys. They probably only want to store the KEKs in there. | 21:04 |
*** lisaclark1 has quit IRC | 21:05 | |
hyakuhei | rellerreller: Yes, we'd only want to store KEK | 21:05 |
rellerreller | hyakuhei: So your plan is store KEKs in KMIP. Then on retrieving a key you would retrieve KEK from KMIP, decrypt the wrapped DEK, and return to Barbican core? | 21:06 |
*** tdink has quit IRC | 21:07 | |
*** tdink_ has quit IRC | 21:07 | |
hyakuhei | Our ideal solution would create and store KEK in HSM via KMIP. Wrapping/Unwrapping of DEK done on HSM | 21:07 |
tkelsey | rellerreller: yes, the key (un)wrapping would be done on the HSM ideally. However the details still need to be worked out :) | 21:08 |
atiwari | hyakuhei, what is difference between DEK and KEK? | 21:08 |
hyakuhei | DEK - Data Encryption Key (That which encrypts things in OpenStack) | 21:08 |
hyakuhei | KEK - Key Encryption Key - used to protect DEKs | 21:08 |
atiwari | hyakuhei, DEK is the actual secret? | 21:09 |
rellerreller | So you really want an HSM that is also KMIP compliant? | 21:09 |
hyakuhei | rellerreller: Don't we all? | 21:09 |
hyakuhei | In fact our HSMs are | 21:09 |
rellerreller | hyakuhei haha :) Good point! | 21:09 |
hyakuhei | _very_ KMIP compliant - however we felt that KMIP support in OpenStack was going to take a while to land / become stable | 21:10 |
hyakuhei | after all, the pykmip library was only release a month ago right ? | 21:10 |
rellerreller | Ya, something like that | 21:10 |
hyakuhei | So we went ahead and built something that used the much simpler (if less capable) xml interface that the ESKM exposes with the intention to use that immediately and work to support/stabilse KMIP at which point we'd migrate over | 21:11 |
alee | tkelsey, hyakuhei and there is some api call in KMIP that allows you to send the encrypted DEK to the HSM , unencrypt with the KEK - and return the unwrapped DEK? | 21:12 |
alee | just trying to understand what the end-state would be .. | 21:12 |
hyakuhei | alee: that's my understanding yeah | 21:13 |
atiwari | hyakuhei, in this pkcs#11 plugin implemented by Paul https://review.openstack.org/#/c/107775/4/specs/juno/restructure-pkcs11-plugin.rst KEKs and DEK are stored locally and propagated to HSM as per need. | 21:13 |
tkelsey | atiwari: the KEK is sent _to_ the HSM ?? | 21:14 |
hyakuhei | That's the mode of operation that's just been -1'd for our plugin. | 21:14 |
hyakuhei | tkelsey: atiwari basically that's just using the HSM as a secure file store | 21:14 |
hyakuhei | A fips-140.3 data store | 21:14 |
tkelsey | ah ok | 21:14 |
atiwari | tkelsey, hyakuhei that is the pattern to overcome the HSM storage issues. | 21:15 |
hyakuhei | or a fileserver with epoxy resin slathered all over it, to use the full fips definitiion | 21:15 |
atiwari | IMO | 21:15 |
hyakuhei | atiwari: no it isn't | 21:15 |
tkelsey | hyakuhei: lol | 21:15 |
hyakuhei | HSM handling KEK will scale to several million keys | 21:15 |
hyakuhei | while guarenteeing that even massive compromises of Barbican core will have only limited key impact | 21:16 |
hyakuhei | and the audit stream of the HSM can reveal exactly what keymat may have been compromised | 21:16 |
hyakuhei | When Barbican core handles KEK and DEK you're basically screwed | 21:16 |
tkelsey | with the DEK stored locally and wrapped by a KEK the number of keys should be within capacity for a HSM. | 21:16 |
tkelsey | hyakuhei: +1 for sure | 21:17 |
hyakuhei | A system with any scale will end up keeping some notional MKEK always in memory | 21:17 |
hyakuhei | Now what I don't know about KMIP is if it supports the notion of multiple clusters if if that'd be a metadata issue | 21:17 |
hyakuhei | i.e if there are smaller HSMs, lets say they support only a few hundred keys | 21:18 |
hyakuhei | then in that case you'd need a smart way to scale. My preferred way to do that would be to buy more ESKM | 21:18 |
hyakuhei | s/ESKM/HSM | 21:18 |
hyakuhei | So if you have multiple HSM how does Barbican know which one to retrieve keymaterial from? | 21:18 |
hyakuhei | Probably need to store something with the KEK(DEK) that tells Barbican where the KEK is stored | 21:19 |
tkelsey | hyakuhei: interesting, guess you would need somthing in the metadata for that | 21:19 |
hyakuhei | yeh | 21:19 |
rellerreller | I agree | 21:20 |
-openstackstatus- NOTICE: Zuul erroneously marked some changes as having merge conflicts. Those changes have been added to the check queue to be rechecked and will be automatically updated when complete. | 21:20 | |
*** lisaclark1 has joined #openstack-barbican | 21:21 | |
hyakuhei | Is that something we want to add sooner rather than later? KMIP endpoint or something similar? I'm unfamiliar with HSM clustering and KMIP | 21:22 |
alee | hyakuhei, tkelsey - you might want to see if the atalla supports pkcs11 -- this problem of encrypting/decrypting on the hsm has been solved there. | 21:23 |
hyakuhei | alee: It may do, but my feeling is that KMIP support is where interopability with HSMs is going | 21:24 |
hyakuhei | Well, mine and the rest of the crypto industry ;) | 21:24 |
hyakuhei | You'll see less pkcs11 in the future I'd imagine, so if anything I think we should be looking to help develop KMIP | 21:25 |
hyakuhei | erm | 21:25 |
hyakuhei | Develop pykmip | 21:25 |
tkelsey | hyakuhei: +1 | 21:25 |
hyakuhei | The standard supports keywrapping and the devices do | 21:25 |
hyakuhei | I think the library needs work to support it | 21:25 |
hyakuhei | and then the plugin for Barbican needs developing | 21:25 |
hyakuhei | which brings us back around to our interim ESKM plugin | 21:26 |
rellerreller | hyakuhei +1 for develop pykmip! | 21:26 |
tkelsey | yeah, KMIP is future looking, the plugin works with whats available right now | 21:26 |
alee | hyakuhei, fair enough - but it depends on your time scale. You may be able to put together a more secure solution using pkcs11 before the kmip library is where you need it to be. | 21:26 |
alee | hyakuhei, tkelsey - if your customers will be happy with the interim plugin , then ok .. | 21:27 |
hyakuhei | alee potentially yes, difference between offloaded .vs. local wrapping is that local is succiptible to comrpomise through info leakage | 21:28 |
alee | but most folks who care about this may not look at having the kek in memory favorably | 21:28 |
hyakuhei | It's not the best way to do things, I think we're all agreed on that | 21:28 |
hyakuhei | However, it's significantly better than doing _everything_ locally | 21:29 |
alee | I know it would be a non-starter for most of our customers. | 21:29 |
hyakuhei | Well, Barbican as a whole would be in it's current tate | 21:29 |
hyakuhei | *state | 21:29 |
hyakuhei | It's all about moving things forward | 21:30 |
alee | yup | 21:30 |
tkelsey | hyakuhei alee +1 moving forward | 21:30 |
tkelsey | this is a very interesting discussion but I have to log here, very good points from all though! | 21:31 |
hyakuhei | +1, late o'clock in the UK | 21:31 |
hyakuhei | Thanks for the discussion alee, rellerreller | 21:31 |
tkelsey | hyakuhei: heh yeah. yeah rellerreller alee good input! | 21:31 |
woodster_ | lots of discussion here I'm catching up on, but regarding the current pkcs11 plugin that reaperhulk developed (here: https://github.com/openstack/barbican/blob/master/barbican/plugin/crypto/p11_crypto.py) it works with a single MEK stored in the HSM, to wrap per-project KEKs. Only the MEK is stored in the HSM, with per-project KEKs wrapped by the MEK stored | 21:36 |
woodster_ | in barbican. All encrypt decrypt operations happen on the HSM. He HMACs the wrapped KEKs for further integrity. | 21:36 |
woodster_ | so it sounds like KMIP would support similar functionality? | 21:37 |
hyakuhei | Thanks woodster_ I'll take a closer look at that | 21:37 |
hyakuhei | fundamentally I think we need to add wrapping support to the KMIP libraries and then use that in a Barbican plugin | 21:37 |
hyakuhei | The real discussion is around what happens in the meantime | 21:38 |
hyakuhei | Anyway I gotta drop, I'll try to come back to discuss more in the next day or two. | 21:38 |
*** tkelsey has quit IRC | 21:38 | |
woodster_ | hyakuhei, so it looks like that code is handling the encrypt/decrypt itself, but it's really working with either handles to the HSM-internal KEKs, or else 'extracted' but HSM-encrypted KEKs. So either way, only the HSM itself ever sees unencrypted KEKs | 21:39 |
woodster_ | tkelsey: ^^^^ | 21:39 |
hyakuhei | Thanks woodster_ :) | 21:40 |
*** openstackgerrit has quit IRC | 21:40 | |
woodster_ | hyakuhei, good discussions! | 21:41 |
*** ametts has quit IRC | 21:41 | |
*** tdink has joined #openstack-barbican | 21:51 | |
*** paul_glass has quit IRC | 21:54 | |
*** lisaclark1 has quit IRC | 22:01 | |
*** rellerreller has quit IRC | 22:08 | |
*** SheenaG11 has joined #openstack-barbican | 22:12 | |
*** kaitlin-farr__ has quit IRC | 22:13 | |
*** SheenaG1 has quit IRC | 22:14 | |
*** dimtruck is now known as zz_dimtruck | 22:18 | |
*** zz_dimtruck is now known as dimtruck | 22:20 | |
*** openstackgerrit has joined #openstack-barbican | 22:43 | |
*** atiwari has quit IRC | 23:02 | |
*** dimtruck is now known as zz_dimtruck | 23:16 | |
*** kgriffs is now known as kgriffs|afk | 23:31 | |
*** rm_you| has quit IRC | 23:43 | |
*** gyee has quit IRC | 23:51 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!