Friday, 2015-05-29

*** SheenaG has quit IRC00:13
*** SheenaG has joined #openstack-barbican00:15
*** gyee has quit IRC00:18
*** kebray has quit IRC00:19
*** dimtruck is now known as zz_dimtruck00:20
*** arunkant_ has quit IRC00:22
*** SheenaG has quit IRC00:24
*** gyee has joined #openstack-barbican00:25
*** kfox1111 has quit IRC00:38
*** dave-mccowan has joined #openstack-barbican01:04
*** gyee is now known as operator9903:06
*** barra204 has quit IRC03:11
*** barra204 has joined #openstack-barbican03:13
*** dave-mcc_ has joined #openstack-barbican05:05
*** dave-mccowan has quit IRC05:08
*** tkelsey has joined #openstack-barbican05:51
*** tkelsey has quit IRC05:56
*** woodster_ has quit IRC06:50
*** nickrmc83 has joined #openstack-barbican07:00
*** tkelsey has joined #openstack-barbican08:25
*** tkelsey has quit IRC11:09
*** tkelsey has joined #openstack-barbican11:11
*** darrenmoffat has quit IRC11:39
*** darrenmoffat has joined #openstack-barbican11:39
*** nickrmc83 has quit IRC12:03
*** kfarr has joined #openstack-barbican12:16
*** woodster_ has joined #openstack-barbican12:50
*** rellerreller has joined #openstack-barbican12:52
openstackgerritMerged openstack/barbican-specs: Drop incubating theme from docs
*** nelsnelson has joined #openstack-barbican14:08
openstackgerritAde Lee proposed openstack/barbican: Added Certificate API Docs and Quick Start Guides
*** pglass has joined #openstack-barbican14:26
*** rellerreller has quit IRC14:30
*** kebray has joined #openstack-barbican14:36
*** kebray has quit IRC14:37
aleewoodster_, so is there anything controversial in the acl docs?14:37
*** rellerreller has joined #openstack-barbican14:37
*** kebray has joined #openstack-barbican14:37
*** nkinder has quit IRC14:38
*** xaeth_afk is now known as xaeth14:39
*** igueths has joined #openstack-barbican15:05
*** rellerreller has quit IRC15:15
*** rellerreller has joined #openstack-barbican15:16
woodster_alee: the biggest thing in there is if a secret/container should be considered to have an ACL 'resource' always or not...that is the bit about returning 404s and 200/201s vs not. I'm in the camp that dealing with the no-ACL case adds complexity that doesn't buy you anything. I'd rather say a secret/container always has a no-settings/default policy (so15:20
woodster_eventually the project-access=true) so we don't have to worry (in code/testing/docs) that initially you get a 200, thereafter get a 201. Or if you GET acl for a secret you don't get a 404 if not there, rather get an empty dict15:20
woodster_hockeynut: jvrbanac redrobot ^^^^15:21
woodster_also an FYI that kfox1111 is interested in being able to add/remove users atomically to avoid race conditions with multiple heat engines operating at the same time. Future bike shed opportunities, not to be confused with current CRs!15:22
aleewoodster_, right I responded to that.  Based on our discussion in Vancouver, it seems that there is always an ACL15:23
aleebecause we return a default ACL rather than an empty list15:24
*** kfox1111 has joined #openstack-barbican15:25
kfox1111First stab at the nova instance user spec here:
*** tkelsey has quit IRC15:34
openstackgerritChelsea Winfree proposed openstack/barbican: Adding a new script  to generate mkek and hmac
chellygel^ WIP15:35
aleewoodster_, chellygel - note - I added cert api docs - please review15:36
arunkantalee, woodster_, If no ACL exists, we can return empty list instead of returning with 'project_access' flag. The reason being it indicates that there is entry exists in barbican side which is not correct. This gets confusing if other operations 'list', 'delete' are added. Are we going to return record for those entries with 'project_access' true.15:37
arunkantalee, woodster_, As mentioned yesterday in irc, we are using PUT for both create and update and indicating 201 vs 200 response code indicates that clearly to client.15:40
*** gyee has joined #openstack-barbican15:41
woodster_arunkant: hockeynut my concern is more of testing...we would have to have tests (unit and functional) in place to test those conditions, and I don't see a benefit to that. If we go the 200/201 route, for consistency we'd also need to return 404 on GETs IMHO, which also doesn't seem beneficial to me15:43
woodster_alee: will do15:43
dhellmannredrobot: I would like to cut a release of python-barbicanclient on Monday to unblock the work on dropping the oslo namespace packages. The release would include -- Does that work for you?15:45
dhellmannredrobot: based on the change list there, the version will be 3.2.015:46
redrobotdhellmann sounds good.  I asumme it'll be 3.1.2 ?15:46
dhellmannwith the requirements changes and new features, it should be 3.215:46
*** SheenaG has joined #openstack-barbican15:47
redrobotdhellmann ok, sounds good.15:47
dhellmannredrobot: ok, I'll include that in my list on Monday -- thanks!15:47
aleearunkant, woodster_ sorry - I thought that we decided in vancouver to return "{project-access: True}" ?15:47
redrobotalee arunkant woodster_ yep, that's what I remember/wrote down.  should not need 404s.15:50
aleearunkant, woodster_ from the clients point of view, I'm not sure there is a need to distinguish whether or not an acl has been previously generated.  An acl is more like a property of a secret - rather than a standalone resource.15:51
arunkantalee: Right now CR is returning empty dict. I think we talked about returning { 'read' : { project-access: True}}  as we are now only supporting 'read' operation only. The question is if we start supporting other operations like 'list' or 'write', then are we going to include those as well. Returning non-empty dict gives impression that there is ACL exists.15:51
*** zz_dimtruck is now known as dimtruck15:52
aleearunkant, if you consider the acl to be a preoperty of the secret/container, rather than as an independent resource, then it does not matter to the client whether or not they initially added an acl or not.15:53
aleeand yeah - we'd likely need to return the same for write, list etc.15:54
aleefor one thing, that will make the permissions model and defaults explicit15:54
aleearunkant, think of it this way -- secrets always have an effective acl, even if we don't set one.15:55
aleearunkant, from the clients point of view, why should they care if they originally set it explicitly or not?15:56
kfox1111I like that.16:01
kfox1111for the heat resource, I want to just delete/add users to an acl. not care that it doesn't exist yet.16:01
arunkantalee: It would have been quite clear if ACL is created whenever a new secret is created with default setting. Now, we are defining a custom default behavior which is not easy to follow if a new person comes and start looking into barbican16:01
redrobotarunkant I think the main point here is that whether the ACL exists as "project-access": true or if it does not exist yet, the behavior is the same.16:03
aleearunkant, I dont think it will be too hard to follow if it is 1) well documented in the api docs you have written 2) made explicit in the code ie. we'll have constants like DEFAULT_READ_ACL etc.16:03
*** kfarr has quit IRC16:04
redrobotarunkant I don't see a benefit in differentiating the two cases, if the behavior is the same.  I think it's simpler if there is no explicit creation of the ACL.16:04
aleearunkant, we have defaults for many other parameters too.16:05
arunkantalee, okay. I will make the change and API docs to reflect that. Cannot say if totally convinced as this default response now ties tightly to policy defined behavior (expected to change with deployment).16:13
aleearunkant, thats an interesting point16:16
aleeredrobot, woodster_ ^^16:16
aleeis it possible that project-access:True will not be the default response for a particular deployment?16:17
kfox1111question, while we're in the general area. What benifit does having users, not tenants be able to restrict secrets? It sounds totally counter to the whole reason behind tenants.16:26
kfox1111As an admin on various tenants, I'm going to run into problems if one of the other admins in the tenant launches something that uses that kind of secret, then goes on vacation. :/16:26
redrobotkfox1111 so project (tenant) access is provided by Keystone currently.   For a private secret, for example, the Keystone workflow would be to create a new project (tenant) where the user is the only one associated with the project with the admin role.16:28
kfox1111I wouldn't be able to relaunch vm's that go bad. :/16:29
kfox1111ah. so thats still basically just project level acl's. that's ok.16:29
redrobotkfox1111 some contributors were unhappy with this workflow, and pushed for this feature to work around the way Keystone provides authorization.16:30
kfox1111I thought I heard someone mention that you could acl it so that only the user that created the secret could do things with it though.16:30
redrobotkfox1111 no, the project admin(s) can still edit the secret.16:30
redrobotkfox1111 including removing/modifying the acl16:30
kfox1111ok. cool.16:31
aleekfox1111, yes - by default its project level access -- but you can restrict a secret to be read-able only by a specific user.  but a project admin can modify those acls.16:31
kfox1111ok. So I can recommend "Don't Do That", and still have a chance to fix it when they do it wrong. :)16:32
*** kebray has quit IRC16:34
*** Kevin_Bishop has joined #openstack-barbican16:54
*** kebray has joined #openstack-barbican17:09
hockeynuthockeynut is going to be afk this afternoon but I'll be back on tonight and over the weekend.17:18
*** kebray has quit IRC17:22
*** barra204 has quit IRC17:26
*** kebray has joined #openstack-barbican17:29
*** kebray has quit IRC17:40
*** chadlung has joined #openstack-barbican17:53
*** kebray has joined #openstack-barbican18:07
*** barra204 has joined #openstack-barbican18:09
*** kebray has quit IRC18:12
*** kebray has joined #openstack-barbican18:12
*** barra204 has quit IRC18:15
*** barra204 has joined #openstack-barbican18:20
*** crc32 has joined #openstack-barbican18:24
*** barra204_ has joined #openstack-barbican18:28
*** crc32 has quit IRC18:30
*** crc32 has joined #openstack-barbican18:30
*** barra204 has quit IRC18:31
*** crc32 has quit IRC18:35
*** chadlung has quit IRC18:38
*** xaeth is now known as xaeth_afk18:39
*** crc32 has joined #openstack-barbican18:40
*** xaeth_afk is now known as xaeth18:46
openstackgerritChelsea Winfree proposed openstack/barbican: Adding a new script  to generate mkek and hmac
*** chadlung has joined #openstack-barbican18:50
*** barra204_ is now known as shakamunyi18:52
*** chadlung has quit IRC18:55
*** crc32 has quit IRC19:10
chellygelreaperhulk, would love your opinion on the mkek/hmac generation script if you get the chance in the next few days.
*** rellerreller has quit IRC19:40
*** igueths has quit IRC19:45
*** openstack has joined #openstack-barbican20:04
*** chadlung has joined #openstack-barbican20:26
*** openstack has joined #openstack-barbican20:29
*** chadlung has quit IRC20:30
*** Kevin_Bishop has quit IRC20:40
*** SheenaG has quit IRC20:50
*** nelsnelson has quit IRC20:50
*** openstackgerrit has quit IRC20:59
*** openstackgerrit has joined #openstack-barbican21:00
*** chadlung has joined #openstack-barbican21:12
*** xaeth is now known as xaeth_afk21:13
*** SheenaG has joined #openstack-barbican21:25
*** shakamunyi has quit IRC21:26
*** openstack has joined #openstack-barbican21:30
*** openstackstatus has joined #openstack-barbican21:30
*** ChanServ sets mode: +v openstackstatus21:30
woodster_alee, there was an LBaaS discussion regarding validation of uploaded certificates so clients that later retrieve them don't have to validate them. I think the plan is to add this to Barbican, but rm_work was curious about the transport key feature...Barbican can't validate the cert data of course but it seems the receiving plugins that something21:31
woodster_worth including in the Python interface contract verbiage?21:31
rm_workwoodster_: for reference, we need to validate the whole package21:33
rm_workIE, is this cert valid, is this private key valid, does this private key match this cert21:33
rm_workand for intermediates, I guess that they are all actual certs21:34
rm_workwe can't validate the chain really21:34
rm_workit's not a simple task21:34
woodster_rm_work: ah, ok yeah that does make things a bit trickier if Barbican isn't generating the certs...but I think that is eventually where things will go for the 'typical' use case?21:34
rm_workwoodster_: MAYBE.21:35
rm_workI am not certain21:35
rm_workI feel like a lot of people will probably still have their own certs :/21:36
kfox1111We have a few wild card certs we will want to use.21:46
kfox1111some of them weren't cheep either. :/21:47
*** dimtruck is now known as zz_dimtruck21:53
kfox1111should I file a spec for the crud acl stuff we talked about?22:14
kfox1111also, are acl's supported on containers as well, or just secrets?22:14
*** pglass has quit IRC22:16
*** chadlung has quit IRC22:24
rm_workkfox1111: I hope containers, as that is how we plan to use them O_o22:56
rm_workthough would be good to hear for sure22:56
*** chadlung has joined #openstack-barbican23:08
*** SheenaG has quit IRC23:08
*** kfox1111 has quit IRC23:09
*** kfox1111 has joined #openstack-barbican23:09
*** chadlung has quit IRC23:15
*** SheenaG has joined #openstack-barbican23:16
kfox1111rm_work: So far, I've only heard them being discussed on secrets. getting a little worried about it. :/23:24
*** chadlung has joined #openstack-barbican23:31
openstackgerritArun Kant proposed openstack/barbican-specs: Spec for adding audit capability using CADF specification.
*** SheenaG has quit IRC23:37

Generated by 2.14.0 by Marius Gedminas - find it at!