Open Stack

On 05/15/2015 09:56 AM, Zane Bitter wrote:
> On 14/05/15 23:38, Adam Young wrote:
>>> So the mechanisms are there. In the short term we'd need some
>>> cross-project co-operation to define a system through which we can do
>>> this across projects (i.e. Murano or any other service can create a
>>> user and have Zaqar authorise it for listening on a particular queue).
>>> Maybe this is an extra parameter when creating a queue in Zaqar to
>>> also create a user account in a separate domain (the way Heat does)
>>> with permission to send and/or receive only on that particular queue
>>> and return its credentials. That would be easier to secure and easier
>>> to implement than having other services create the user accounts
>>> themselves.
>>
>> I think the user accounts (or consumers as oauth calls them) should be
>> cheap, and easy to create .  I see no reason to try to limit them.
>> Ideally, we would use something like X509 in order for them to talk to
>> Keystone;  that work is under way in Keystone already. Kerberos works
>> for those who want to use it with a Keytab.
>
> I was talking about a short term solution to follow Heat's existing 
> practices, without any changes in Keystone. It'd be much easier for 
> Zaqar to say 'here is your queue, and here is the user I created that 
> is already correctly authorised for it' than it would be for every 
> service to have its own separate Keystone domain to set up and for 
> them all to have to learn how to create users in it and then to pass 
> the user to Zaqar when creating the queue to set up the authorisation.
>
> If you're saying that Keystone already supports, or will soon support, 
> what we need to do by using OAuth then I'm *more* than happy to dump 
> this idea and move straight to that.

Think of OAuth as a more standard API, and the Domains as the 
impklementation.  There is 0 difference in capability, but oauth is a 
(sorta) standard and Keystone is not.

In oauth, all consumers go into a single table.  We could replicate that 
by putting all of these service users in  a single  domain.

>
>>> In the medium term hopefully we'll be able to come up with a less
>>> hacky solution that uses Oslo libraries to manage all of the user
>>> creation and authorisation.
>>
>> Why Oslo oand not Keystone?  Why do we need a new abstraction?
>
> Again, if Keystone does everything we need then I agree there's no 
> problem to solve here.
Good.  I'd rather keep this stuff in a single place.  Oslo is good for 
things that are cross cutting concerns, which means that sometimes there 
are unclear boundaries between that goes ther and what goes into 
Keystone.  Poliocy is a good example:  the generic rules engine goes 
into Osol.  The use of that engine for access control stays with Keystone.
>
>>>> It will be interesting to discuss this with Keystone team. What is 
>>>> it is
>>>> possible to have a token which is restricted to be authenticated to
>>>> specific API URL like  GET /v1/queues/<queue-id>/
>>>
>>> Yes, we should definitely discuss this with the Keystone team and make
>>> sure they're getting feedback from all of the many groups who need it
>>> so that they can prioritise the work appropriately :)
>>>
>>
>> Endpoint binding of tokens is proposed already.  I have a spec out for
>> more constraints.  We need a way to annotate them in the token, and then
>> policy can certainly be enforced on any data in the token.
>
> This is OAuth tokens?
Nope, all tokens.  OAuth ends up with a keystone token, too.
>
> In the existing world of expiring bearer tokens I think we'd probably 
> need application servers to hold their own auth credentials, not just 
> a token, so they can keep refreshing it. Which implies that the 
> scoping should be on the user, not the token.

Agreed. A service user to shadow the real user is the right 
abstraction;  it has its own credentials, and limited scope of access.

> It's kind of unfortunate IMHO that the default policy.json files tend 
> to give all users access to non-admin APIs, rather than requiring a 
> specific role (like "Member"). 
Working on that.  Come to my policy session!


> Although that's kind of counterbalanced by the fact that when you 
> create users, it has to be in a separate domain with its own separate 
> tenant anyway, and right now the application has to do its own mapping 
> between tenants in different domains to know whom to trust (at least, 
> this is how Heat currently does it).

Yes.  Let's work through the use cases here, and see what we can propose.
>
> If OAuth makes all of these problems go away, then +1000 from me :)
No silver bullet. sorry.
>
>> I suspect that what we will have is a two pass policy check;  the first
>> will be all global options (endpoint binding, etc) and the second will
>> be API specific checks.
>
> That makes sense to me.
>
> cheers,
> Zane.
>
> __________________________________________________________________________ 
>
> 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