I followed up with Sean in IRC [0]. My last note about rebuilding role assignment dynamically doesn't really make sense. I was approaching this from a different perspective.
[0] http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2017-05-18.log.html#t2017-05-18T15:20:32 On Thu, May 18, 2017 at 9:39 AM, Lance Bragstad <lbrags...@gmail.com> wrote: > > > On Thu, May 18, 2017 at 8:45 AM, Sean Dague <s...@dague.net> wrote: > >> On 05/18/2017 09:27 AM, Doug Hellmann wrote: >> > Excerpts from Adrian Turjak's message of 2017-05-18 13:34:56 +1200: >> > >> >> Fully agree that expecting users of a particular cloud to understand >> how >> >> the policy stuff works is pointless, but it does fall on the cloud >> >> provider to educate and document their roles and the permissions of >> >> those roles. I think step 1 plus some basic role permissions for the >> > >> > Doesn't basing the API key permissions directly on roles also imply that >> > the cloud provider has to anticipate all of the possible ways API keys >> > might be used so they can then set up those roles? >> >> Not really. It's not explicit roles, it's inherited ones. At some point >> an adminstrator gave a user permission to do stuff (through roles that >> may be site specific). Don't care how we got there. The important thing >> is those are cloned to the APIKey, otherwise, the APIKey litterally >> would not be able to do anything, ever. Discussing roles here was an >> attempt to look at how internals would work today, though it's >> definitely not part of contract of this new interface. >> >> There is a lot more implicitness in what roles mean (see >> https://bugs.launchpad.net/keystone/+bug/968696) which is another reason >> I'm really skeptical that we should have roles or policy points in the >> APIKey interface. Describing what they do in any particular installation >> is a ton of work. And you thought ordering a Medium coffee at Starbucks >> was annoying. :) >> >> The important thing is to make a clear and expressive API with the user >> so they can be really clear about what they expect a thing should do. >> >> >> Keys with the expectation of operators to document their roles/policy >> is >> >> a safe enough place to start, and for us to document and set some >> >> sensible default roles and policy. I don't think we currently have good >> > >> > This seems like an area where we want to encourage interoperability. >> > Policy doesn't do that today, because deployers can use arbitrary >> > names for roles and set permissions in those roles in any way they >> > want. That's fine for human users, but doesn't work for enabling >> > automation. If the sets of roles and permissions are different in >> > every cloud, how would anyone write a key allocation script that >> > could provision a key for their application on more than one cloud? >> >> So, this is where there are internals happening distinctly from user >> expressed intent. >> >> POST /apikey {} >> >> Creates an APIKey, in the project the token is currently authed to, and >> the APIKey inherits all the roles on that project that the user >> currently has. The user may or may not even know what these are. It's >> not a user interface. >> > > If we know the user_id and project_id of the API key, then can't we build > the roles dynamically whenever the API key is used (unless the API key is > scoped to a single role)? This is the same approach we recently took with > token validation because it made the revocation API sub-system *way* > simpler (i.e. we no longer have to write revocation events anytime a role > is removed from a user on a project, instead the revocation happens > naturally when the token is used). Would this be helpful from a "default > open" PoV with API keys? > > We touched on blacklisting certain operations a bit in Atlanta at the PTG > (see the API key section) [0]. I attempted to document it shortly after the > PTG, but some of those statement might be superseded at this point. > > > [0] https://www.lbragstad.com/blog/keystone-pike-ptg-summary > > >> >> The contract is "Give me an APIKey that can do what I do*" (* with the >> exception of self propogating, i.e. the skynet exception). >> >> That's iteration #1. APIKey can do what I can do. >> >> Iteration #2 is fine grained permissions that make it so I can have an >> APIKey do far less than I can do. >> >> -Sean >> >> -- >> Sean Dague >> http://dague.net >> >> ____________________________________________________________ >> ______________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
