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.


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

Reply via email to