Wednesday, 2015-04-22

woodster_reaperhulk: ^^^00:04
reaperhulkyeah pycparser made a change that blows up cffi00:08
reaperhulkso we're stuck on an upstream fix00:08
*** david-lyle has quit IRC00:24
*** david-lyle has joined #openstack-barbican00:27
*** SheenaG has quit IRC00:30
*** stanzi has joined #openstack-barbican00:32
*** zz_dimtruck is now known as dimtruck00:40
*** stanzi has quit IRC00:41
*** stanzi has joined #openstack-barbican00:42
redrobotreaperhulk ping00:47
dimtruckresolived! verified :)00:54
redrobotdimtruck woot!00:54
dimtruckpraise be the powers!!!00:55
*** gyee has quit IRC01:12
*** alee_headed_home has quit IRC01:14
*** alee has quit IRC01:25
*** alee_headed_home has joined #openstack-barbican01:26
*** alee_headed_home has quit IRC01:31
*** alee has joined #openstack-barbican01:37
*** ccneill has quit IRC01:37
*** alee_ has joined #openstack-barbican01:39
*** stanzi has quit IRC02:04
*** stanzi has joined #openstack-barbican02:05
*** stanzi has quit IRC02:09
*** stanzi has joined #openstack-barbican02:23
*** stanzi_ has joined #openstack-barbican02:24
*** stanzi_ has quit IRC02:26
*** stanzi_ has joined #openstack-barbican02:27
*** stanzi has quit IRC02:28
*** jamielennox is now known as jamielennox|away02:39
reaperhulkwhat's up redrobot. presumably it was about pycparser? :)03:14
*** stanzi_ has quit IRC03:16
*** stanzi has joined #openstack-barbican03:17
*** stanzi has quit IRC03:21
*** stanzi has joined #openstack-barbican03:22
redrobotreaperhulk nah, wanted to ask you about that description thing.  Sent an email instead.03:29
reaperhulkwill try to catch up on email tonight03:29
reaperhulkjust finished painting for the moment03:29
*** stanzi has quit IRC03:47
*** stanzi has joined #openstack-barbican03:47
*** dave-mccowan has quit IRC03:50
*** stanzi has quit IRC03:52
*** rm_you| has joined #openstack-barbican04:05
*** alee_ has quit IRC04:06
*** alee has quit IRC04:06
*** rm_you has quit IRC04:06
*** alee_ has joined #openstack-barbican04:09
*** alee has joined #openstack-barbican04:09
*** joesavak has joined #openstack-barbican04:16
*** stanzi has joined #openstack-barbican04:22
*** joesavak has quit IRC04:29
*** stanzi has quit IRC05:00
*** stanzi has joined #openstack-barbican05:01
*** stanzi has quit IRC05:05
*** stanzi has joined #openstack-barbican05:32
*** stanzi has quit IRC06:08
*** stanzi has joined #openstack-barbican06:09
*** stanzi has quit IRC06:13
*** woodster_ has quit IRC06:30
*** jaosorior has joined #openstack-barbican06:54
*** alee_ has quit IRC08:29
*** alee has quit IRC08:29
*** alee_ has joined #openstack-barbican08:34
*** alee has joined #openstack-barbican08:34
*** dimtruck is now known as zz_dimtruck09:14
*** stanzi has joined #openstack-barbican10:22
*** stanzi has quit IRC10:26
*** woodster_ has joined #openstack-barbican11:37
*** dave-mccowan has joined #openstack-barbican12:12
openstackgerritDave McCowan proposed openstack/barbican: Fix failure with get on dict that was None
dave-mccowan^^^ redrobot, i think this is rc2 worthy.13:39
*** xaeth_afk is now known as xaeth13:51
*** rellerreller has joined #openstack-barbican13:58
*** paul_glass has joined #openstack-barbican14:07
*** zz_dimtruck is now known as dimtruck14:15
*** rellerreller has quit IRC14:15
*** rellerreller has joined #openstack-barbican14:22
*** silos has joined #openstack-barbican14:25
*** igueths has joined #openstack-barbican14:28
dave-mccowanjvrbanac, when you get a chance, i could use some help using your code in functionaltests/common/{client,auth}.py14:36
jvrbanacdave-mccowan, what's up?14:37
dave-mccowanjvrbanac, i'd like to add some additional users to functional tests to exercise the ACL code.14:37
dave-mccowanjvrbanac, for keystone setup, i've done:
dave-mccowanjvrbanac, in i've done:
dave-mccowanjvrbanac, when i try to authenticate user 'reader', keystone spews: WARNING keystone.common.wsgi [-] Authorization failed. The request you have made requires authentication. from
dave-mccowanjvrbanac, keystone client agrees: keystoneclient.openstack.common.apiclient.exceptions.Unauthorized: The request you have made requires authentication. (HTTP 401)14:40
dave-mccowanjvrbananc, 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 jaosorior14:43
jvrbanacdave-mccowan, I believe so14:49
jvrbanacdave-mccowan, python-keystoneclient should provide the keystone cli14:50
redrobotjvrbanac dave-mccowan fyi the cli included in python-keystoneclient only supports keystone v2.0 and is deprecated in favor of the unified cli14:53
dave-mccowanjvrbanac, 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 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
jvrbanacdave-mccowan, first things first, can you manually authenticate with the user?14:59
dave-mccowanjvrbananc, what's the command to do that?14:59
*** silos has quit IRC15:00
jvrbanacdave-mccowan, like making a keystone auth call via the API. The easiest call is Keystone V2 which should still work:
*** stanzi has joined #openstack-barbican15:04
*** silos has joined #openstack-barbican15:04
*** stanzi has quit IRC15:05
*** stanzi has joined #openstack-barbican15:06
*** stanzi has quit IRC15:06
*** stanzi has joined #openstack-barbican15:06
dave-mccowanjvrbananc, i get the same error when i issue the command: keystone --os-username=reader --os-password=barbcian --os-auth-url= token-get15:07
redrobotdave-mccowan typo in 'barbican' password?15:08
dave-mccowanjvrbanac,   good eye redrobot, i got a token through the cli.15:10
*** rellerreller has quit IRC15:11
*** kebray has joined #openstack-barbican15:14
*** darrenmoffat has quit IRC15:20
*** darrenmoffat has joined #openstack-barbican15:21
openstackgerritKaitlin Farr proposed openstack/castellan: Add Barbican key manager
*** ccneill has joined #openstack-barbican15:33
*** joesavak has joined #openstack-barbican15:33
openstackgerritKaitlin Farr proposed openstack/castellan: Add Barbican key manager
*** stanzi has quit IRC15:42
*** stanzi has joined #openstack-barbican15:43
openstackgerritCharles Neill proposed openstack/barbican: Removing signing_dir directive from config
*** gyee has joined #openstack-barbican15:44
*** silos has quit IRC15:46
*** SheenaG has joined #openstack-barbican15:47
*** silos has joined #openstack-barbican15:51
dave-mccowanjvrbanac, any other ideas?  i captured some extra debug from  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-barbican15:53
siloshey rellerreller, could you help me with a problem I am having using the kmip plugin?15:55
*** jsavak has joined #openstack-barbican15:55
rellerrellersilos what's up?15:55
rellerrellersilos I saw your email this morning.15:56
rellerrellerI 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
silosah ok.15:56
silosno problem.15:56
rellerrellersilos I have two comments on your issue.15:57
rellerreller1. I believe you found a bug in the generate_supports method15:57
rellerreller2. The KMIP plugin does not yet support passphrase or opaque secret types.15:58
*** joesavak has quit IRC15:58
silosahhhh ok. So I can't just store a plain text secret then?15:58
rellerrellersilos Ya, that is not supported yet.15:59
rellerrellersilos tkelsey pushed a patch to PyKMIP to support secret data (i.e. passphrases) and opaque data15:59
silosrellerreller ok. I believe I have the newest version of pyKMIP already unless the patch was pushed in the past few days.16:00
rellerrellersilos 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
rellerrellersilos The support needs to be added to kmip_secret_store16:01
silosooo I might be interested in that if I get a little more free time :(16:01
rellerrellersilos Excellent! We are always looking for more contributors.16:02
silosrellerreller: 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-mccowanjvrbanac, i found it.  i had the tenant-name wrong. thanks!16:04
rellerrellersilos In terms of contributing to barbican. There is an OpenStack wiki on how to contribute to Barbican,
rellerrellerI meant how to contribute to OpenStack in general16:09
rellerrellersilos If you can go to the summit then there are good tutorials there as well.16:10
*** kfarr has joined #openstack-barbican16:10
rellerrellersilos There is not an API call to check if the KMIP plugin is configured correctly. The logs are the best place.16:10
silosrellerreller: ok I'll look into the logs16:14
silosreller: 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 behalf16:16
*** jsavak has quit IRC16:22
openstackgerritJohn Vrbanac proposed openstack/python-barbicanclient: Cleaning up validate_ref()
jvrbanacredrobot, question when you have a chance16:32
*** silos has quit IRC16:53
*** joesavak has joined #openstack-barbican16:53
*** ccneill has quit IRC16:58
*** jaosorior has quit IRC17:02
*** stanzi has quit IRC17:08
*** stanzi has joined #openstack-barbican17:09
*** stanzi has quit IRC17:13
*** ccneill has joined #openstack-barbican17: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 zuul17:31
*** gyee is now known as chinese_gyee17:37
*** chinese_gyee is now known as gyee17:38
*** david-lyle has quit IRC17:42
redrobotjvrbanac what's up?17:50
*** ccneill has quit IRC17:50
jvrbanacredrobot, nm. I figured it out17:51
*** chadlung has joined #openstack-barbican17:58
*** stanzi has joined #openstack-barbican17:58
arunkantwoodster_,: ping..have a question around order processing in worker flow. This is related to bug
openstackLaunchpad 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 IRC18:02
*** rellerreller has joined #openstack-barbican18:04
*** stanzi has quit IRC18:04
*** stanzi has joined #openstack-barbican18:04
*** joesavak has quit IRC18:13
*** kebray has quit IRC18:18
*** silos has joined #openstack-barbican18:25
*** ccneill has joined #openstack-barbican18:29
*** joesavak has joined #openstack-barbican18:30
woodster_arunkant: hey there, let me take a look....18:32
openstackgerritAmy Marrich proposed openstack/barbican: Improved error code handling for pkcs11 errors
arunkantwoodster_: 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 IRC18:36
*** silos1 has joined #openstack-barbican18:36
*** paul_glass has joined #openstack-barbican18:37
woodster_arunkant: I added some info to that bug just now18:37
*** silos has quit IRC18:38
*** silos1 has left #openstack-barbican18: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 orders18:38
*** silos1 has joined #openstack-barbican18:38
arunkantwoodster_, 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
openstackgerritJohn Vrbanac proposed openstack/python-barbicanclient: Adding support for token based authentication
arunkantwoodster_, 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 IRC18:43
*** stanzi has joined #openstack-barbican18:43
openstackgerritJohn Vrbanac proposed openstack/python-barbicanclient: Adding support for token based authentication
*** chadlung has quit IRC18: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 that18:46
woodster_covers all the cert order types, not just inferred from the stored key18:46
woodster_arunkant: my two cents though, not sure what others think18:46
woodster_arunkant: I added this one as a liberty summit discussion topic as well18:47
woodster_ccneill: FYI, regarding orders and ACL for generated secrets ^^^^18:47
*** stanzi has quit IRC18:48
redrobotSo, I need some core volunteers to be part of the stable branch release team18:50
redrobotjvrbanac I'm looking at you ^^18:50
aleewoodster_, I'm trying to parse what you wrote.18:51
aleewoodster_, 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
arunkantwoodster_,  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
aleewoodster_, 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
aleeso if the container does not belong to the order-initiators project id, then the order will fail.18:54
aleewoodster_, 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
aleewoodster_, 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 the short term I'd push for a simple check like I put in
openstackLaunchpad 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 request18:57
woodster_alee, arunkant dave-mccowan once that secret has any ACL applied, I'd say reject it for the short term18:58
*** chadlung has joined #openstack-barbican18:58
arunkantwoodster_, you mean even reject for users who has created that secret/containers or has the right roles on the secret/container project ?18:59
aleewoodster_, 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
aleeso the order will not be created19:00
*** paul_glass has quit IRC19:00
aleeand nothing will be there for the worker nodes to process19: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 them19: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 list19:01
*** ccneill_ has joined #openstack-barbican19: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 project19:02
aleeright - yes so there need to be a check added -- is the container private and owned by someone else.19:03
*** chadlung has quit IRC19:03
*** paul_glass has joined #openstack-barbican19:03
aleewoodster_, arunkant this should not be too hard to do -- we can query the acls and the owner.19:03
*** ccneill has quit IRC19:04
arunkantwoodster_, 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
aleearunkant, woodster_ eh? that seems a little too extreme19:05
woodster_arunkant: well, that is what I'm proposing until a more slick solution is available19:05
dave-mccowanwoodster_, 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
aleearunkant, woodster_ the whole idea of adding an acl is to allow people outside the project access19:05
arunkantalee, 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
aleenot add more restrcitons19:06
woodster_dave-mccowan: hmmm, not sure I like a half-baked container to be accessible outside of barbican19:06
aleearunkant, 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 IRC19:07
woodster_arunkant: the worker would have to drive all ACL processing based on what is stored on the order currently only the project-id and user-id it was created under19:07
aleewoodster_, arunkant I suggest we add the check at order creation time, and punt on the worker check19:07
aleewoodster_, arunkant do we know which user created an order?19:08
aleeI 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 processes19:09
arunkantwoodster_, 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 order19:09
*** kebray has joined #openstack-barbican19:09
aleearunkant, all you need to know is who created the order and if the secret is private or not, right?19:10
aleeits 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 key19:11
*** SheenaG has quit IRC19: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
arunkantalee, if container is not private, then we generally check if user has roles for the order/container project..that check cannot be done19: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 way19: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
arunkantwoodster_, Enforcing ACL at order submission time is possible. I agree, we can revisit enforcement at worker processing side later19:17
arunkantas 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 experience19:18
*** ccneill_ has quit IRC19:19
arunkantwoodster_, I am not sure what is expected 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 to19:26
woodster_me....or else not support it at all right now.19:26
redrobotwoodster_ I think that would surprise the user19:26
redrobotwoodster_ to issue and order, have it complete, but then be unable to retrieve the resulting container19:26
redrobotI think the expected behavior should be :  If you don't have access to the key, the order should go into ERROR state.19:27
redrobotor even better, get a 400 on the Order POST19:29
arunkantwoodster_, 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 we want to limit ACL copy for that operation only?19:33
redrobotarunkant I don't think ACL copy is the right solution19:33
redrobotarunkant woodster_  ACL copy would allow someone without access to a key to flood the rightful owner's account with certs.19:34
arunkantredrobot, 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
arunkantwoodster_ , ^^^19:37
arunkantwoodster_, can you please clarify19:38
*** chadlung has joined #openstack-barbican19: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 json19: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
redrobotwoodster_ 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
arunkantwoodster_, don't know who has this use case. It may be something came around testing different combinations..may be dave-mccowan has better idea19:45
redrobotwoodster_ 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 cert19:46
aleewoodster_, 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 owner19: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
aleethat should be a relatively easy check to add on order creation and on the worker nodes19: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_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 is as if the client instead uploaded the cert and then applied ACL to that cert.19:52
*** openstackgerrit has quit IRC19:54
*** openstackgerrit has joined #openstack-barbican19:55
arunkantwoodster_, 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 discussion19:56
*** chadlung has quit IRC19:57
aleewoodster_, 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-barbican19:59
aleeso basically the orderer has get permissions on the container (and its secrets).20:00
aleein 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_dimtruck20:01
*** kebray has quit IRC20:01
aleethe order goes in and generates a cert -- which by default has project based access.20:02
aleewhere is the issue?20:02
aleeare you saying that if the stored key has private access only, then the cert should too?20:05
arunkantalee, 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 project20:05
aleearunkant, no it explicitly does not20:05
aleearunkant, for now ..20:05
aleearunkant, if we wan to cover that case, we need to do a full acl check on the container20:06
aleeand I figured we ppunt that to L20:06
arunkantalee, 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 ccneill20:07
aleeyup - I'm ok with punting that case to L20:07
*** zz_dimtruck is now known as dimtruck20:08
arunkantalee, so full acl check can be done during order submission.. its unclear how to do that during worker based order processing.20:08
aleearunkant, right -- thats why I figured we'd punt :)20:09
aleearunkant, on the worker side, you do know who initiated the order20:10
aleeand you know the the acls etc. for the secret20:10
aleearunkant, seems like you could do a full acl check ..20:11
arunkantalee, yes..but the roles are missing which comes from token..20:11
aleearunkant, right and so we may need to persist those20:11
alee(as part of the order barbican-metadata20: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
aleewoodster_, wow thats a mouthful20:14
*** kebray has joined #openstack-barbican20:15
aleewoodster_, 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 certificate20:17
woodster_container...but they can't get that private key20:17
woodster_alee, ha! well my version somehow was more words than the first one I sent :)20:17
aleewoodster_, ok so why is that a problem?20:18
aleewoodster_, we're talking about x509 certificates here ..20:18
aleewoodster_, I most certainly want you and the whole world to be able to get my x509 certificate20:19
aleebecause it contains my public key20:19
aleeI also don't want you to ever get my private key20: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 project20:19
*** chadlung has joined #openstack-barbican20:20
aleeUser 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
aleethe cert isn't busted just because I can't access the private key20:21
aleeI can do all sorts of things with a cert20:21
aleelike verify communications from A20: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 need to auth to get any20:23
woodster_secret anyway, so right off the bat you aren't in public cert happiness anymore20:23
woodster_I think we've found our new 'content types' topic to bike shed about in Liberty!20:23
aleewoodster_, well - maybe we should talk about how created secrets really ought to have private access unless explicitly specified otherwise20:24
woodster_I was concerned we would be getting bored in VC20:24
aleerather than project access20:25
*** chadlung has quit IRC20:25
aleebut thats a whole 'nother content-types discussion20:25
woodster_alee, oh as a default? Yeah, I'll add that to the v2 discussion, as I think that woudl break v1 functionality20:25
aleeindeed it will - but its the right behavior if you want what you mentioned above20:26
aleepoint is - this is a problem not confined to stored-key cert enrolment20:26
aleeok -- gotta get back to dogtag20: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
arunkantwoodster_, alee, so do we want to partially address order related rbac defect..or something to be discussed in summit ?20:32
aleearunkant, I think we should add check if the container/secret is private and orderer != owner20:35
aleecertainly in validator at api level - and if possible at worker level.20:35
aleearunkant, that way someone who does not have access to my private key should not be able to use it to generate a cert20:36
*** chadlung has joined #openstack-barbican20:36
*** ccneill_ has joined #openstack-barbican20:36
aleeall the rest gets punted to liberty20:36
arunkantalee: okay. makes sense. Will update the bug to address on validator level with full acl check.20:37
*** ccneill__ has joined #openstack-barbican20:37
*** ccneill has quit IRC20:37
*** ccneill__ is now known as ccneill20: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 IRC20:40
aleewoodster_, I'd modify that slightly -- if private and owner != orderer, reject order20:43
aleewoodster_, this allows the cert publish case.20:43
*** silos1 has left #openstack-barbican20: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, reject20: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
jvrbanacredrobot, yo20:53
aleewoodster_, arunkant good for me20:53
redrobotjvrbanac what the deuce?20:53
jvrbanacredrobot, soo I don't think the logic you suggested is correct.20:53
redrobotjvrbanac how so?20:54
jvrbanacredrobot, actually my fingers are tired. You want to do mumble or hangouts or something?20:54
redrobotjvrbanac lol, sure thing, your choice20:54
ccneillwoodster_: 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 think21:02
dave-mccowanwoodster_, 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
tdinkwoodster_: not that im aware of21:06
dave-mccowanwoodster_, arunkant,  in case anyone wants to look at my output.    "creator" created a private secret, but 'writer' was able to write to it.21:07
ccneilltdink: that reminds me, have you guys decided on a good way to manage multiple users' credentials for tests?21:07
dave-mccowanccneill, 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
tdinkccneill: 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 problem21:09
ccneillyeah, 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-mccowanwoodster_, in the pastebin: line 58 creator creates with POST, line 65 creator sets ACL, line 84 writer writes with PUT21:12
dave-mccowanccneill, tdink i'm expecting my solution to work with the gate.  we'll see. :-)21:16
tdinkdave-mccowan: nice look forward to seeing it, that has been something on our radar for awhile21:18
*** gyee has quit IRC21:20
woodster_dave-mccowan: this is why: "secret:put": "rule:admin_or_creator_role and rule:secret_project_match"21:23
arunkantdave-mccowan, as part of initial acl impl, the policy rules were added only around read operations. No ACL support was added for write or delete21:23
woodster_dave-mccowan: for this first go around of RBAC, only secret and container GETs are covered21:23
redrobotjvrbanac when you get a chance, can you +2 and +Workflow ...  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-mccowanwoodster_, arunkant.  cool. working as designed. :-)   i'll take a look at some read test cases.21:26
*** gyee has joined #openstack-barbican21:26
*** openstackgerrit has quit IRC21:29
*** openstackgerrit has joined #openstack-barbican21:30
openstackgerritJohn Vrbanac proposed openstack/python-barbicanclient: Adding support for token based authentication
jvrbanacredrobot, done21:35
redrobotjvrbanac \o/21:35
jvrbanacredrobot, also, I came up with a more readable alternative:
jvrbanacredrobot, thoughts?21:35
redrobotjvrbanac yes!  much nicer to read21:37
dave-mccowanwoodster_, arunkant,  if I define read: ['reader'] and list:['lister'], should the user 'lister' be able to get a secret payload?21:38
redrobotwoodster_ I can add you to barbican-release if you want to approve stable branch CRs21:39
*** chadlung has quit IRC21: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 said21:41
woodster_dave-mccowan: arunkant I did not think list-based RBAC reads were supported...not in the policy file (secrets:get) anyway21:42
redrobotdave-mccowan yeah, afaik we don't have a "lister" role21:42
dave-mccowanwoodster_, 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 spec21: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-mccowanwoodster_, 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 GETs21:47
woodster_dave-mccowan: so those other ACL methods in there are 'forward looking'...probably should be rejected until they are really working21:48
dave-mccowanwoodster_, is "creator_only" the only option working?21:49
arunkantdave-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
redrobotyeahhhhhh so the spec never mentions "write" or "lister"21:52
redrobotdave-mccowan I agree with woodster_  that we need to remove all the "foward-looking" options21:53
redrobotdave-mccowan or rather, validate that only GET whitelist and creator-only are allowed in the acl request21:57
*** insequent has quit IRC21:58
redrobotdave-mccowan per spec delete, write are not implemented for K22:01
*** greghaynes has joined #openstack-barbican22:02
arunkantdave-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 private22:05
redrobotarunkant 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_afk22:10
*** openstackgerrit has quit IRC22:11
*** openstackgerrit has joined #openstack-barbican22:11
arunkantredrobot, 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_dinner22:13
redrobotarunkant yep, I suspect you are correct, and lister is in the same project as the owner22:13
openstackgerritSteve Heyman proposed openstack/python-barbicanclient: Initial setup for command line tests
dave-mccowanredrobot, 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-mccowanredrobot, arunaknt, woodster_,   so, same-project reads always work, unless secret is marked creator-only?22:17
redrobotdave-mccowan kindof.  users in the same project should each have a role on that project.   The roles follow this table for access:22:18
openstackgerritAmy Marrich proposed openstack/barbican: Improved error code handling for pkcs11 errors
redrobotdave-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 testing22:22
redrobotdave-mccowan per-secret-acl then overrides the RBAC, such that users in the same project can't access a secret marked as creator-only22:23
dave-mccowanredrobot, 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
redrobotdave-mccowan yes, that sounds about right.  the extra reader would be granted access to a secret as per
redrobotdave-mccowan I think that granting access in this way allows both GET metadata and GET decrypted.22:26
*** ccneill has quit IRC22:27
dave-mccowanredrobot thanks!22:29
*** ccneill has joined #openstack-barbican22:33
*** paul_glass has quit IRC22:35
*** chadlung has joined #openstack-barbican22:40
*** chadlung has quit IRC22:45
*** dimtruck is now known as zz_dimtruck22:48
*** ccneill has quit IRC22: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-barbican22:52
woodster_redrobot: dave-mccowan arunkant that reminds me we probably need to add a 'read-only' role to those you have to have some barbican role to access secrets even if on ACL or creator-only22:53
*** joesavak has quit IRC22:55
*** SheenaG has joined #openstack-barbican23:03
*** rm_you| has quit IRC23:10
*** kfarr has quit IRC23:12
*** igueths has quit IRC23:12
*** david-lyle has joined #openstack-barbican23:24
*** ccneill has quit IRC23:26
*** SheenaG has quit IRC23:54

Generated by 2.14.0 by Marius Gedminas - find it at!