Open Stack

On Thu, May 18, 2017 at 8:45 AM, Sean Dague <sean at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170518/91f8b35c/attachment.html>