<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 18, 2017 at 8:45 AM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 05/18/2017 09:27 AM, Doug Hellmann wrote:<br>
> Excerpts from Adrian Turjak's message of 2017-05-18 13:34:56 +1200:<br>
><br>
>> Fully agree that expecting users of a particular cloud to understand how<br>
>> the policy stuff works is pointless, but it does fall on the cloud<br>
>> provider to educate and document their roles and the permissions of<br>
>> those roles. I think step 1 plus some basic role permissions for the<br>
><br>
> Doesn't basing the API key permissions directly on roles also imply that<br>
> the cloud provider has to anticipate all of the possible ways API keys<br>
> might be used so they can then set up those roles?<br>
<br>
</span>Not really. It's not explicit roles, it's inherited ones. At some point<br>
an adminstrator gave a user permission to do stuff (through roles that<br>
may be site specific). Don't care how we got there. The important thing<br>
is those are cloned to the APIKey, otherwise, the APIKey litterally<br>
would not be able to do anything, ever. Discussing roles here was an<br>
attempt to look at how internals would work today, though it's<br>
definitely not part of contract of this new interface.<br>
<br>
There is a lot more implicitness in what roles mean (see<br>
<a href="https://bugs.launchpad.net/keystone/+bug/968696" rel="noreferrer" target="_blank">https://bugs.launchpad.net/<wbr>keystone/+bug/968696</a>) which is another reason<br>
I'm really skeptical that we should have roles or policy points in the<br>
APIKey interface. Describing what they do in any particular installation<br>
is a ton of work. And you thought ordering a Medium coffee at Starbucks<br>
was annoying. :)<br>
<br>
The important thing is to make a clear and expressive API with the user<br>
so they can be really clear about what they expect a thing should do.<br>
<span class="gmail-"><br>
>> Keys with the expectation of operators to document their roles/policy is<br>
>> a safe enough place to start, and for us to document and set some<br>
>> sensible default roles and policy. I don't think we currently have good<br>
><br>
> This seems like an area where we want to encourage interoperability.<br>
> Policy doesn't do that today, because deployers can use arbitrary<br>
> names for roles and set permissions in those roles in any way they<br>
> want. That's fine for human users, but doesn't work for enabling<br>
> automation. If the sets of roles and permissions are different in<br>
> every cloud, how would anyone write a key allocation script that<br>
> could provision a key for their application on more than one cloud?<br>
<br>
</span>So, this is where there are internals happening distinctly from user<br>
expressed intent.<br>
<br>
POST /apikey {}<br>
<br>
Creates an APIKey, in the project the token is currently authed to, and<br>
the APIKey inherits all the roles on that project that the user<br>
currently has. The user may or may not even know what these are. It's<br>
not a user interface.<br></blockquote><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>[0] <a href="https://www.lbragstad.com/blog/keystone-pike-ptg-summary">https://www.lbragstad.com/blog/keystone-pike-ptg-summary</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The contract is "Give me an APIKey that can do what I do*" (* with the<br>
exception of self propogating, i.e. the skynet exception).<br>
<br>
That's iteration #1. APIKey can do what I can do.<br>
<br>
Iteration #2 is fine grained permissions that make it so I can have an<br>
APIKey do far less than I can do.<br>
<span class="gmail-im gmail-HOEnZb"><br>
        -Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>
<br>
</span><div class="gmail-HOEnZb"><div class="gmail-h5">______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>