| *** namnh has joined #openstack-barbican | 01:34 | |
| *** namnh has quit IRC | 02:33 | |
| *** namnh has joined #openstack-barbican | 02:34 | |
| *** annp has joined #openstack-barbican | 02:47 | |
| *** zhongjun_ has joined #openstack-barbican | 02:49 | |
| *** EmilienM has quit IRC | 03:22 | |
| *** EmilienM has joined #openstack-barbican | 03:24 | |
| openstackgerrit | Nguyen Van Trung proposed openstack/barbican master: Follow the new PTI for document build https://review.openstack.org/571365 | 06:09 |
|---|---|---|
| *** pcaruana has joined #openstack-barbican | 07:12 | |
| *** pcaruana is now known as pcaruana|worksho | 07:14 | |
| *** sapd_ has quit IRC | 07:15 | |
| *** sapd_ has joined #openstack-barbican | 07:15 | |
| *** serlex has joined #openstack-barbican | 07:23 | |
| *** alee has joined #openstack-barbican | 07:36 | |
| *** jaosorior has joined #openstack-barbican | 08:05 | |
| openstackgerrit | Nam Nguyen Hoai proposed openstack/barbican master: Initial OVO for Barbican https://review.openstack.org/559014 | 08:44 |
| openstackgerrit | Nam Nguyen Hoai proposed openstack/barbican master: Implement OVO for Barbican [1] https://review.openstack.org/499004 | 08:44 |
| openstackgerrit | Nam Nguyen Hoai proposed openstack/barbican master: Implement OVO for Barbican [2] https://review.openstack.org/499109 | 08:44 |
| openstackgerrit | Nam Nguyen Hoai proposed openstack/barbican master: [WIP] Implement OVO for Barbican [3] https://review.openstack.org/499419 | 08:44 |
| openstackgerrit | Nam Nguyen Hoai proposed openstack/barbican master: [WIP] Implement OVO for Barbican [4] https://review.openstack.org/528972 | 08:44 |
| openstackgerrit | Nam Nguyen Hoai proposed openstack/barbican master: [WIP] Implement OVO for Barbican [5] https://review.openstack.org/500244 | 08:44 |
| openstackgerrit | Nam Nguyen Hoai proposed openstack/barbican master: [WIP] Replace ACL resource to use OVO https://review.openstack.org/563857 | 08:44 |
| openstackgerrit | Nam Nguyen Hoai proposed openstack/barbican master: [WIP] Replace Transport-key using OVO https://review.openstack.org/563858 | 08:44 |
| openstackgerrit | Nam Nguyen Hoai proposed openstack/barbican master: [WIP] Replace secretstore and secretmeta using OVO https://review.openstack.org/564025 | 08:44 |
| openstackgerrit | Nam Nguyen Hoai proposed openstack/barbican master: [WIP] Replace container resource using OVO https://review.openstack.org/564672 | 08:44 |
| *** salmankhan has joined #openstack-barbican | 09:08 | |
| *** salmankhan has quit IRC | 09:14 | |
| *** pbourke has quit IRC | 09:41 | |
| *** pbourke has joined #openstack-barbican | 09:41 | |
| *** sapd_ has quit IRC | 09:45 | |
| *** sapd_ has joined #openstack-barbican | 09:45 | |
| *** namnh has quit IRC | 10:05 | |
| *** dave-mccowan has joined #openstack-barbican | 10:41 | |
| *** dave-mcc_ has joined #openstack-barbican | 10:46 | |
| *** dave-mccowan has quit IRC | 10:47 | |
| *** noslzzp has joined #openstack-barbican | 12:09 | |
| *** noslzzp has quit IRC | 12:10 | |
| *** openstackgerrit has quit IRC | 12:34 | |
| redrobot | Good mornin' Barbican! | 12:37 |
| alee | dave-mcc_, please check out any pending patches to try to get stuff in before friday | 13:15 |
| alee | thats when I'll cut the release | 13:15 |
| *** raildo has joined #openstack-barbican | 13:20 | |
| *** beisner is now known as beisner-sick | 13:22 | |
| *** rmascena has joined #openstack-barbican | 13:27 | |
| *** raildo has quit IRC | 13:29 | |
| alee | dave-mcc_, in particular, can you look at the stable branch stuff -- as you have the power! | 13:49 |
| dave-mcc_ | alee just queens? or pike (or ocata too)? | 13:51 |
| alee | dave-mcc_, we're responsible for 2 releases , right? | 14:02 |
| alee | so queens and pike? | 14:02 |
| alee | dave-mcc_, though we should certainly cast a leery eye to pike | 14:02 |
| *** noslzzp has joined #openstack-barbican | 14:04 | |
| alee | redrobot, jaosorior , dave-mcc_ there is some interest here in adding an api call to transfer the ownership of a secret to a different user/project -- any concerns about that? | 14:04 |
| alee | redrobot, jaosorior , dave-mcc_ the use case here is a cinder capability to transfer a volume from one user to another | 14:05 |
| dave-mcc_ | alee seems like the call would require permissions of both "old owner" and "new owner". does keystone tokens support that? | 14:06 |
| *** dave-mcc_ is now known as dave-mccowan | 14:06 | |
| alee | dave-mccowan, maybe .. certainly permission from the old owner | 14:07 |
| alee | which we would have | 14:07 |
| redrobot | Yeah, thinking only the current owner permission should be needed? | 14:07 |
| alee | dave-mccowan, cinder does have a two step process -- so that you would transfer as the old owener, and accept as the new owner | 14:08 |
| alee | but that may be unneeded for us .. | 14:08 |
| alee | maybe we just need the old owner's permissions? | 14:08 |
| alee | "dude, I'm giving you my secret ..." | 14:09 |
| jaosorior | alee: lets dig into what cinder can do | 14:09 |
| jaosorior | it seems to me that it's from one user to another, right? | 14:09 |
| dave-mccowan | "dude, i'm filling your secret quota without your permission" ;-) | 14:09 |
| jaosorior | is there a limitation there? | 14:09 |
| jaosorior | should those users always be in the same project? | 14:09 |
| alee | jaosorior, no | 14:10 |
| jaosorior | if that's the case, then we only need to care about ACLs | 14:10 |
| alee | jaosorior, they can be in different projects | 14:10 |
| jaosorior | if it isn't, then yeah, it would be a project transfer | 14:10 |
| jaosorior | uhm | 14:10 |
| alee | jaosorior, if they were in the same project, it wouldn't matter - because all project members have read access at least | 14:10 |
| jaosorior | what roles do the user that does the transfer need to have? | 14:10 |
| alee | though maybe not delete | 14:11 |
| jaosorior | to do the cinder volume transfer | 14:11 |
| alee | jaosorior, thats a good point -- maybe they need a special role to avoid the "secret quota problem" | 14:12 |
| alee | jaosorior, let me ask who can transfer volumes ... | 14:13 |
| *** abishop has joined #openstack-barbican | 14:14 | |
| alee | abishop, hey | 14:14 |
| abishop | alee: hey all | 14:14 |
| alee | abishop, so question -- who can transfer volumes? | 14:15 |
| alee | do they need a special role? | 14:15 |
| abishop | the presumption is a volume owner can try to transfer to anyone, and the recipient chooses to accept | 14:15 |
| abishop | no roles involved | 14:16 |
| jaosorior | abishop: what role does a volume owner have in a project? | 14:16 |
| jaosorior | is it just a _member_ in a project? | 14:16 |
| abishop | I believe so | 14:16 |
| abishop | not 100% solid on the details (it's old cinder code) | 14:17 |
| jaosorior | how does the recipient accept? | 14:17 |
| abishop | it's another cinder api call | 14:17 |
| abishop | initiated by recipient (sorry if that was obvious) | 14:17 |
| jaosorior | abishop: got docs about it? | 14:18 |
| jaosorior | abishop: is there a way to rever the ownership transfer? | 14:18 |
| alee | abishop, I imagine there is some transaction-id that is passed from sender to recipient | 14:18 |
| alee | jaosorior, yes there is | 14:19 |
| abishop | jaosorior: docs would be upstream, and I'd have to look for them (not sure who developed feature) | 14:19 |
| abishop | and you can cancel a transfer (reverts to original owner) | 14:19 |
| jaosorior | abishop: thanks for the info | 14:20 |
| abishop | alee: yes, the transfer initiate generates a cookie/token that the recipient must use when accepting the xfer | 14:20 |
| jaosorior | alee: my concern is that if you choose to revert the ownership... the other user already has access to read the secret. | 14:21 |
| abishop | jaosorior: my thought is the transfer initiate could xfer ownership to cinder service, who can then xfer it on to recipient, or back to original ownder if cancelled | 14:22 |
| *** openstackgerrit has joined #openstack-barbican | 14:23 | |
| openstackgerrit | Merged openstack/barbican master: Update the version of Ubuntu https://review.openstack.org/570835 | 14:23 |
| alee | abishop, maybe this can be solved completely on the side of things using existing barbican api calls | 14:23 |
| jaosorior | using ACLs maybe? | 14:23 |
| abishop | fyi, found this: https://wiki.openstack.org/wiki/VolumeTransfer | 14:23 |
| alee | yup | 14:23 |
| alee | abishop, you could do something like this .. | 14:24 |
| alee | 1. when transfer initiated, add acl to read to cinder service user | 14:24 |
| alee | 2. when transfer accepted, cinder service user creates a clone of the key --- i.e. gets key and store it again with recipient's creds | 14:25 |
| alee | and remove acl on original key | 14:26 |
| abishop | alee: would "store again" generate a new secret href? | 14:26 |
| jaosorior | it would, yes | 14:27 |
| alee | yes -- so you'd have to modify the metadata | 14:27 |
| alee | but thats just a db update , right? | 14:27 |
| abishop | alee: then things get awkward because the key ID is stored in multiple places in cinder db | 14:28 |
| abishop | could be done, but would need to ponder the details | 14:28 |
| abishop | alee: and what would clean up by deleting the original volume's secret? | 14:28 |
| alee | abishop, we could look to add acl to allow delete to cinder service user | 14:29 |
| jaosorior | abishop, alee: one downside of that is that ready access is only granted towards a specific user, not the project. So the transfer needs to be accepted by a very specific user. | 14:30 |
| abishop | alee: sure, as long as we agree on who handles cleanup, and that entity has perms to do so | 14:30 |
| alee | jaosorior, abishop the other thing we can do is model the transfer request in the same way as cinder does | 14:31 |
| dave-mccowan | alee giving the cinder service account access to a secret would be a new concept for encrypted volumes. some might consider it a risk. | 14:31 |
| alee | so when request is made, we could also make a "transfer request" we keep track of in barbican | 14:31 |
| alee | and then when cinder volume is accepted, we have a "acccept transfer" api call in barbican too | 14:32 |
| alee | with relevant cookie/id etc. | 14:32 |
| dave-mccowan | i like following cinder's model. hopefully, they've thought through all the issues we're bringing up now. :-) | 14:32 |
| alee | then no other user ("cinder service user" is involved | 14:33 |
| openstackgerrit | Brianna Poulos proposed openstack/barbican-tempest-plugin master: Add certificate validation scenario tests https://review.openstack.org/515210 | 14:40 |
| *** tidwellr has joined #openstack-barbican | 14:40 | |
| *** tidwellr has quit IRC | 14:40 | |
| *** tidwellr has joined #openstack-barbican | 14:41 | |
| openstackgerrit | Juan Antonio Osorio Robles proposed openstack/barbican master: Remove CA API policy file https://review.openstack.org/572120 | 14:50 |
| jaosorior | dave-mccowan, alee: or we could use a keystone trust that the cinder user would then have to use for this. | 14:50 |
| openstackgerrit | Juan Antonio Osorio Robles proposed openstack/barbican master: Remove CA API policy file https://review.openstack.org/572120 | 14:52 |
| jaosorior | alee: any reviews I should be giving priority to? | 14:52 |
| dave-mccowan | does cinder also have a copy volume? does that work well with barbican? (do they share the same key?) what happens if a volume is copied then one copy is deleted? | 14:53 |
| alee | dave-mccowan, I think they make a copy of the key | 15:00 |
| alee | dave-mccowan, but its all within the same project | 15:00 |
| alee | jaosorior, looking .. | 15:01 |
| alee | jaosorior, https://tinyurl.com/yctfozgh | 15:02 |
| alee | jaosorior, the needs approval stuff is most ready | 15:02 |
| alee | and dave-mccowan should focus on the stable stuff -- as he has power to push | 15:04 |
| alee | jaosorior, https://review.openstack.org/568905 as well | 15:04 |
| alee | jaosorior, how would a keystone trust work? | 15:06 |
| alee | I wonder if any other services besides cinder have this transfer ability .. | 15:07 |
| jaosorior | alee: https://wiki.openstack.org/wiki/Keystone/Trusts check the use cases | 15:09 |
| jaosorior | the rules explains it better | 15:11 |
| alee | jaosorior, gotcha - so the same flow I proposed earlier - except instead of using acls, we use two trusts -- one that the giver gives to cinder user to read/delete the secret and one that the receiver gives to cinder user to create a key | 15:20 |
| alee | jaosorior, sounds messy -- if I recall correctly, we developed acls specifically because trusts were not fine grained enough .. | 15:21 |
| alee | ie. could not be limited to a specific resource | 15:21 |
| jaosorior | uhm | 15:21 |
| jaosorior | true | 15:21 |
| alee | so the trust would let cinder user see all my secrets .. | 15:22 |
| alee | and that sucks | 15:22 |
| jaosorior | alee: although, cinder reading and re-writing the secret in the cinder process wouldn't be ideal either. Since that would expose the decrypted secret (even if for a very brief time) in memory | 15:22 |
| jaosorior | maybe the best choice is to re-implement the transfer mechanism in barbican | 15:22 |
| jaosorior | and just let cinder do that call with the user's credentials | 15:23 |
| alee | yeah - I like the idea of doing this without the secret leaving barbican | 15:23 |
| jaosorior | yeah, I'm also starting to think it's the best idea | 15:24 |
| jaosorior | with this, we need to start thinking of microversions for barbican though | 15:24 |
| jaosorior | and the OVO work becomes even more relevant | 15:24 |
| jaosorior | unless we want to start backporting this | 15:24 |
| jaosorior | which we shouldn't | 15:25 |
| alee | jaosorior, do we? its a new api call .. | 15:26 |
| jaosorior | alee: either that or we release API v2 :D | 15:27 |
| alee | jaosorior, we're going to end up doing that anyways , right? :/ | 15:27 |
| jaosorior | at some point | 15:28 |
| jaosorior | alee: up to the community though | 15:28 |
| jaosorior | could be a microversion | 15:28 |
| jaosorior | (since nothing changes but we just add a new API call) | 15:28 |
| alee | jaosorior, yeah - we need to think about microversions | 15:28 |
| alee | and yeah - we need to get the ovo stuff in | 15:28 |
| alee | jaosorior, good thing we got ovo patches to review :) | 15:29 |
| jaosorior | indeed | 15:29 |
| jaosorior | I'll get to those tomorrow | 15:29 |
| jaosorior | those I need to think about more | 15:29 |
| alee | does the microversion stuff require ovo to be in first? | 15:29 |
| jaosorior | not necessarily | 15:29 |
| alee | there will be new tables though | 15:30 |
| jaosorior | so.... supporting microversions per-se doesn't require OVO... having this new API call, I think yes, it does require the OVO work | 15:30 |
| jaosorior | also... what do we claim to support once the OVO work merges? rolling upgrades? | 15:31 |
| alee | yup | 15:32 |
| alee | gotta head back to hotel .. back on later -- lets ponder on this .. | 15:32 |
| jaosorior | ok | 15:32 |
| alee | jaosorior, ideally though we can get the ovo stuff in -- in rocky | 15:32 |
| jaosorior | indeed | 15:32 |
| jaosorior | it's been out there too long :D | 15:32 |
| alee | and then add this new api and microversions in early stein | 15:33 |
| jaosorior | +1 | 15:33 |
| alee | back later .. | 15:33 |
| *** alee has quit IRC | 15:34 | |
| *** pcaruana|worksho has quit IRC | 15:35 | |
| *** abishop has quit IRC | 15:38 | |
| *** serlex has quit IRC | 15:46 | |
| *** jmlowe has quit IRC | 15:49 | |
| openstackgerrit | Merged openstack/barbican master: Initial OVO for Barbican https://review.openstack.org/559014 | 15:51 |
| openstackgerrit | Merged openstack/barbican master: Implement OVO for Barbican [1] https://review.openstack.org/499004 | 15:51 |
| openstackgerrit | Merged openstack/python-barbicanclient master: Add --file flag for secrets https://review.openstack.org/506258 | 15:53 |
| openstackgerrit | Merged openstack/barbican master: Commit DB changes on API startup https://review.openstack.org/571698 | 15:54 |
| openstackgerrit | Merged openstack/barbican master: update some documents about the keystone "API v2.0" https://review.openstack.org/567995 | 16:09 |
| *** tidwellr has quit IRC | 16:30 | |
| *** tidwellr has joined #openstack-barbican | 16:31 | |
| *** pcaruana|worksho has joined #openstack-barbican | 16:51 | |
| *** alee has joined #openstack-barbican | 16:54 | |
| *** jmlowe has joined #openstack-barbican | 16:59 | |
| *** pcaruana|worksho is now known as pcaruana | 17:18 | |
| *** noslzzp has quit IRC | 18:22 | |
| *** jaosorior has quit IRC | 19:19 | |
| *** noslzzp has joined #openstack-barbican | 19:27 | |
| *** rmascena__ has joined #openstack-barbican | 19:29 | |
| *** rmascena has quit IRC | 19:31 | |
| *** sapd_ has quit IRC | 20:17 | |
| *** sapd has joined #openstack-barbican | 20:40 | |
| *** tidwellr has left #openstack-barbican | 20:42 | |
| *** pcaruana has quit IRC | 20:59 | |
| *** jmlowe has quit IRC | 21:08 | |
| *** rmascena__ has quit IRC | 21:10 | |
| *** dave-mccowan has quit IRC | 21:50 | |
| *** jmlowe has joined #openstack-barbican | 22:12 | |
| *** noslzzp has quit IRC | 22:15 | |
| *** dave-mccowan has joined #openstack-barbican | 22:22 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!