| *** DCWillia_ has quit IRC | 00:02 | |
| *** SheenaG has quit IRC | 00:04 | |
| *** rm_work is now known as rm_work|away | 00:35 | |
| *** everjeje has quit IRC | 00:36 | |
| *** DCWilliams_VA has joined #openstack-barbican | 00:40 | |
| *** shakamunyi has quit IRC | 01:02 | |
| *** kebray has joined #openstack-barbican | 01:10 | |
| *** kebray has quit IRC | 01:10 | |
| *** kebray has joined #openstack-barbican | 01:11 | |
| *** DCWilliams_VA has quit IRC | 01:12 | |
| *** kebray has quit IRC | 01:16 | |
| *** kebray has joined #openstack-barbican | 01:16 | |
| *** shakamunyi has joined #openstack-barbican | 02:10 | |
| *** crc32 has quit IRC | 02:30 | |
| *** kebray has quit IRC | 02:47 | |
| openstackgerrit | Dave McCowan proposed openstack/barbican: Add Multi-user support and ACL coverage in Functional Tests https://review.openstack.org/176615 | 03:22 |
|---|---|---|
| *** dave-mccowan has quit IRC | 04:24 | |
| *** woodster_ has quit IRC | 05:30 | |
| openstackgerrit | Arun Kant proposed openstack/barbican: Removed per ACL operations and added support for PUT method. https://review.openstack.org/180888 | 06:55 |
| *** everjeje has joined #openstack-barbican | 06:58 | |
| *** rm_work|away is now known as rm_work | 07:07 | |
| *** nickrmc83 has joined #openstack-barbican | 07:34 | |
| *** darrenmoffat has quit IRC | 10:06 | |
| *** darrenmoffat has joined #openstack-barbican | 10:12 | |
| *** woodster_ has joined #openstack-barbican | 11:46 | |
| *** jaosorior has joined #openstack-barbican | 11:52 | |
| *** openstackgerrit has quit IRC | 11:52 | |
| *** openstackgerrit has joined #openstack-barbican | 11:52 | |
| therve | Hi all | 12:01 |
| therve | I noticed that the default policy is to only allow admins to do secret:delete | 12:01 |
| therve | What's the reasoning behind not allowing creator? | 12:01 |
| jaosorior | therve: probably arunkant would be able to answer that question | 12:05 |
| therve | Cool :) | 12:05 |
| jaosorior | and I think he's in US timezone so he will hopefully be online soon | 12:05 |
| therve | jaosorior, Unrelated, but do you have any feedback on https://review.openstack.org/#/c/179397/ ? | 12:06 |
| jaosorior | actually I was about to start reviewing | 12:06 |
| jaosorior | let me take a look | 12:06 |
| therve | Sweet | 12:06 |
| jaosorior | uhm... | 12:07 |
| jaosorior | I guess to be able to properly test that, we would need your other CR to land, right? | 12:07 |
| jaosorior | well, to properly test it in the gate | 12:08 |
| jaosorior | meaning, this: https://review.openstack.org/#/c/179374/ | 12:08 |
| therve | I don't think that patch changes the gate situation | 12:20 |
| therve | It helps testing in devstack, though | 12:21 |
| *** dave-mccowan has joined #openstack-barbican | 12:24 | |
| jaosorior | which I would like | 12:26 |
| jaosorior | I'll check that first | 12:26 |
| woodster_ | jaosorior: Ozz can you look at https://review.openstack.org/#/c/178479? | 12:51 |
| jaosorior | woodster_: sure | 12:51 |
| jaosorior | therve: ping | 12:52 |
| jaosorior | woodster_: ping | 13:05 |
| *** nkinder has quit IRC | 13:14 | |
| *** david-lyle has quit IRC | 13:19 | |
| therve | jaosorior, Yep! Sorry was away | 13:24 |
| *** openstackstatus has quit IRC | 13:25 | |
| *** openstackstatus has joined #openstack-barbican | 13:25 | |
| *** ChanServ sets mode: +v openstackstatus | 13:25 | |
| jaosorior | therve: no problem | 13:27 |
| jaosorior | therve: can you add some placeholder to the config for the snakeoil configuration options in the etc/barbican/barbican-api.conf? I was initially gonna discuss testing, since I would like to have the snakeoil ca plugin tested in the gate, but then I figured that it's better to either discuss it in the summit, or just do it at some point | 13:32 |
| therve | jaosorior, I believe you only need to set the enabled_certificate_plugins option | 13:33 |
| therve | default values of the snakeoild_ca plugin should work | 13:33 |
| therve | Ah you need to set the values to something though | 13:34 |
| jaosorior | yup | 13:34 |
| jaosorior | and there are no default values set in the config file | 13:35 |
| jaosorior | so, it would be nice if as part of the fix, if you want, you could add those | 13:35 |
| jaosorior | just thought it would fit the CR | 13:35 |
| therve | Definitely | 13:37 |
| jaosorior | therve: thanks man | 13:38 |
| *** joesavak has joined #openstack-barbican | 13:39 | |
| *** chlong has joined #openstack-barbican | 13:39 | |
| openstackgerrit | Thomas Herve proposed openstack/barbican: Fix snakeoil_ca plugin https://review.openstack.org/179374 | 13:42 |
| therve | jaosorior, ^^^ | 13:42 |
| jaosorior | therve: checked | 13:51 |
| *** jamielennox is now known as jamielennox|away | 13:51 | |
| *** pglass has joined #openstack-barbican | 14:05 | |
| *** nkinder has joined #openstack-barbican | 14:08 | |
| woodster_ | jaosorior: I'm back | 14:23 |
| *** rellerreller has joined #openstack-barbican | 14:32 | |
| openstackgerrit | Dave McCowan proposed openstack/barbican: Add Multi-user support and ACL coverage in Functional Tests https://review.openstack.org/176615 | 14:33 |
| openstackgerrit | Juan Antonio Osorio Robles proposed openstack/barbican: Add project_id to Secret model https://review.openstack.org/181025 | 14:46 |
| openstackgerrit | Thomas Herve proposed openstack/barbican: Fix snakeoil_ca plugin https://review.openstack.org/179374 | 14:47 |
| therve | jaosorior, So I removed those values. You actually don't need them to test the plugin | 14:48 |
| therve | (And the tests failed in a weird way that I couldn't reproduce) | 14:48 |
| jaosorior | you don't need them to test the plugin, but it would have been nice to have them (even if commented) just for documentation | 14:48 |
| jaosorior | anyway, that's alright | 14:48 |
| therve | Yeah... | 14:49 |
| therve | I'm really wondering what's happening in the gate for those files to be loaded | 14:49 |
| openstackgerrit | Juan Antonio Osorio Robles proposed openstack/barbican-specs: Move data-remove-tenant-secret-assoc to Liberty https://review.openstack.org/181026 | 14:51 |
| *** jsavak has joined #openstack-barbican | 14:53 | |
| jaosorior | woodster_: where's the etherpad for the liberty summit? | 14:53 |
| woodster_ | jaosorior: Here it is: https://etherpad.openstack.org/p/barbican-L-design-sessions | 14:54 |
| jaosorior | and, do you think it's valuable to talk about adding tests for the snakeoil plugin to the functionaltests or should that just be done? | 14:54 |
| woodster_ | jaosorior: it's fair game to talk about testing anything in our repository I figure. Please add to the list..I think there is some other testing related things out there too | 14:55 |
| *** joesavak has quit IRC | 14:55 | |
| *** joesavak has joined #openstack-barbican | 14:56 | |
| woodster_ | jaosorior: it seems we do need a way to select from multiple cert plugins in our testing. The ca_id work alee_ and others have done helps out with that | 14:56 |
| woodster_ | hockeynut: tdink ^^^^ | 14:57 |
| *** darrenmoffat has left #openstack-barbican | 14:57 | |
| hockeynut | woodster_ yep, we don't play with any of that...yet | 14:57 |
| *** jsavak has quit IRC | 14:58 | |
| *** xaeth_afk is now known as xaeth | 15:01 | |
| jaosorior | we don't, and we should :O | 15:12 |
| *** kebray has joined #openstack-barbican | 15:12 | |
| *** SheenaG has joined #openstack-barbican | 15:22 | |
| *** igueths has joined #openstack-barbican | 15:34 | |
| *** rm_work is now known as rm_work|away | 15:40 | |
| *** nelsnelson has joined #openstack-barbican | 15:41 | |
| *** tkelsey has joined #openstack-barbican | 15:47 | |
| tkelsey | hey Barbican folks, can I just check what the status of certificates is in Kilo ? | 15:48 |
| hockeynut | barbicaneers - looking for some review on two functional test CRs: https://review.openstack.org/#/c/179609/ and https://review.openstack.org/#/c/179659/ | 15:49 |
| *** nickrmc83 has quit IRC | 15:50 | |
| *** jsavak has joined #openstack-barbican | 16:05 | |
| *** joesavak has quit IRC | 16:08 | |
| *** rm_work|away is now known as rm_work | 16:13 | |
| openstackgerrit | John Wood proposed openstack/barbican: Port the Architecture, Dataflow, and Project Strucure docs https://review.openstack.org/132304 | 16:21 |
| *** joesavak has joined #openstack-barbican | 16:23 | |
| *** jsavak has quit IRC | 16:26 | |
| *** shakamunyi has quit IRC | 16:29 | |
| kragniz | heads up, folk, we're looking at getting barbican and glance together :) | 16:31 |
| kragniz | https://etherpad.openstack.org/p/liberty-glance-image-signing-and-encryption | 16:31 |
| redrobot | kragniz \o/ | 16:31 |
| kragniz | I should finish off those oslo CRs... | 16:32 |
| *** rm_work is now known as rm_work|away | 16:32 | |
| woodster_ | tkelsey: Ade (alee_) has done a lot of work with Dogtag for certs in Kilo. Thomas (therve) has done work with a snake-oil plugin, good for demo/local-dev work. I've added a dev-mode retry functionality that can support development of extended workflows with CAs to generate certs. | 16:41 |
| chellygel | hey redrobot / jvrbanac re: https://review.openstack.org/#/c/179155/ pragma no cover only removes coverage for line 280, not for 281 -- so i still only see 98%. Should i leave it as an exclude in the RC or should i add pragma no cover twice? also on line 281? | 16:41 |
| tkelsey | woodster_: ok thanks for the info, so we can request certs through Barbican and hit one of the available plugins? | 16:43 |
| woodster_ | tkelsey: you would need to configure things from the default/out-of-the-box configs to make things work. Are you interested in the Dogtag CA plugin or the snakeoil one? | 16:44 |
| tkelsey | either, I'm just interested in where things are with it in general :) | 16:45 |
| tkelsey | is there a document some place with details of how to kick the tires with the snake oil CA ? | 16:47 |
| tkelsey | than i can go RTFM :) | 16:48 |
| woodster_ | tkelsey: unfortunately docs have not caught up to the relatively new features. alee_, therve or jaosorior can you guys provide more guidance on setting up these features? | 16:57 |
| woodster_ | tkelsey: in fact, therve has a CR up to fix the snakeoil plugin: https://review.openstack.org/#/c/179374/ | 16:58 |
| tkelsey | thanks woodster_ I'll take a look | 16:58 |
| openstackgerrit | Dave McCowan proposed openstack/barbican: Refactor Stored Key Certificate Order Validator Code https://review.openstack.org/171023 | 16:59 |
| *** joesavak has quit IRC | 17:03 | |
| woodster_ | tkelsey: That CR looks complete (i.e. you could probably pull it down and play with it), except that I noticed that the barbican configs for it were removed (patch 4 has them, the latest doesn't) which you would need to run this locally I believe. | 17:04 |
| *** crc32 has joined #openstack-barbican | 17:05 | |
| tkelsey | ok woodster_ thanks :) | 17:06 |
| *** crc32 has quit IRC | 17:06 | |
| *** joesavak has joined #openstack-barbican | 17:07 | |
| woodster_ | elmiko: thanks for the assist in the api-wg meeting...I didn't know if they were going to have a general topics part at the end or not | 17:15 |
| elmiko | woodster_: np =) | 17:15 |
| openstackgerrit | Chelsea Winfree proposed openstack/python-barbicanclient: Adding new tests to cover failure scenarios https://review.openstack.org/179155 | 17:29 |
| *** crc32 has joined #openstack-barbican | 17:32 | |
| *** rellerreller has quit IRC | 17:32 | |
| *** rellerreller has joined #openstack-barbican | 17:35 | |
| *** notmyname has joined #openstack-barbican | 17:36 | |
| notmyname | hmm..this looks like the right place | 17:36 |
| notmyname | Sheena_: SheenaG: ping | 17:36 |
| notmyname | I'm looking at the barbican panel slides now | 17:36 |
| SheenaG | notmyname: pong | 17:37 |
| SheenaG | notmyname: welcome to the room! You've made it! | 17:37 |
| notmyname | :-) | 17:37 |
| notmyname | well, more like I finally made it to looking at this particular summit thing :-) | 17:38 |
| SheenaG | notmyname: that's a way bigger congratulations | 17:38 |
| SheenaG | notmyname: I'm positive that diagram I made is totally wrong - just let me know what to change and I'll get it fixed, you're welcome to amend the deck directly | 17:38 |
| notmyname | so now we gotta whip the swift part into shape :-) | 17:38 |
| notmyname | yeah, it is kinda totally wrong | 17:39 |
| SheenaG | notmyname: hahahahahaha | 17:39 |
| SheenaG | notmyname: I figured. I was having a terrible time translating it, I'm sorry. I did rm_work|away's from a scribble, I thought I could do anything | 17:39 |
| SheenaG | notmyname: I learned my lesson | 17:40 |
| SheenaG | notmyname: also, could you send me your availability/unavailability for next week? I want to schedule our first run through today if possible, before peoples' schedules fill up | 17:41 |
| notmyname | lol | 17:41 |
| notmyname | I've got one or two things on the calendar that week ;-) http://d.not.mn/summit_cal.png | 17:42 |
| notmyname | sunday afternoon would be great | 17:43 |
| SheenaG | I'm only seeing the summit calendar - is next week (before the summit) nuts too? | 17:43 |
| SheenaG | I see "herding" - I hope that's "herding cats" | 17:43 |
| notmyname | ah, ok. next week | 17:43 |
| notmyname | much easier next week :-) | 17:43 |
| SheenaG | Human Genome Sequencing? | 17:44 |
| SheenaG | Your calendar is so much cooler than mine. | 17:44 |
| notmyname | yeah, it's really cool. Swift is integrated into some of the gene sequencers so they can dump directly to swift http://libertydesignsummit.sched.org/event/249e7b5816d7d00b1ac1fe9f24a78845#.VUukmc4msyw | 17:45 |
| *** anteaya has quit IRC | 17:45 | |
| SheenaG | That's awesome. | 17:45 |
| SheenaG | Adding to my talks to attend... | 17:46 |
| notmyname | also, you might suspect why "encryption" is getting some attention in swift ;-) | 17:46 |
| *** everjeje has quit IRC | 17:46 | |
| SheenaG | It certainly makes intuitive sense | 17:47 |
| notmyname | so, yeah, next weeks is pretty open. wednesday pm I have the hardest time | 17:47 |
| notmyname | also, I'm in pacific time zone, so I can generally do later (if you're in central) | 17:47 |
| SheenaG | I'm in Mountain View, CA right now - so I'm on your time | 17:48 |
| notmyname | oh cool | 17:48 |
| SheenaG | I'll see about scheduling Tuesday or Thursday - it looks like either of those work for the other attendees. | 17:48 |
| SheenaG | Maybe both if I can - I'd like to do two full walkthroughs before the actual conference if possible | 17:49 |
| notmyname | Sheena_: yeah, tuesday or wed are ok. wednesday is a little tricky, but not too back | 17:54 |
| notmyname | SheenaG: shall we go over the swift slide now? | 17:56 |
| SheenaG | notmyname: I'm in a meeting for another 4 minutes, but can chat immediately following | 17:56 |
| *** arunkant_ has joined #openstack-barbican | 17:56 | |
| notmyname | ok | 17:56 |
| notmyname | hmm..looking at the diagram again, it's actually not too bad | 18:01 |
| SheenaG | notmyname: don't try to make me feel better about my hideous diagram | 18:01 |
| notmyname | the order if the columns isn't what I was expecting, but overall it's close to what actually happens | 18:01 |
| SheenaG | notmyname: I can take the criticism | 18:01 |
| SheenaG | notmyname: haha - do you want to chat on here or do Hangouts for review? | 18:02 |
| notmyname | well, the column order is not what I was expecting, and there's one part missing, but that missing part isn't too far off from the functional things that are shown | 18:02 |
| notmyname | your call | 18:02 |
| notmyname | hangouts might be better. higher bandwidth communication gets things done faster | 18:02 |
| SheenaG | True - I'll send you a link | 18:03 |
| notmyname | ok | 18:03 |
| jaosorior | woodster_: sorry for the late reply, was in the forest haha. Sure tomorrow I can see if I can answer tkelsey ' s questions | 18:25 |
| *** jsavak has joined #openstack-barbican | 18:35 | |
| openstackgerrit | Chelsea Winfree proposed openstack/python-barbicanclient: Adding new tests to cover failure scenarios https://review.openstack.org/179155 | 18:36 |
| notmyname | I tagged the 2 swift design sessions on encryption with babican, so you should see it in your schedule too | 18:37 |
| SheenaG | Nice, thanks notmyname | 18:37 |
| notmyname | hmmm...looks like there might be a conflict | 18:37 |
| notmyname | http://libertydesignsummit.sched.org/type/design+summit/barbican#.VUuw6s4msyw | 18:37 |
| notmyname | I'll see what I can do | 18:37 |
| *** joesavak has quit IRC | 18:39 | |
| *** joesavak has joined #openstack-barbican | 18:39 | |
| *** jsavak has quit IRC | 18:41 | |
| *** jsavak has joined #openstack-barbican | 18:41 | |
| *** tkelsey has quit IRC | 18:43 | |
| *** joesavak has quit IRC | 18:45 | |
| *** rm_work|away is now known as rm_work | 18:52 | |
| *** joesavak has joined #openstack-barbican | 19:02 | |
| rm_work | SheenaG: hey, my "scribble" was beautiful, not my fault you don't appreciate art when you see it :P | 19:02 |
| *** jsavak has quit IRC | 19:03 | |
| SheenaG | rm_work: and you wonder why people call you crazy | 19:05 |
| rm_work | pfft | 19:07 |
| rm_work | people call me crazy because when people observe brilliance outside their level of understanding, they ascribe it to insanity | 19:08 |
| elmiko | lol | 19:09 |
| rm_work | :P | 19:09 |
| notmyname | out of curiosity, how much should I worry about barbican storing/managing a few million keys? or more | 19:23 |
| elmiko | good question, it's using sqlalchemy, so i imagine as long as you have faith in your db it would be ok. not sure about the scale of retrieving those keys, depending on density. | 19:26 |
| rm_work | I think in production it would use MySQL or such usually? | 19:29 |
| rm_work | so really it's that | 19:29 |
| rm_work | err, sorry yeah misread that statement, elmiko is correct :P | 19:29 |
| elmiko | yea i wouldn't be worried about the mysql or postgresql db, i'd be more worried about the density of calls to the server. but that might not be an issue either. | 19:30 |
| redrobot | notmyname should be fine if using a backend that leverages the Database. The KMIP plugin, for example would be limited by the storage space in your KMIP device. | 19:31 |
| elmiko | has anyone ever brought up HA barbican? | 19:31 |
| notmyname | redrobot: at what point will I see problems? what if I need to store a billion keys? | 19:31 |
| redrobot | notmyname depends on hardware choice. there's two classes of storage backends: Those that use the DB for storage, and those that use an external device for storage. In both cases you'll be limited by the actual space, but the DB storage is much easier to scale. | 19:34 |
| notmyname | single machine? single drive? | 19:34 |
| notmyname | I'm curious from a deployment perspective | 19:34 |
| notmyname | in a few months when I have swift+barbican and I want to encrypt all the things, I'll need to store a _lot_ of keys | 19:35 |
| notmyname | so if I have a million container, get a new key per container per month, and store it for a few years, I've got a pretty large key cardinality | 19:35 |
| notmyname | so I'm curious if that's just not suitable at this point (ie keep problem scope and cluster size down) or if the answer is "sure, np. just add some more boxes" | 19:36 |
| notmyname | so if eg bank of america uses swift+barbican to encrypt every customer record they store, is that reasonable or not | 19:37 |
| * notmyname doesn't know if BoA uses swift or not, but it's reasonable (and they should!) | 19:37 | |
| redrobot | we're limiting key size to be very small | 19:37 |
| *** tkelsey has joined #openstack-barbican | 19:38 | |
| redrobot | the reference limit is 10kb | 19:38 |
| notmyname | size of the key or cardinality of the keys? | 19:38 |
| redrobot | so 1 billion keys at 10kb ~ 10 TB for storage | 19:38 |
| notmyname | what does that mean? what's a reference limit? | 19:38 |
| notmyname | ok | 19:38 |
| redrobot | limit is configurable | 19:38 |
| redrobot | but we're recommending small limits so people don't use Barbican as the "encrypted swift" :) | 19:39 |
| notmyname | :-) | 19:39 |
| notmyname | that's what swift is for! | 19:39 |
| notmyname | how is that storage done? all in one place? in a DB that is/can be sharded? something else that's more horizontally scalable? | 19:40 |
| notmyname | hmm...maybe I'm thinking of something different for "key" than you are | 19:40 |
| redrobot | notmyname so the storage depends on the backend choice. | 19:40 |
| notmyname | I'm thinking of the key that's used to do the encypt/decrypt | 19:40 |
| notmyname | what are the backend options? | 19:40 |
| redrobot | so you need to choose a "Secret Store". Current choices are DB+PCKS#11 device, or KMIP device, or DogTag | 19:41 |
| notmyname | clearly, /me hasn't read much on barbican's implementation ;-) | 19:41 |
| *** tkelsey has quit IRC | 19:42 | |
| redrobot | so for the DB+PCKS#11 backend, we provision an data-encryption-key for the project/tenant, which we call the KEK | 19:42 |
| redrobot | the KEK is encrypted in the PKCS#11 device with a Master Key | 19:42 |
| redrobot | the Master Key never leaves the PCKS#11 device | 19:43 |
| redrobot | the KEK is stored in the DB after it's encrypted | 19:43 |
| redrobot | when a user sends us a "secret" (for your case, probably one of the billion keys you're using to encrypt things) | 19:43 |
| redrobot | we retrieve the encrypted KEK | 19:44 |
| redrobot | send it to the PKCS11 device | 19:44 |
| woodster_ | notmyname: yep, so the HSM is not storing much data at all | 19:44 |
| redrobot | decrypt it with the master key, leave KEK in-memory | 19:44 |
| redrobot | then send the "secret" to be encrypted with the KEK. | 19:44 |
| redrobot | and we store the now-encrypted secret in DB | 19:44 |
| notmyname | hmm | 19:45 |
| redrobot | the other two backends are different in that they store both the KEK and "secret" in the external device. | 19:45 |
| redrobot | and dedicated security devices won't scale like a DB does. So for super high storage requirements, you definitely want to use the DB storage | 19:46 |
| notmyname | so my understanding is that there is the "key" that is used to encrypt/decrypt and it has a key_id. so swift sends a request to barbican for the key associated with a particular key_id and then uses that to decrypt the data | 19:46 |
| redrobot | notmyname yep, "key" for you is "secret" for us | 19:46 |
| notmyname | and on the initial write, swift sends *something* to barbican to get a new key and key_id. swift encrypts with the key and stores the key_id | 19:46 |
| notmyname | ok | 19:46 |
| redrobot | notmyname so, if you want Barbican to provision the "key" you will use, then you send us an Order | 19:48 |
| notmyname | so swift asks for either a new secrect/id pair or the secret associated with an ID | 19:48 |
| notmyname | ok | 19:48 |
| notmyname | and what's in an order? | 19:48 |
| redrobot | notmyname all the metadata we need to generate an appropriate key. So if you want to do symmetric encryption, you would tell us that you want to do AES-256-CBC for example. | 19:49 |
| redrobot | then barbican provisions the key, and creates a new "secret" | 19:49 |
| redrobot | so you send Order, and get an Order ID. Once the Order is processed, you can use the Order ID to retrieve the Secret ID for the secret that was created. | 19:50 |
| notmyname | how about I send you an ID of my own choosing and you send back the secret for that or a new secret for it? | 19:50 |
| redrobot | with the Secret ID you can get the key back to do your encryption. | 19:50 |
| notmyname | so orders are async? I wonder how that will/can work with something that's in the read/write data path | 19:51 |
| redrobot | notmyname you'd get an existing key back, or a 404. | 19:51 |
| redrobot | notmyname orders are async because some secrets take a long time to provision e.g. x509 cert from a CA | 19:52 |
| notmyname | ah, so if I get a 404 then I make a new connection with an order? | 19:52 |
| woodster_ | notmyname: you can give the secret a name of your choosing, and then search by that name later if that's what you mean? | 19:52 |
| notmyname | woodster_: yeah, that sounds good | 19:52 |
| chellygel | stepping away, need to get some paperwork finished for my trip. will be back | 19:53 |
| notmyname | I'm thinking of a unique key per (account, container, month) tuple. I'll send that to barbican asking for a key | 19:53 |
| redrobot | notmyname yep. secret IDs include a UUID. They'll 404 if the uuid doesn't exist, and they will also 404 if you set an expiration date that has past. | 19:54 |
| notmyname | it would be _really_ nice if I could have a key created and returned if it didn't already exist. my secrets will _never_ expire, and they will all be symetric | 19:54 |
| notmyname | oh, and I need to handle 10-15K of these every second (which is why the extra http connection is bad for me) ;-) | 19:55 |
| redrobot | notmyname you could achieve that by setting the "name" on your secret to be "account-container-month", and then filter your secrets by that name. You'll either get one or more secrets that match, or an empty list. | 19:55 |
| redrobot | notmyname hehe, yeah, that's a lot of keys | 19:56 |
| notmyname | :-) | 19:56 |
| notmyname | well, I know steady-state swift clusters today doing around that much traffic. so actually that's a lower bound ;-) | 19:56 |
| notmyname | redrobot: thanks for the info. it sounds like, for now, most of the functionality is there. and the appropriate scale is yet to be tested. lots of variables | 19:58 |
| * notmyname would still really like the equiv of INSERTORUPDATE to avoid extra http requests | 19:59 | |
| elmiko | 10-15k a second, that's awesome =) | 19:59 |
| notmyname | I guess in this case it's a get_key_or_create_if_it_doesnt_exist() | 19:59 |
| rm_work | notmyname: that'd require an order to be created, not sure that's SUPER feasible | 20:00 |
| rm_work | since orders are async | 20:00 |
| notmyname | rm_work: even if the scope is limited to a secret that doesn't expire, has one kind of algo, and is symetric? | 20:01 |
| rm_work | notmyname: all generation of secrets is via Orders, and all Orders are async, at the moment | 20:02 |
| rm_work | redrobot: ^^ confirm? | 20:02 |
| notmyname | actually, why do you need the algorithm? I need a symetric key to use, and of course that needs to be big enough for the algo, but I'll be doing the actual encryption | 20:03 |
| notmyname | we're using aes-256 in ctr mode | 20:03 |
| woodster_ | rm_work: that's correct. 10-15k generation / second is a very high rate. The HSMs are a major bottleneck to all of this. They have limited memory, and since we store a enryption key per project, we can only store the MKEK in the HSM and then decrypt/unwrap that project KEK for each secret operation. That is several hops to the HSM to decrypt and encrypt | 20:05 |
| woodster_ | secrets (or your data encryption keys). | 20:05 |
| redrobot | notmyname we only really need the bit_length to provision a correct key in this case. We ask for algorithm and mode as metadata, in the event that sometime in the future you change the algorithm/mode you can use the metadata with the key to remember what you were doing with it. rm_work is right though, currently all provisioning is async. | 20:05 |
| woodster_ | notmyname: so if you need to create this many unique secrets per second I think that will be a challenge. We would need to ask the HSM to generate the secret/DEK, then have it unwrap the secret's project KEK, then encrypt the secret with that project KEK, then store that secret along with its cypher text. The reverse process is needed when the secret is | 20:07 |
| woodster_ | decrypted | 20:07 |
| *** chadlung has joined #openstack-barbican | 20:11 | |
| hockeynut | dave-mccowan ping | 20:19 |
| dave-mccowan | hockeynut pong | 20:19 |
| notmyname | woodster_: rm_work: thanks for the info | 20:20 |
| hockeynut | dave-mccowan looking at the acl user/multiuser CR | 20:20 |
| hockeynut | can we break that up into 2? one for just multiuser and then one for acl? | 20:20 |
| notmyname | woodster_: rm_work: also, this is ongoing work in swift right now. not something that is at all finished. there's a lot to do in swift beyond talking to barbican | 20:20 |
| notmyname | good stuff to think about over the next few months | 20:20 |
| hockeynut | dave-mccowan the reason I ask is that we can get a lot of good stuff for general RBAC testing out of what you have but its kinda tied closely with ACL users and we can generalize it | 20:21 |
| dave-mccowan | 2 CRs? or functionally break up code? +1 I want it to be generalized. | 20:21 |
| woodster_ | notmyname: I don't mean to scare you off btw! It would be good to talk details with you, reaperhulk at others at the summit, regarding your particular needs. I know you've had conversations with reaperhulk along those lines already too | 20:21 |
| notmyname | yeah | 20:22 |
| notmyname | oh you aren't scaring me off (yet) | 20:22 |
| jaosorior | jvrbanac: ping | 20:22 |
| hockeynut | dave-mccowan 2 CRs - ACL would be dependent on multiuser | 20:22 |
| hockeynut | then we could take multiuser piece and use that for generalized RBAC testing beyond just ACL | 20:23 |
| hockeynut | you've done some good stuff there that we really need in more than just 1 place | 20:23 |
| *** rellerreller has quit IRC | 20:24 | |
| reaperhulk | notmyname: I need to talk to you about some ideas around seekable authenticated encryption too ;) | 20:24 |
| jvrbanac | jaosorior, sup | 20:24 |
| notmyname | reaperhulk: I understand some of those words | 20:24 |
| reaperhulk | haha :) | 20:24 |
| jaosorior | jvrbanac: hey man, regarding this CR https://review.openstack.org/#/c/181026/ what entry are you talking about? O_O | 20:24 |
| hockeynut | dave-mccowan I'll put some comments in the CR you have now - then we can stew on them for a bit :-) | 20:25 |
| jvrbanac | jaosorior, oh... oops! brain fart. Sorry, I thought we had to specify the specs in the source/index | 20:26 |
| jaosorior | jvrbanac: I was looking for it and got pretty confused haha | 20:26 |
| jvrbanac | jaosorior, lol yeah | 20:27 |
| jvrbanac | oops | 20:27 |
| jaosorior | lol happens | 20:27 |
| dave-mccowan | hockeynut i'm definitely on board with using this framework for more general testing. (i'm also willing to write more test cases.) i'm willing to refactor the code to make that easier, if i have inadvertently tied it too closely to ACL. not sure how two CRs will help the cause, but i'm open to be influenced. :-) | 20:28 |
| openstackgerrit | Merged openstack/barbican-specs: Move data-remove-tenant-secret-assoc to Liberty https://review.openstack.org/181026 | 20:30 |
| hockeynut | dave-mccowan If nothing else it breaks up into 2 distinct functional enhancements. Combining too much in one CR could also lead to global warming. | 20:30 |
| redrobot | hockeynut everyone knows global warming is a myth ;) | 20:30 |
| hockeynut | for now...but what happens if we end up combining all kinds of stuff into a single CR? Anarchy and then global warming | 20:31 |
| hockeynut | at least thats what Algore says | 20:31 |
| woodster_ | so any available reviewers for arunkant 's CR?: https://review.openstack.org/#/c/178479/ | 20:36 |
| woodster_ | lots of comments out there so far, but would be good to get folk's general opinion about the changes suggested out there | 20:37 |
| dave-mccowan | hockeynut one question for you. jaosorior talked a while back about having the test sestup code add users on the fly (execute "keystone user-create") is this what you have in mind? | 20:53 |
| hockeynut | dave-mccowan I would except that could be painful for folks who don't have the authority to create users on-the-fly | 21:00 |
| hockeynut | dave-mccowan so your way would work better - assume the users exist already | 21:01 |
| dave-mccowan | hockeynut cool. i wrote code that did implemented it, and it made a mess of my dev environment when ever a test failed. did you have anything in mind w.r.t. your comment on barbican-functional.conf to make it less integrated with the code? | 21:03 |
| jaosorior | anybody has time to check this one out? https://review.openstack.org/#/c/175338/4 | 21:04 |
| redrobot | jaosorior looking | 21:04 |
| hockeynut | dave-mccowan would love to have the users be a list where each element of the list is the id/pw/proj but not sure how to do that w/oslo config | 21:05 |
| dave-mccowan | hockeynut, yea that would be nicer. although, i think the test cases would still be somewhat hardcoded, since it needs to know the expected behavior for each test for each user. | 21:08 |
| hockeynut | dave-mccowan yes, that is true | 21:08 |
| hockeynut | for now I think its aok - then if we see an opportunity for refactor later then we can jump on it | 21:09 |
| jaosorior | redrobot: thanks mr. | 21:12 |
| *** xaeth is now known as xaeth_afk | 21:13 | |
| jaosorior | arunkant, or whoever can answer this. By the way, why is it so that in the policy file, for the secret delete, it's admin only, and not admin and creator role? | 21:15 |
| jaosorior | so why "secret:delete": "rule:admin ..." and not "secret:delete": "rule:admin_or_creator_role ..." ? | 21:15 |
| redrobot | jaosorior creator is different than admin because creator cannot delete | 21:18 |
| redrobot | jaosorior https://github.com/cloudkeep/barbican/wiki/Role-Based-Access-Control#roles | 21:19 |
| redrobot | jaosorior otherwise, creator would be the same as admin, so no point in having two roles with the same permissions. | 21:19 |
| jaosorior | true | 21:21 |
| jaosorior | buuuut, why wouldn't I be able to delete my own secret? | 21:21 |
| redrobot | jaosorior because roles are used per-project | 21:21 |
| jaosorior | aah | 21:21 |
| jaosorior | forgot that detail | 21:21 |
| jaosorior | thanks man | 21:22 |
| atiwari | redrobot, all getting "ArgsAlreadyParsedError: arguments already parsed: cannot register CLI option" error while running Barbican under Apache. any idea? | 21:22 |
| jaosorior | therve had asked this question and I didn't know what was up there | 21:22 |
| atiwari | http://paste.openstack.org/show/216489/ is the full exception | 21:22 |
| *** kebray has quit IRC | 21:46 | |
| SheenaG | alee_ alee_dinner: would you give me your schedule for early next week when you get back? I want to set up a dry run time for the presentation with woodster_ | 21:47 |
| jaosorior | redrobot: thanks for the review man :D | 21:49 |
| dave-mccowan | atiwari, that error shows up in the troubleshoot guide: http://docs.openstack.org/developer/barbican/setup/troubleshooting.html | 21:51 |
| *** chadlung has quit IRC | 21:54 | |
| *** david-lyle has joined #openstack-barbican | 21:56 | |
| atiwari | dave-mccowan, I looked at it and I am not changing any code | 21:57 |
| *** chadlung has joined #openstack-barbican | 21:57 | |
| atiwari | I think, it some find need at https://github.com/cloudkeep/barbican/wiki/Integration-with-Apache2#create-the-corresponding-barbican-wsgi-python-scripts | 21:58 |
| openstackgerrit | Merged openstack/barbican: Add Barbican configs for SQLAlchemy pool settings https://review.openstack.org/179696 | 21:58 |
| atiwari | s/find/fix | 21:59 |
| openstackgerrit | Merged openstack/barbican: Removed extraneous config.py https://review.openstack.org/180625 | 21:59 |
| *** chlong has quit IRC | 21:59 | |
| *** chadlung has quit IRC | 22:04 | |
| *** igueths has quit IRC | 22:10 | |
| *** nelsnelson has quit IRC | 22:11 | |
| *** kebray has joined #openstack-barbican | 22:12 | |
| *** nkinder has quit IRC | 22:18 | |
| *** chadlung has joined #openstack-barbican | 22:29 | |
| *** pglass has quit IRC | 22:38 | |
| *** joesavak has quit IRC | 22:38 | |
| *** david-lyle has quit IRC | 22:38 | |
| *** kebray has quit IRC | 22:41 | |
| *** rm_work is now known as rm_work|away | 22:42 | |
| *** chadlung has quit IRC | 23:07 | |
| *** chadlung has joined #openstack-barbican | 23:08 | |
| *** chadlung has quit IRC | 23:12 | |
| *** arunkant_ has quit IRC | 23:18 | |
| *** chlong has joined #openstack-barbican | 23:24 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/barbican: Updated from global requirements https://review.openstack.org/181197 | 23:29 |
| *** nkinder has joined #openstack-barbican | 23:34 | |
| *** tkelsey has joined #openstack-barbican | 23:39 | |
| *** tkelsey has quit IRC | 23:43 | |
| *** rellerreller has joined #openstack-barbican | 23:52 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!
