| *** SheenaG has quit IRC | 00:13 | |
| *** SheenaG has joined #openstack-barbican | 00:15 | |
| *** gyee has quit IRC | 00:18 | |
| *** kebray has quit IRC | 00:19 | |
| *** dimtruck is now known as zz_dimtruck | 00:20 | |
| *** arunkant_ has quit IRC | 00:22 | |
| *** SheenaG has quit IRC | 00:24 | |
| *** gyee has joined #openstack-barbican | 00:25 | |
| *** kfox1111 has quit IRC | 00:38 | |
| *** dave-mccowan has joined #openstack-barbican | 01:04 | |
| *** gyee is now known as operator99 | 03:06 | |
| *** barra204 has quit IRC | 03:11 | |
| *** barra204 has joined #openstack-barbican | 03:13 | |
| *** dave-mcc_ has joined #openstack-barbican | 05:05 | |
| *** dave-mccowan has quit IRC | 05:08 | |
| *** tkelsey has joined #openstack-barbican | 05:51 | |
| *** tkelsey has quit IRC | 05:56 | |
| *** woodster_ has quit IRC | 06:50 | |
| *** nickrmc83 has joined #openstack-barbican | 07:00 | |
| *** tkelsey has joined #openstack-barbican | 08:25 | |
| *** tkelsey has quit IRC | 11:09 | |
| *** tkelsey has joined #openstack-barbican | 11:11 | |
| *** darrenmoffat has quit IRC | 11:39 | |
| *** darrenmoffat has joined #openstack-barbican | 11:39 | |
| *** nickrmc83 has quit IRC | 12:03 | |
| *** kfarr has joined #openstack-barbican | 12:16 | |
| *** woodster_ has joined #openstack-barbican | 12:50 | |
| *** rellerreller has joined #openstack-barbican | 12:52 | |
| openstackgerrit | Merged openstack/barbican-specs: Drop incubating theme from docs https://review.openstack.org/186191 | 13:50 |
|---|---|---|
| *** nelsnelson has joined #openstack-barbican | 14:08 | |
| openstackgerrit | Ade Lee proposed openstack/barbican: Added Certificate API Docs and Quick Start Guides https://review.openstack.org/186771 | 14:23 |
| *** pglass has joined #openstack-barbican | 14:26 | |
| *** rellerreller has quit IRC | 14:30 | |
| *** kebray has joined #openstack-barbican | 14:36 | |
| *** kebray has quit IRC | 14:37 | |
| alee | woodster_, so is there anything controversial in the acl docs? | 14:37 |
| *** rellerreller has joined #openstack-barbican | 14:37 | |
| *** kebray has joined #openstack-barbican | 14:37 | |
| *** nkinder has quit IRC | 14:38 | |
| *** xaeth_afk is now known as xaeth | 14:39 | |
| *** igueths has joined #openstack-barbican | 15:05 | |
| *** rellerreller has quit IRC | 15:15 | |
| *** rellerreller has joined #openstack-barbican | 15: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 (so | 15: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 dict | 15: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 |
| alee | woodster_, right I responded to that. Based on our discussion in Vancouver, it seems that there is always an ACL | 15:23 |
| alee | because we return a default ACL rather than an empty list | 15:24 |
| *** kfox1111 has joined #openstack-barbican | 15:25 | |
| kfox1111 | First stab at the nova instance user spec here: https://review.openstack.org/186617 | 15:26 |
| *** tkelsey has quit IRC | 15:34 | |
| openstackgerrit | Chelsea Winfree proposed openstack/barbican: Adding a new script to generate mkek and hmac https://review.openstack.org/186800 | 15:35 |
| chellygel | ^ WIP | 15:35 |
| alee | woodster_, chellygel - note - I added cert api docs - please review | 15:36 |
| arunkant | alee, 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 |
| arunkant | alee, 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-barbican | 15: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 me | 15:43 |
| woodster_ | alee: will do | 15:43 |
| dhellmann | redrobot: 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 http://paste.openstack.org/show/245091/ -- Does that work for you? | 15:45 |
| dhellmann | redrobot: based on the change list there, the version will be 3.2.0 | 15:46 |
| redrobot | dhellmann sounds good. I asumme it'll be 3.1.2 ? | 15:46 |
| dhellmann | with the requirements changes and new features, it should be 3.2 | 15:46 |
| *** SheenaG has joined #openstack-barbican | 15:47 | |
| redrobot | dhellmann ok, sounds good. | 15:47 |
| dhellmann | redrobot: ok, I'll include that in my list on Monday -- thanks! | 15:47 |
| alee | arunkant, woodster_ sorry - I thought that we decided in vancouver to return "{project-access: True}" ? | 15:47 |
| redrobot | alee arunkant woodster_ yep, that's what I remember/wrote down. should not need 404s. | 15:50 |
| alee | arunkant, 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 |
| arunkant | alee: 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 dimtruck | 15:52 | |
| alee | arunkant, 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 |
| alee | and yeah - we'd likely need to return the same for write, list etc. | 15:54 |
| alee | for one thing, that will make the permissions model and defaults explicit | 15:54 |
| alee | arunkant, think of it this way -- secrets always have an effective acl, even if we don't set one. | 15:55 |
| alee | arunkant, from the clients point of view, why should they care if they originally set it explicitly or not? | 15:56 |
| kfox1111 | I like that. | 16:01 |
| kfox1111 | for the heat resource, I want to just delete/add users to an acl. not care that it doesn't exist yet. | 16:01 |
| arunkant | alee: 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 barbican | 16:01 |
| redrobot | arunkant 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 |
| alee | arunkant, 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 IRC | 16:04 | |
| redrobot | arunkant 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 |
| alee | arunkant, we have defaults for many other parameters too. | 16:05 |
| arunkant | alee, 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 |
| alee | arunkant, thats an interesting point | 16:16 |
| alee | redrobot, woodster_ ^^ | 16:16 |
| alee | is it possible that project-access:True will not be the default response for a particular deployment? | 16:17 |
| kfox1111 | question, 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 |
| kfox1111 | As 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 |
| redrobot | kfox1111 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 |
| kfox1111 | I wouldn't be able to relaunch vm's that go bad. :/ | 16:29 |
| kfox1111 | ah. so thats still basically just project level acl's. that's ok. | 16:29 |
| redrobot | kfox1111 some contributors were unhappy with this workflow, and pushed for this feature to work around the way Keystone provides authorization. | 16:30 |
| kfox1111 | I 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 |
| redrobot | kfox1111 no, the project admin(s) can still edit the secret. | 16:30 |
| redrobot | kfox1111 including removing/modifying the acl | 16:30 |
| kfox1111 | ok. cool. | 16:31 |
| alee | kfox1111, 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 |
| kfox1111 | ok. 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 IRC | 16:34 | |
| *** Kevin_Bishop has joined #openstack-barbican | 16:54 | |
| *** kebray has joined #openstack-barbican | 17:09 | |
| hockeynut | hockeynut is going to be afk this afternoon but I'll be back on tonight and over the weekend. | 17:18 |
| hockeynut | <click> | 17:18 |
| *** kebray has quit IRC | 17:22 | |
| *** barra204 has quit IRC | 17:26 | |
| *** kebray has joined #openstack-barbican | 17:29 | |
| *** kebray has quit IRC | 17:40 | |
| *** chadlung has joined #openstack-barbican | 17:53 | |
| *** kebray has joined #openstack-barbican | 18:07 | |
| *** barra204 has joined #openstack-barbican | 18:09 | |
| *** kebray has quit IRC | 18:12 | |
| *** kebray has joined #openstack-barbican | 18:12 | |
| *** barra204 has quit IRC | 18:15 | |
| *** barra204 has joined #openstack-barbican | 18:20 | |
| *** crc32 has joined #openstack-barbican | 18:24 | |
| *** barra204_ has joined #openstack-barbican | 18:28 | |
| *** crc32 has quit IRC | 18:30 | |
| *** crc32 has joined #openstack-barbican | 18:30 | |
| *** barra204 has quit IRC | 18:31 | |
| *** crc32 has quit IRC | 18:35 | |
| *** chadlung has quit IRC | 18:38 | |
| *** xaeth is now known as xaeth_afk | 18:39 | |
| *** crc32 has joined #openstack-barbican | 18:40 | |
| *** xaeth_afk is now known as xaeth | 18:46 | |
| openstackgerrit | Chelsea Winfree proposed openstack/barbican: Adding a new script to generate mkek and hmac https://review.openstack.org/186800 | 18:49 |
| *** chadlung has joined #openstack-barbican | 18:50 | |
| *** barra204_ is now known as shakamunyi | 18:52 | |
| *** chadlung has quit IRC | 18:55 | |
| *** crc32 has quit IRC | 19:10 | |
| chellygel | reaperhulk, would love your opinion on the mkek/hmac generation script if you get the chance in the next few days. https://review.openstack.org/#/c/186800/ | 19:31 |
| chellygel | :) | 19:31 |
| *** rellerreller has quit IRC | 19:40 | |
| *** igueths has quit IRC | 19:45 | |
| *** openstack has joined #openstack-barbican | 20:04 | |
| *** chadlung has joined #openstack-barbican | 20:26 | |
| *** openstack has joined #openstack-barbican | 20:29 | |
| *** chadlung has quit IRC | 20:30 | |
| *** Kevin_Bishop has quit IRC | 20:40 | |
| *** SheenaG has quit IRC | 20:50 | |
| *** nelsnelson has quit IRC | 20:50 | |
| *** openstackgerrit has quit IRC | 20:59 | |
| *** openstackgerrit has joined #openstack-barbican | 21:00 | |
| *** chadlung has joined #openstack-barbican | 21:12 | |
| *** xaeth is now known as xaeth_afk | 21:13 | |
| *** SheenaG has joined #openstack-barbican | 21:25 | |
| *** shakamunyi has quit IRC | 21:26 | |
| *** openstack has joined #openstack-barbican | 21:30 | |
| *** openstackstatus has joined #openstack-barbican | 21:30 | |
| *** ChanServ sets mode: +v openstackstatus | 21: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 could...is that something | 21:31 |
| woodster_ | worth including in the Python interface contract verbiage? | 21:31 |
| rm_work | woodster_: for reference, we need to validate the whole package | 21:33 |
| rm_work | IE, is this cert valid, is this private key valid, does this private key match this cert | 21:33 |
| rm_work | and for intermediates, I guess that they are all actual certs | 21:34 |
| rm_work | we can't validate the chain really | 21:34 |
| rm_work | it's not a simple task | 21: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_work | woodster_: MAYBE. | 21:35 |
| rm_work | I am not certain | 21:35 |
| rm_work | I feel like a lot of people will probably still have their own certs :/ | 21:36 |
| kfox1111 | We have a few wild card certs we will want to use. | 21:46 |
| kfox1111 | some of them weren't cheep either. :/ | 21:47 |
| *** dimtruck is now known as zz_dimtruck | 21:53 | |
| kfox1111 | should I file a spec for the crud acl stuff we talked about? | 22:14 |
| kfox1111 | also, are acl's supported on containers as well, or just secrets? | 22:14 |
| *** pglass has quit IRC | 22:16 | |
| *** chadlung has quit IRC | 22:24 | |
| rm_work | kfox1111: I hope containers, as that is how we plan to use them O_o | 22:56 |
| rm_work | though would be good to hear for sure | 22:56 |
| *** chadlung has joined #openstack-barbican | 23:08 | |
| *** SheenaG has quit IRC | 23:08 | |
| *** kfox1111 has quit IRC | 23:09 | |
| *** kfox1111 has joined #openstack-barbican | 23:09 | |
| *** chadlung has quit IRC | 23:15 | |
| *** SheenaG has joined #openstack-barbican | 23:16 | |
| kfox1111 | rm_work: So far, I've only heard them being discussed on secrets. getting a little worried about it. :/ | 23:24 |
| *** chadlung has joined #openstack-barbican | 23:31 | |
| openstackgerrit | Arun Kant proposed openstack/barbican-specs: Spec for adding audit capability using CADF specification. https://review.openstack.org/159938 | 23:34 |
| *** SheenaG has quit IRC | 23:37 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!