Open Stack

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.

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