On Thu, May 18, 2017 at 8:45 AM, Sean Dague <[email protected]> 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
