| woodster_ | reaperhulk: ^^^ | 00:04 |
|---|---|---|
| reaperhulk | yeah pycparser made a change that blows up cffi | 00:08 |
| reaperhulk | so we're stuck on an upstream fix | 00:08 |
| *** david-lyle has quit IRC | 00:24 | |
| *** david-lyle has joined #openstack-barbican | 00:27 | |
| *** SheenaG has quit IRC | 00:30 | |
| *** stanzi has joined #openstack-barbican | 00:32 | |
| *** zz_dimtruck is now known as dimtruck | 00:40 | |
| *** stanzi has quit IRC | 00:41 | |
| *** stanzi has joined #openstack-barbican | 00:42 | |
| redrobot | reaperhulk ping | 00:47 |
| dimtruck | resolived! verified :) | 00:54 |
| dimtruck | thanks! | 00:54 |
| redrobot | dimtruck woot! | 00:54 |
| dimtruck | praise be the powers!!! | 00:55 |
| *** gyee has quit IRC | 01:12 | |
| *** alee_headed_home has quit IRC | 01:14 | |
| *** alee has quit IRC | 01:25 | |
| *** alee_headed_home has joined #openstack-barbican | 01:26 | |
| *** alee_headed_home has quit IRC | 01:31 | |
| *** alee has joined #openstack-barbican | 01:37 | |
| *** ccneill has quit IRC | 01:37 | |
| *** alee_ has joined #openstack-barbican | 01:39 | |
| *** stanzi has quit IRC | 02:04 | |
| *** stanzi has joined #openstack-barbican | 02:05 | |
| *** stanzi has quit IRC | 02:09 | |
| *** stanzi has joined #openstack-barbican | 02:23 | |
| *** stanzi_ has joined #openstack-barbican | 02:24 | |
| *** stanzi_ has quit IRC | 02:26 | |
| *** stanzi_ has joined #openstack-barbican | 02:27 | |
| *** stanzi has quit IRC | 02:28 | |
| *** jamielennox is now known as jamielennox|away | 02:39 | |
| reaperhulk | what's up redrobot. presumably it was about pycparser? :) | 03:14 |
| *** stanzi_ has quit IRC | 03:16 | |
| *** stanzi has joined #openstack-barbican | 03:17 | |
| *** stanzi has quit IRC | 03:21 | |
| *** stanzi has joined #openstack-barbican | 03:22 | |
| redrobot | reaperhulk nah, wanted to ask you about that description thing. Sent an email instead. | 03:29 |
| reaperhulk | will try to catch up on email tonight | 03:29 |
| reaperhulk | just finished painting for the moment | 03:29 |
| *** stanzi has quit IRC | 03:47 | |
| *** stanzi has joined #openstack-barbican | 03:47 | |
| *** dave-mccowan has quit IRC | 03:50 | |
| *** stanzi has quit IRC | 03:52 | |
| *** rm_you| has joined #openstack-barbican | 04:05 | |
| *** alee_ has quit IRC | 04:06 | |
| *** alee has quit IRC | 04:06 | |
| *** rm_you has quit IRC | 04:06 | |
| *** alee_ has joined #openstack-barbican | 04:09 | |
| *** alee has joined #openstack-barbican | 04:09 | |
| *** joesavak has joined #openstack-barbican | 04:16 | |
| *** stanzi has joined #openstack-barbican | 04:22 | |
| *** joesavak has quit IRC | 04:29 | |
| *** stanzi has quit IRC | 05:00 | |
| *** stanzi has joined #openstack-barbican | 05:01 | |
| *** stanzi has quit IRC | 05:05 | |
| *** stanzi has joined #openstack-barbican | 05:32 | |
| *** stanzi has quit IRC | 06:08 | |
| *** stanzi has joined #openstack-barbican | 06:09 | |
| *** stanzi has quit IRC | 06:13 | |
| *** woodster_ has quit IRC | 06:30 | |
| *** jaosorior has joined #openstack-barbican | 06:54 | |
| *** alee_ has quit IRC | 08:29 | |
| *** alee has quit IRC | 08:29 | |
| *** alee_ has joined #openstack-barbican | 08:34 | |
| *** alee has joined #openstack-barbican | 08:34 | |
| *** dimtruck is now known as zz_dimtruck | 09:14 | |
| *** stanzi has joined #openstack-barbican | 10:22 | |
| *** stanzi has quit IRC | 10:26 | |
| *** woodster_ has joined #openstack-barbican | 11:37 | |
| *** dave-mccowan has joined #openstack-barbican | 12:12 | |
| openstackgerrit | Dave McCowan proposed openstack/barbican: Fix failure with get on dict that was None https://review.openstack.org/176101 | 13:31 |
| dave-mccowan | ^^^ redrobot, i think this is rc2 worthy. | 13:39 |
| *** xaeth_afk is now known as xaeth | 13:51 | |
| *** rellerreller has joined #openstack-barbican | 13:58 | |
| *** paul_glass has joined #openstack-barbican | 14:07 | |
| *** zz_dimtruck is now known as dimtruck | 14:15 | |
| *** rellerreller has quit IRC | 14:15 | |
| *** rellerreller has joined #openstack-barbican | 14:22 | |
| *** silos has joined #openstack-barbican | 14:25 | |
| *** igueths has joined #openstack-barbican | 14:28 | |
| dave-mccowan | jvrbanac, when you get a chance, i could use some help using your code in functionaltests/common/{client,auth}.py | 14:36 |
| jvrbanac | dave-mccowan, what's up? | 14:37 |
| dave-mccowan | jvrbanac, i'd like to add some additional users to functional tests to exercise the ACL code. | 14:37 |
| dave-mccowan | jvrbanac, for keystone setup, i've done: http://www.fpaste.org/214019/96452371/ | 14:38 |
| dave-mccowan | jvrbanac, in client.py i've done: http://www.fpaste.org/214337/71354114/ | 14:39 |
| dave-mccowan | jvrbanac, when i try to authenticate user 'reader', keystone spews: WARNING keystone.common.wsgi [-] Authorization failed. The request you have made requires authentication. from 192.168.59.3 | 14:40 |
| dave-mccowan | jvrbanac, keystone client agrees: keystoneclient.openstack.common.apiclient.exceptions.Unauthorized: The request you have made requires authentication. (HTTP 401) | 14:40 |
| dave-mccowan | jvrbananc, to help narrow it down, is there a keystone cli command that i can enter to make sure i have the keystone entries right? | 14:42 |
| *** redrobot sets mode: +v jaosorior | 14:43 | |
| jvrbanac | dave-mccowan, I believe so | 14:49 |
| jvrbanac | dave-mccowan, python-keystoneclient should provide the keystone cli | 14:50 |
| redrobot | jvrbanac dave-mccowan fyi the cli included in python-keystoneclient only supports keystone v2.0 and is deprecated in favor of the unified cli | 14:53 |
| dave-mccowan | jvrbanac, redrobot, maybe that was the wrong question. i don't want to start debugging a non-related path. the real question is: did i miss anything in client.py that is causing me to not get reader's token? or, did i do something wrong in keystone setup that would cause reader to not be a valid user? | 14:56 |
| jvrbanac | dave-mccowan, first things first, can you manually authenticate with the user? | 14:59 |
| dave-mccowan | jvrbananc, what's the command to do that? | 14:59 |
| *** silos has quit IRC | 15:00 | |
| jvrbanac | dave-mccowan, like making a keystone auth call via the API. The easiest call is Keystone V2 which should still work: http://developer.openstack.org/api-ref-identity-v2.html#identity-auth-v2 | 15:02 |
| *** stanzi has joined #openstack-barbican | 15:04 | |
| *** silos has joined #openstack-barbican | 15:04 | |
| *** stanzi has quit IRC | 15:05 | |
| *** stanzi has joined #openstack-barbican | 15:06 | |
| *** stanzi has quit IRC | 15:06 | |
| *** stanzi has joined #openstack-barbican | 15:06 | |
| dave-mccowan | jvrbananc, i get the same error when i issue the command: keystone --os-username=reader --os-password=barbcian --os-auth-url=http://192.168.59.114:35357/v2.0 token-get | 15:07 |
| redrobot | dave-mccowan typo in 'barbican' password? | 15:08 |
| dave-mccowan | jvrbanac, good eye redrobot, i got a token through the cli. | 15:10 |
| *** rellerreller has quit IRC | 15:11 | |
| *** kebray has joined #openstack-barbican | 15:14 | |
| *** darrenmoffat has quit IRC | 15:20 | |
| *** darrenmoffat has joined #openstack-barbican | 15:21 | |
| openstackgerrit | Kaitlin Farr proposed openstack/castellan: Add Barbican key manager https://review.openstack.org/171918 | 15:23 |
| *** ccneill has joined #openstack-barbican | 15:33 | |
| *** joesavak has joined #openstack-barbican | 15:33 | |
| openstackgerrit | Kaitlin Farr proposed openstack/castellan: Add Barbican key manager https://review.openstack.org/171918 | 15:39 |
| *** stanzi has quit IRC | 15:42 | |
| *** stanzi has joined #openstack-barbican | 15:43 | |
| openstackgerrit | Charles Neill proposed openstack/barbican: Removing signing_dir directive from config https://review.openstack.org/176071 | 15:44 |
| *** gyee has joined #openstack-barbican | 15:44 | |
| *** silos has quit IRC | 15:46 | |
| *** SheenaG has joined #openstack-barbican | 15:47 | |
| *** silos has joined #openstack-barbican | 15:51 | |
| dave-mccowan | jvrbanac, any other ideas? i captured some extra debug from auth.py. http://www.fpaste.org/214377/29717733/ as far as i can tell the parameters for the admin user are the same as the parameters for the reader user. (and the username and password are correct, as verified by keystone CLI) | 15:52 |
| *** rellerreller has joined #openstack-barbican | 15:53 | |
| silos | hey rellerreller, could you help me with a problem I am having using the kmip plugin? | 15:55 |
| *** jsavak has joined #openstack-barbican | 15:55 | |
| rellerreller | silos what's up? | 15:55 |
| rellerreller | silos I saw your email this morning. | 15:56 |
| rellerreller | I am normally online more, but the last 1-1.5 weeks I have been testing some KMIP stuff and unable to be online. | 15:56 |
| silos | ah ok. | 15:56 |
| silos | no problem. | 15:56 |
| rellerreller | silos I have two comments on your issue. | 15:57 |
| rellerreller | 1. I believe you found a bug in the generate_supports method | 15:57 |
| rellerreller | 2. The KMIP plugin does not yet support passphrase or opaque secret types. | 15:58 |
| *** joesavak has quit IRC | 15:58 | |
| silos | ahhhh ok. So I can't just store a plain text secret then? | 15:58 |
| rellerreller | silos Ya, that is not supported yet. | 15:59 |
| rellerreller | silos tkelsey pushed a patch to PyKMIP to support secret data (i.e. passphrases) and opaque data | 15:59 |
| silos | rellerreller ok. I believe I have the newest version of pyKMIP already unless the patch was pushed in the past few days. | 16:00 |
| rellerreller | silos It would be easy to add support for passphrases now that that patch is merged in PyKMIP. It is on our todo list; although you are free to contribute if you like :) | 16:00 |
| rellerreller | silos The support needs to be added to kmip_secret_store | 16:01 |
| silos | ooo I might be interested in that if I get a little more free time :( | 16:01 |
| rellerreller | silos Excellent! We are always looking for more contributors. | 16:02 |
| silos | rellerreller: where would be a good place to start to look to becoming a contributor to barbican? also is there another api call I can use just to make sure the kmip_plugin is configured correctly? | 16:03 |
| dave-mccowan | jvrbanac, i found it. i had the tenant-name wrong. thanks! | 16:04 |
| rellerreller | silos In terms of contributing to barbican. There is an OpenStack wiki on how to contribute to Barbican, https://wiki.openstack.org/wiki/How_To_Contribute | 16:09 |
| rellerreller | I meant how to contribute to OpenStack in general | 16:09 |
| rellerreller | silos If you can go to the summit then there are good tutorials there as well. | 16:10 |
| *** kfarr has joined #openstack-barbican | 16:10 | |
| rellerreller | silos There is not an API call to check if the KMIP plugin is configured correctly. The logs are the best place. | 16:10 |
| silos | rellerreller: ok I'll look into the logs | 16:14 |
| silos | reller: for the openstack summit. jrichli, full name janie richling, who is working on swift will be attending the openstack summit. she is aware of what I am working on and can talk to you about the kmip stuff on my behalf | 16:16 |
| *** jsavak has quit IRC | 16:22 | |
| openstackgerrit | John Vrbanac proposed openstack/python-barbicanclient: Cleaning up validate_ref() https://review.openstack.org/175605 | 16:27 |
| jvrbanac | redrobot, question when you have a chance | 16:32 |
| *** silos has quit IRC | 16:53 | |
| *** joesavak has joined #openstack-barbican | 16:53 | |
| *** ccneill has quit IRC | 16:58 | |
| *** jaosorior has quit IRC | 17:02 | |
| *** stanzi has quit IRC | 17:08 | |
| *** stanzi has joined #openstack-barbican | 17:09 | |
| *** stanzi has quit IRC | 17:13 | |
| *** ccneill has joined #openstack-barbican | 17:16 | |
| -openstackstatus- NOTICE: gerrit is restarting to clear hung stream-events tasks. any review events between 16:48 and 17:32 utc will need to be rechecked or have their approval votes reapplied to trigger testing in zuul | 17:31 | |
| *** gyee is now known as chinese_gyee | 17:37 | |
| *** chinese_gyee is now known as gyee | 17:38 | |
| *** david-lyle has quit IRC | 17:42 | |
| redrobot | jvrbanac what's up? | 17:50 |
| *** ccneill has quit IRC | 17:50 | |
| jvrbanac | redrobot, nm. I figured it out | 17:51 |
| *** chadlung has joined #openstack-barbican | 17:58 | |
| *** stanzi has joined #openstack-barbican | 17:58 | |
| arunkant | woodster_,: ping..have a question around order processing in worker flow. This is related to bug https://bugs.launchpad.net/barbican/+bug/1446266 | 18:01 |
| openstack | Launchpad bug 1446266 in Barbican "RBAC needs to be checked for stored-key orders" [Undecided,New] - Assigned to Arun Kant (arunkant-uws) | 18:01 |
| *** rellerreller has quit IRC | 18:02 | |
| *** rellerreller has joined #openstack-barbican | 18:04 | |
| *** stanzi has quit IRC | 18:04 | |
| *** stanzi has joined #openstack-barbican | 18:04 | |
| *** joesavak has quit IRC | 18:13 | |
| *** kebray has quit IRC | 18:18 | |
| *** silos has joined #openstack-barbican | 18:25 | |
| *** ccneill has joined #openstack-barbican | 18:29 | |
| *** joesavak has joined #openstack-barbican | 18:30 | |
| woodster_ | arunkant: hey there, let me take a look.... | 18:32 |
| openstackgerrit | Amy Marrich proposed openstack/barbican: Improved error code handling for pkcs11 errors https://review.openstack.org/175568 | 18:35 |
| arunkant | woodster_: So question is what need to be implemented in worker side. There is no context information available related to user and roles when worker is processing orders. | 18:36 |
| *** paul_glass has quit IRC | 18:36 | |
| *** silos1 has joined #openstack-barbican | 18:36 | |
| *** paul_glass has joined #openstack-barbican | 18:37 | |
| woodster_ | arunkant: I added some info to that bug just now | 18:37 |
| *** silos has quit IRC | 18:38 | |
| *** silos1 has left #openstack-barbican | 18:38 | |
| woodster_ | alee, redrobot, rellerreller: Please take a look at the comments on the bug above to see if you agree ^^^^ Not sure who else was interested in the RBAC policy stuff around orders | 18:38 |
| *** silos1 has joined #openstack-barbican | 18:38 | |
| arunkant | woodster_, I think question comes from ACL support. If a user has access to a container via ACL, then can user (project is different from container's project) make order using that container ? | 18:40 |
| openstackgerrit | John Vrbanac proposed openstack/python-barbicanclient: Adding support for token based authentication https://review.openstack.org/175599 | 18:41 |
| arunkant | woodster_, also if container is marked private..then should users within same project allowed to use when using it via orders? | 18:41 |
| *** stanzi has quit IRC | 18:43 | |
| *** stanzi has joined #openstack-barbican | 18:43 | |
| openstackgerrit | John Vrbanac proposed openstack/python-barbicanclient: Adding support for token based authentication https://review.openstack.org/175599 | 18:45 |
| *** chadlung has quit IRC | 18:46 | |
| woodster_ | arunkant: I think until we bring the orders resource into the ACL fold, we can only produce certificate containers for which a GET will retrieve all the components. We could try to match the container/certificate-secret ACL settings to be the same as for that stored key, but I'd prefer to have an order-based mechanism for specifying such ACL policy that | 18:46 |
| woodster_ | covers all the cert order types, not just inferred from the stored key | 18:46 |
| woodster_ | arunkant: my two cents though, not sure what others think | 18:46 |
| woodster_ | arunkant: I added this one as a liberty summit discussion topic as well | 18:47 |
| woodster_ | ccneill: FYI, regarding orders and ACL for generated secrets ^^^^ | 18:47 |
| *** stanzi has quit IRC | 18:48 | |
| redrobot | So, I need some core volunteers to be part of the stable branch release team | 18:50 |
| redrobot | jvrbanac I'm looking at you ^^ | 18:50 |
| alee | woodster_, I'm trying to parse what you wrote. | 18:51 |
| alee | woodster_, you'll have to forgive me --- I've been tied up in java/c++/dogtag land -- so my brain is still doing a context switch .. | 18:51 |
| arunkant | woodster_, do we need direct ACL definition on orders..I mean orders are processing artifact. We can enforce/check ACL during order submit time but issue comes up around worker processing time. | 18:52 |
| alee | woodster_, arunkant --, dave-mccowan - however, as I understand it, the way the code is currently written -- there is currently a check to see if the container (containing the stored keys) exists and that check is project-based. | 18:53 |
| alee | so if the container does not belong to the order-initiators project id, then the order will fail. | 18:54 |
| alee | woodster_, arunkant , dave-mccowan - this is the way it is written right now -- and I got the impression from woodster_ comments, that this is what you wanted to happen. | 18:55 |
| alee | woodster_, or am I misreading? | 18:55 |
| woodster_ | alee, arunkant, I think this is a question of what to fix/do now vs later after more lengthy discussion at the summit perhaps...in the short term I'd push for a simple check like I put in https://bugs.launchpad.net/barbican/+bug/1446266 | 18:56 |
| openstack | Launchpad bug 1446266 in Barbican "RBAC needs to be checked for stored-key orders" [Undecided,New] - Assigned to Arun Kant (arunkant-uws) | 18:56 |
| woodster_ | alee, arunkant dave-mccowan I think the glitch is if ACL is applied to that secret, either before the request or before the worker processes the request | 18:57 |
| woodster_ | alee, arunkant dave-mccowan once that secret has any ACL applied, I'd say reject it for the short term | 18:58 |
| *** chadlung has joined #openstack-barbican | 18:58 | |
| arunkant | woodster_, you mean even reject for users who has created that secret/containers or has the right roles on the secret/container project ? | 18:59 |
| alee | woodster_, arunkant , dave-mccowan I still don't understand -- when the order is placed, a validator checks to see if the asymm container exists. Right now, that asymm container existence check will return no results if the container is not associated with the order initiators projeect. | 19:00 |
| alee | so the order will not be created | 19:00 |
| *** paul_glass has quit IRC | 19:00 | |
| alee | and nothing will be there for the worker nodes to process | 19:01 |
| woodster_ | arunkant: I'm thinking for the initial go at this yes. I'd prefer to have a generic way to specify at order time desired ACL outcomes for generated secrets/containers, to make it more explicit for all order types, not just for orders with stored keys assoc with them | 19:01 |
| woodster_ | alee, the use case here is the container and order are under teh same project, but the container is a private secret or has an ACL list | 19:01 |
| alee | ah | 19:02 |
| *** ccneill_ has joined #openstack-barbican | 19:02 | |
| alee | gotcha | 19:02 |
| woodster_ | alee, so the generated cert container would have a stored key that is potentially not usable by all clients even if the same project | 19:02 |
| alee | right - yes so there need to be a check added -- is the container private and owned by someone else. | 19:03 |
| *** chadlung has quit IRC | 19:03 | |
| *** paul_glass has joined #openstack-barbican | 19:03 | |
| alee | woodster_, arunkant this should not be too hard to do -- we can query the acls and the owner. | 19:03 |
| *** ccneill has quit IRC | 19:04 | |
| arunkant | woodster_, so we are saying once a ACL is defined on a container..then you cannot use that in a order. Is that okay? | 19:04 |
| alee | arunkant, woodster_ eh? that seems a little too extreme | 19:05 |
| woodster_ | arunkant: well, that is what I'm proposing until a more slick solution is available | 19:05 |
| dave-mccowan | woodster_, alee, we need a two-step container-order. create the container to get a ref, then pass in the ref to the empty container to the order controller. | 19:05 |
| alee | arunkant, woodster_ the whole idea of adding an acl is to allow people outside the project access | 19:05 |
| arunkant | alee, implementing during order submission time is possible, the issue is comes up when need to enforce acl during order processing by a worker (where there is no user context available) | 19:06 |
| alee | not add more restrcitons | 19:06 |
| woodster_ | dave-mccowan: hmmm, not sure I like a half-baked container to be accessible outside of barbican | 19:06 |
| alee | arunkant, yes - but if we enforce at order creation time, there is nothing for the workers to process (unless the acl changes) | 19:07 |
| *** rellerreller has quit IRC | 19:07 | |
| woodster_ | arunkant: the worker would have to drive all ACL processing based on what is stored on the order itself...so currently only the project-id and user-id it was created under | 19:07 |
| alee | woodster_, arunkant I suggest we add the check at order creation time, and punt on the worker check | 19:07 |
| alee | woodster_, arunkant do we know which user created an order? | 19:08 |
| alee | I think we added that info, right? | 19:08 |
| woodster_ | dave-mccowan: but we do have precedent for that with the two step secret :) But secret meta only vs some of my container secrets become visible over time. The difference I see is with processes that require a cannonical cert container to work right...if required secrets are not available, that breaks those processes | 19:09 |
| arunkant | woodster_, There are no user roles available during worker order processing. So cannot tell whether user should have project based access or not? | 19:09 |
| woodster_ | alee, yes the creating user is on the order | 19:09 |
| *** kebray has joined #openstack-barbican | 19:09 | |
| alee | arunkant, all you need to know is who created the order and if the secret is private or not, right? | 19:10 |
| alee | its the same check as on the way in .. | 19:10 |
| woodster_ | arunkant, correct, which is why the order ACL use case is interesting to me and needs further fleshing out I think. Short of that, we either restrict operations involving store keys that have ACL, or else assume generated things have to have the same ACL as the stored key | 19:11 |
| *** SheenaG has quit IRC | 19:11 | |
| woodster_ | alee, arunkant so maybe we just defer to worker time, and when we create the cert container we just copy over the ACL settings of the stored key? | 19:11 |
| arunkant | alee, if container is not private, then we generally check if user has roles for the order/container project..that check cannot be done | 19:13 |
| woodster_ | alee, arunkant so only clients with the same privs as can GET the stored key could get the generated cert container/certificate...makes sense. The order and validation logic wouldn't have to be clever about things that way | 19:13 |
| woodster_ | arunkant: that order RBAC check is to see if the client has auth-z to do that operation. If that operation results in something that is more restrictive to access those new things (generated container/secrets), then I'm not sure that is an insecure thing. It might be an unpleasant surprise to the order client though, who still can't access is generated cert! | 19:15 |
| woodster_ | arunkant: alee so due to the above surprise issue, I'm still in the camp of eventually making ACL explicit as part of the order request contract, and for now not allowing any ACL behaviors on the stored key. | 19:16 |
| arunkant | woodster_, Enforcing ACL at order submission time is possible. I agree, we can revisit enforcement at worker processing side later | 19:17 |
| arunkant | as that is just to cover if there are any authz changes after order submission..which might not be that frequent use case. | 19:18 |
| woodster_ | arunkant: so would you copy the stored key ACL to the generated cert container on the worker side though? If you don't you still could get an unpleasant client experience | 19:18 |
| *** ccneill_ has quit IRC | 19:19 | |
| arunkant | woodster_, I am not sure what is expected behavior..do we need to have same ACLs on newly created cert container? | 19:23 |
| woodster_ | arunkant: I would suggest that we do need this, otherwise we risk the container being out of sync with secrets inside of it. This is always possible due to race conditions, but for the typical case of an order generating a cert for a stored key with not other intervention all the way, I thinking copying the ACL to the generated artifacts makes sense to | 19:26 |
| woodster_ | me....or else not support it at all right now. | 19:26 |
| redrobot | woodster_ I think that would surprise the user | 19:26 |
| redrobot | woodster_ to issue and order, have it complete, but then be unable to retrieve the resulting container | 19:26 |
| redrobot | I think the expected behavior should be : If you don't have access to the key, the order should go into ERROR state. | 19:27 |
| redrobot | or even better, get a 400 on the Order POST | 19:29 |
| arunkant | woodster_, so far the above mentioned bug is only around "stored-key" cert order and enforcing ACL access. Do we want to change scope to include ACL copy behavior. Also bug is around "stored-key" type cert order..do we want to limit ACL copy for that operation only? | 19:33 |
| redrobot | arunkant I don't think ACL copy is the right solution | 19:33 |
| redrobot | arunkant woodster_ ACL copy would allow someone without access to a key to flood the rightful owner's account with certs. | 19:34 |
| arunkant | redrobot, ACL copy is after verifying user has right access privileges. So if I understanding correctly, its something needs to be added when order is processed successfully from plugin perspective. | 19:36 |
| arunkant | woodster_ , ^^^ | 19:37 |
| arunkant | woodster_, can you please clarify | 19:38 |
| *** chadlung has joined #openstack-barbican | 19:42 | |
| woodster_ | redrobot I think you are in the camp of not supporting cert orders with stored keys with ACL/private-user settings then, correct? If so, I'm agreeing with that. Eventually we do need to have ACL/private-user sorts of orders too, but they should be explicit IMHO...either via a query parameters or additions to the order's request json | 19:42 |
| woodster_ | arunkant: alee what use case do we have now that requires being able to create a cert from a stored key with ACL/private-user? | 19:43 |
| woodster_ | ...vs a simple project-id based stored key? | 19:43 |
| redrobot | woodster_ arunkant I need to think about all the possible use cases. Copying ACL from key to cert might make sense, but only after access to key has been verified. I think it would be best if someone ( arun ? ) spells out all the possible use cases, kind of like I did for the typed secrets. | 19:45 |
| arunkant | woodster_, don't know who has this use case. It may be something came around testing different combinations..may be dave-mccowan has better idea | 19:45 |
| redrobot | woodster_ arunkant the problem now is that if a key is marked as private via ACL, someone else in the same project is still allowed to order a cert | 19:46 |
| alee | woodster_, ultimately I think that I should be able to create a cert for any prvate key for which I have access. In the short term, I'm ok with restrciing access to those keys which are in the same project. And the only check that needs to be added is to check if a key is private and if the user != container owner | 19:47 |
| woodster_ | redrobot: yeah, if we don't reject that outright, then I do agree that either certs are created that can be used by some clients, or else a bunch of certs could be injected into the private user space. Either one is bad to me. | 19:47 |
| alee | that should be a relatively easy check to add on order creation and on the worker nodes | 19:47 |
| woodster_ | alee, that last part is the sticky point though...ACL/private is what makes this problematic because it either means a less restricted user is generating secrets for a more restricted one, or else some users of that same project can't use the cert later. But seem like bad UX to me. | 19:50 |
| woodster_ | s/But/Both | 19:51 |
| woodster_ | alee, redrobot arunkant I'd rather add the whitelist/private info optionally to the order request itself, since an order is essentially storing a secret on behalf of the ordering client...so is as if the client instead uploaded the cert and then applied ACL to that cert. | 19:52 |
| *** openstackgerrit has quit IRC | 19:54 | |
| *** openstackgerrit has joined #openstack-barbican | 19:55 | |
| arunkant | woodster_, it looks like it really need more thinking around this..may be we just implement ACL check during order processing time (which will address the case of not allowing private secret to be used in order if user does not have access) ...and implement rest later after summit discussion | 19:56 |
| arunkant | s/processing/submission | 19:56 |
| *** chadlung has quit IRC | 19:57 | |
| alee | woodster_, sorry I'm a little slow today -- lets say we add a check so that if a container is private and the orderer != owner, we reject the order. we also keep the check that container project = orderer project. | 19:59 |
| *** ccneill_ has joined #openstack-barbican | 19:59 | |
| alee | so basically the orderer has get permissions on the container (and its secrets). | 20:00 |
| alee | in fact its a subset of those users that have get permissions on that secret - because it excludes non-project members that have acl access. | 20:01 |
| *** dimtruck is now known as zz_dimtruck | 20:01 | |
| *** kebray has quit IRC | 20:01 | |
| alee | the order goes in and generates a cert -- which by default has project based access. | 20:02 |
| alee | where is the issue? | 20:02 |
| alee | are you saying that if the stored key has private access only, then the cert should too? | 20:05 |
| arunkant | alee, does it cover the case, where orderer has read ACL access for container..should that user be able to request cert for that container . container project != orderer project | 20:05 |
| alee | arunkant, no it explicitly does not | 20:05 |
| alee | arunkant, for now .. | 20:05 |
| alee | arunkant, if we wan to cover that case, we need to do a full acl check on the container | 20:06 |
| alee | and I figured we ppunt that to L | 20:06 |
| arunkant | alee, that is the only case I can think of..which is not addressed in your above mentioned approach. | 20:07 |
| *** ccneill_ is now known as ccneill | 20:07 | |
| alee | yup - I'm ok with punting that case to L | 20:07 |
| *** zz_dimtruck is now known as dimtruck | 20:08 | |
| arunkant | alee, so full acl check can be done during order submission.. its unclear how to do that during worker based order processing. | 20:08 |
| alee | arunkant, right -- thats why I figured we'd punt :) | 20:09 |
| alee | arunkant, on the worker side, you do know who initiated the order | 20:10 |
| alee | and you know the the acls etc. for the secret | 20:10 |
| alee | arunkant, seems like you could do a full acl check .. | 20:11 |
| arunkant | alee, yes..but the roles are missing which comes from token.. | 20:11 |
| alee | arunkant, right and so we may need to persist those | 20:11 |
| alee | (as part of the order barbican-metadata | 20:12 |
| woodster_ | alee, arunkant the issue I see is that the generated cert will be non-ACL project based, but if that stored key has an ACL with the order's user, then if another user of that same project tries to later get that cotainer, they won't be able to get the private key, so the cert is worthless to them. | 20:12 |
| alee | woodster_, wow thats a mouthful | 20:14 |
| *** kebray has joined #openstack-barbican | 20:15 | |
| alee | woodster_, lets try to make this specific -- users A in project X accesses secret S (which is associated with project X) and generates a cert C (which is associated by default with project X) | 20:16 |
| woodster_ | alee, arunkant This is the problem sequence: 1) User A with project A creates private key secret, putting themselves as ACL for it, 2) User A creates an order specifying that private key secret (passes the proposed checks above) and a cert container is generated with no ACL, but for project A, 3) User B, also with project A tried to use that certificate | 20:17 |
| woodster_ | container...but they can't get that private key | 20:17 |
| woodster_ | alee, ha! well my version somehow was more words than the first one I sent :) | 20:17 |
| alee | woodster_, ok so why is that a problem? | 20:18 |
| alee | woodster_, we're talking about x509 certificates here .. | 20:18 |
| alee | woodster_, I most certainly want you and the whole world to be able to get my x509 certificate | 20:19 |
| alee | because it contains my public key | 20:19 |
| alee | I also don't want you to ever get my private key | 20:19 |
| woodster_ | alee, because User A might not have realized that the private key secret was restrictive to other users (they just did a simple order), and User B has access to a busted certificate even though in their project | 20:19 |
| *** chadlung has joined #openstack-barbican | 20:20 | |
| alee | User B will realize that they can't access the private key when they try to do so -- and if they realy need it -- go bonk user A on the head. | 20:20 |
| alee | the cert isn't busted just because I can't access the private key | 20:21 |
| alee | I can do all sorts of things with a cert | 20:21 |
| alee | like verify communications from A | 20:21 |
| woodster_ | alee, I've been looking at this from a provisioning perspective, not a publishing perspective. it seems like making any secret, regardless of its type, less restrictive should be explicit though. I think we are operating without enough use cases though! :) It doesn't seem to me that barbican should be in the publishing business...you need to auth to get any | 20:23 |
| woodster_ | secret anyway, so right off the bat you aren't in public cert happiness anymore | 20:23 |
| woodster_ | I think we've found our new 'content types' topic to bike shed about in Liberty! | 20:23 |
| alee | woodster_, well - maybe we should talk about how created secrets really ought to have private access unless explicitly specified otherwise | 20:24 |
| woodster_ | I was concerned we would be getting bored in VC | 20:24 |
| alee | rather than project access | 20:25 |
| *** chadlung has quit IRC | 20:25 | |
| alee | but thats a whole 'nother content-types discussion | 20:25 |
| woodster_ | alee, oh as a default? Yeah, I'll add that to the v2 discussion, as I think that woudl break v1 functionality | 20:25 |
| alee | indeed it will - but its the right behavior if you want what you mentioned above | 20:26 |
| alee | point is - this is a problem not confined to stored-key cert enrolment | 20:26 |
| alee | ok -- gotta get back to dogtag | 20:27 |
| woodster_ | alee, I would agree with that one. I would feel better if we had good use cases to bound these discussions though. Provisioning is the only cert use case I'm familiar with right now, but a more open public key secret make sense for channel communiacation use cases. | 20:28 |
| woodster_ | alee, ok, enough bike shed for now! | 20:29 |
| arunkant | woodster_, alee, so do we want to partially address order related rbac defect..or something to be discussed in summit ? | 20:32 |
| alee | arunkant, I think we should add check if the container/secret is private and orderer != owner | 20:35 |
| alee | certainly in validator at api level - and if possible at worker level. | 20:35 |
| alee | arunkant, that way someone who does not have access to my private key should not be able to use it to generate a cert | 20:36 |
| *** chadlung has joined #openstack-barbican | 20:36 | |
| *** ccneill_ has joined #openstack-barbican | 20:36 | |
| alee | all the rest gets punted to liberty | 20:36 |
| arunkant | alee: okay. makes sense. Will update the bug to address on validator level with full acl check. | 20:37 |
| alee | ok | 20:37 |
| *** ccneill__ has joined #openstack-barbican | 20:37 | |
| *** ccneill has quit IRC | 20:37 | |
| *** ccneill__ is now known as ccneill | 20:38 | |
| woodster_ | alee, arunkant so the check is: is stored key's project doesn't match order's, reject order. Else if private setting on stored key, reject order. Else if no ACL make the order. Else if stored key ACL has the order's user on the list, make the order. | 20:40 |
| *** ccneill_ has quit IRC | 20:40 | |
| alee | woodster_, I'd modify that slightly -- if private and owner != orderer, reject order | 20:43 |
| alee | woodster_, this allows the cert publish case. | 20:43 |
| *** silos1 has left #openstack-barbican | 20:44 | |
| woodster_ | redrobot, checkout ^^^^...alee brought up an interesting use case, whereby a user might want to have the public cert more widely available for folks to use than the private key secret has. So combining his and my rules then: is stored key's project doesn't match order's, reject order. Else if private setting on stored key and its owner != order, reject | 20:51 |
| woodster_ | order. Else if no ACL make the order. Else if stored key ACL has the order's user on the list, make the order. | 20:51 |
| jvrbanac | redrobot, yo | 20:53 |
| alee | woodster_, arunkant good for me | 20:53 |
| redrobot | jvrbanac what the deuce? | 20:53 |
| jvrbanac | redrobot, soo I don't think the logic you suggested is correct. | 20:53 |
| redrobot | jvrbanac how so? | 20:54 |
| jvrbanac | redrobot, actually my fingers are tired. You want to do mumble or hangouts or something? | 20:54 |
| redrobot | jvrbanac lol, sure thing, your choice | 20:54 |
| jvrbanac | mumble | 20:54 |
| ccneill | woodster_: been reading through the conversation, looks pretty reasonable to me but I'll have to take a look at the bug report and probably re-read the whole discussion before I get my head totally around it I think | 21:02 |
| dave-mccowan | woodster_, arunkant, redrobot, has anyone done much end-to-end testing with ACLs? i've written some basic functional tests to try them out, and i don't think ACLs are being enforced. | 21:04 |
| woodster_ | dave-mccowan: I don't believe so. tdink you and hockeynut haven't work on ACL functional tests yet, correct? | 21:05 |
| tdink | woodster_: not that im aware of | 21:06 |
| dave-mccowan | woodster_, arunkant, in case anyone wants to look at my output. http://www.fpaste.org/214486/42973632/ "creator" created a private secret, but 'writer' was able to write to it. | 21:07 |
| ccneill | tdink: that reminds me, have you guys decided on a good way to manage multiple users' credentials for tests? | 21:07 |
| dave-mccowan | ccneill, tdink, i don't know if it's a "good way", but i got on a roll and implemented "a way" :-) i'll try to get it cleaned up for review soon. | 21:09 |
| tdink | ccneill: steve was working on something that woudl have allowed the creation of multiple users for testing. however i believe he had to scrap that due to some keystone issues and opted to use a different method to solve the problem | 21:09 |
| ccneill | yeah, I made a little "security_utils" file that had static credentials defined in it, but I think my way would've broken in the Gerrit gate :( | 21:10 |
| woodster_ | dave-mccowan: what sequence did you call things in? did you make the secret a private-user secret under 'creator', and then 'writer' was able to access it later? | 21:10 |
| dave-mccowan | woodster_, in the pastebin: line 58 creator creates with POST, line 65 creator sets ACL, line 84 writer writes with PUT | 21:12 |
| dave-mccowan | ccneill, tdink i'm expecting my solution to work with the gate. we'll see. :-) | 21:16 |
| ccneill | sweet | 21:17 |
| tdink | dave-mccowan: nice look forward to seeing it, that has been something on our radar for awhile | 21:18 |
| *** gyee has quit IRC | 21:20 | |
| woodster_ | dave-mccowan: this is why: "secret:put": "rule:admin_or_creator_role and rule:secret_project_match" | 21:23 |
| arunkant | dave-mccowan, as part of initial acl impl, the policy rules were added only around read operations. No ACL support was added for write or delete | 21:23 |
| woodster_ | dave-mccowan: for this first go around of RBAC, only secret and container GETs are covered | 21:23 |
| redrobot | jvrbanac when you get a chance, can you +2 and +Workflow https://review.openstack.org/#/c/175515/1 ... Since you and I are the only ones with +2 on stable/kilo I think we should merge with only 2 reviews. | 21:25 |
| dave-mccowan | woodster_, arunkant. cool. working as designed. :-) i'll take a look at some read test cases. | 21:26 |
| *** gyee has joined #openstack-barbican | 21:26 | |
| *** openstackgerrit has quit IRC | 21:29 | |
| *** openstackgerrit has joined #openstack-barbican | 21:30 | |
| openstackgerrit | John Vrbanac proposed openstack/python-barbicanclient: Adding support for token based authentication https://review.openstack.org/175599 | 21:34 |
| jvrbanac | redrobot, done | 21:35 |
| redrobot | jvrbanac \o/ | 21:35 |
| jvrbanac | redrobot, also, I came up with a more readable alternative: https://review.openstack.org/#/c/175599/4/barbicanclient/barbican.py | 21:35 |
| jvrbanac | redrobot, thoughts? | 21:35 |
| redrobot | jvrbanac yes! much nicer to read | 21:37 |
| dave-mccowan | woodster_, arunkant, if I define read: ['reader'] and list:['lister'], should the user 'lister' be able to get a secret payload? | 21:38 |
| redrobot | woodster_ I can add you to barbican-release if you want to approve stable branch CRs | 21:39 |
| *** chadlung has quit IRC | 21:40 | |
| woodster_ | redrobot, probably best for you to control that, as you know best what the TC wants to see put in there :) | 21:40 |
| woodster_ | jvrbanac: +1 on what redrobot said | 21:41 |
| woodster_ | dave-mccowan: arunkant I did not think list-based RBAC reads were supported...not in the policy file (secrets:get) anyway | 21:42 |
| redrobot | dave-mccowan yeah, afaik we don't have a "lister" role | 21:42 |
| dave-mccowan | woodster_, redrobot, what is the expected behavior, if this is my ACL: Request Body: {"read": {"users": ["reader"], "creator-only": false}, "write": {"users": ["writer"], "creator-only": false}, "list": {"users": ["lister"], "creator-only": false}} | 21:44 |
| * redrobot needs to go re-read the ACL spec | 21:44 | |
| woodster_ | dave-mccowan: arunkant I'm pretty sure only the 'read' group is actually used. Yeah, no sphinx docs to look at yet. | 21:45 |
| dave-mccowan | woodster_, redrobot, currently 'lister' is able to read. i expected that read to be blocked. | 21:47 |
| woodster_ | dave-mccowan: in general, if the policy.json file access you are trying to do only has the old-school rules, then RBAC is not supported on them. So right now, that is only the secret and container GETs | 21:47 |
| woodster_ | dave-mccowan: so those other ACL methods in there are 'forward looking'...probably should be rejected until they are really working | 21:48 |
| dave-mccowan | woodster_, is "creator_only" the only option working? | 21:49 |
| arunkant | dave-mccowan, do you have output for case where 'lister' is able to read. As you said, it should not be able to read assuming 'lister' is not creator of the secret. | 21:51 |
| redrobot | yeahhhhhh so the spec never mentions "write" or "lister" | 21:52 |
| dave-mccowan | woodster_ http://www.fpaste.org/214507/14297395/ | 21:52 |
| redrobot | http://specs.openstack.org/openstack/barbican-specs/specs/kilo/add-creator-only-option.html | 21:52 |
| redrobot | dave-mccowan I agree with woodster_ that we need to remove all the "foward-looking" options | 21:53 |
| redrobot | dave-mccowan or rather, validate that only GET whitelist and creator-only are allowed in the acl request | 21:57 |
| *** insequent has quit IRC | 21:58 | |
| redrobot | dave-mccowan per spec http://specs.openstack.org/openstack/barbican-specs/specs/kilo/add-per-secret-policy.html delete, write are not implemented for K | 22:01 |
| *** greghaynes has joined #openstack-barbican | 22:02 | |
| arunkant | dave-mccowan: Does lister user has barbican roles in the same project where secret is created? It may be getting project based access as secret is not marked private | 22:05 |
| redrobot | arunkant I think that the test is invalid. judging from the payload dave-mccowan is using, he was expecting the "list" part of ACL to work, which it does not currently as per spec. | 22:09 |
| *** xaeth is now known as xaeth_afk | 22:10 | |
| *** openstackgerrit has quit IRC | 22:11 | |
| *** openstackgerrit has joined #openstack-barbican | 22:11 | |
| arunkant | redrobot, as there is no ACL policy for list operation so 'lister' user is just any random user. If user is able to access it, one possibility is that lister user may have barbican roles in the same project where that secret is created. That can explain the reason for access. I cannot tell from output what are the roles for that user. | 22:12 |
| *** alee is now known as alee_dinner | 22:13 | |
| redrobot | arunkant yep, I suspect you are correct, and lister is in the same project as the owner | 22:13 |
| openstackgerrit | Steve Heyman proposed openstack/python-barbicanclient: Initial setup for command line tests https://review.openstack.org/172604 | 22:15 |
| dave-mccowan | redrobot, arunaknt, woodster_, yes, lister is in same project as creator. ok, got it. i need separate projects for the extra read list. | 22:16 |
| dave-mccowan | redrobot, arunaknt, woodster_, so, same-project reads always work, unless secret is marked creator-only? | 22:17 |
| redrobot | dave-mccowan kindof. users in the same project should each have a role on that project. The roles follow this table for access: | 22:18 |
| redrobot | dave-mccowan https://github.com/cloudkeep/barbican/wiki/Role-Based-Access-Control#roles | 22:18 |
| openstackgerrit | Amy Marrich proposed openstack/barbican: Improved error code handling for pkcs11 errors https://review.openstack.org/175568 | 22:19 |
| redrobot | dave-mccowan having functional tests with 4 different users on the same project, each with one of the 4 roles should be the first step in RBAC testing | 22:22 |
| redrobot | dave-mccowan per-secret-acl then overrides the RBAC, such that users in the same project can't access a secret marked as creator-only | 22:23 |
| dave-mccowan | redrobot, to be complete, then 6 users. those four, plus an extra reader on a different project and an extra on a different project with no access? | 22:23 |
| redrobot | dave-mccowan yes, that sounds about right. the extra reader would be granted access to a secret as per http://specs.openstack.org/openstack/barbican-specs/specs/kilo/add-per-secret-policy.html#rest-api-impact | 22:25 |
| redrobot | dave-mccowan I think that granting access in this way allows both GET metadata and GET decrypted. | 22:26 |
| *** ccneill has quit IRC | 22:27 | |
| dave-mccowan | redrobot thanks! | 22:29 |
| *** ccneill has joined #openstack-barbican | 22:33 | |
| *** paul_glass has quit IRC | 22:35 | |
| *** chadlung has joined #openstack-barbican | 22:40 | |
| *** chadlung has quit IRC | 22:45 | |
| *** dimtruck is now known as zz_dimtruck | 22:48 | |
| *** ccneill has quit IRC | 22:49 | |
| woodster_ | redrobot: dave-mccowan just adding users to that ACL list (so not just the creator-only setting) bypasses traditional RBAC as noted in that wiki link above. | 22:51 |
| woodster_ | redrobot: dave-mccowan so just being a user on that ACL list for a secret can grant you access to it. | 22:52 |
| *** ccneill has joined #openstack-barbican | 22:52 | |
| woodster_ | redrobot: dave-mccowan arunkant that reminds me we probably need to add a 'read-only' role to those rules...so you have to have some barbican role to access secrets even if on ACL or creator-only | 22:53 |
| *** joesavak has quit IRC | 22:55 | |
| *** SheenaG has joined #openstack-barbican | 23:03 | |
| *** rm_you| has quit IRC | 23:10 | |
| *** kfarr has quit IRC | 23:12 | |
| *** igueths has quit IRC | 23:12 | |
| *** david-lyle has joined #openstack-barbican | 23:24 | |
| *** ccneill has quit IRC | 23:26 | |
| *** SheenaG has quit IRC | 23:54 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!