Open Stack

On 08/25/2014 10:49 AM, Zane Bitter wrote:
> On 24/08/14 23:17, Adam Young wrote:
>> On 08/23/2014 02:01 AM, Clint Byrum wrote:
>>> I don't know how Zaqar does its magic, but I'd love to see simple 
>>> signed
>>> URLs rather than users/passwords. This would work for Heat as well. 
>>> That
>>> way we only have to pass in a single predictably formatted string.
>>>
>>> Excerpts from Zane Bitter's message of 2014-08-22 14:35:38 -0700:
>>>> Here's an interesting fact about Zaqar (the project formerly known as
>>>> Marconi) that I hadn't thought about before this week: it's 
>>>> probably the
>>>> first OpenStack project where a major part of the API primarily faces
>>
>>
>>
>> Nah, this is the direction we are headed.  Service users (out of LDAP!)
>> are going to be the norm with a recent feature add to Keytone:
>>
>>
>> http://adam.younglogic.com/2014/08/getting-service-users-out-of-ldap/
>
> Ah, excellent, thanks Adam. (BTW markup fail: "The naming of this file 
> is essential: keystone..conf [sic] is the expected form.")
If that is the worst typo in that article I consider that success.

>
> So this will solve the Authentication half of the problem. What is the 
> recommended solution for Authorisation?
>
> In particular, even if a service like Zaqar or Heat implements their 
> own authorisation (e.g. the user creating a Zaqar queue supplies lists 
> of the accounts that are allowed to read or write to it, 
> respectively), how does the user ensure that the service accounts they 
> create will not have access to other OpenStack APIs? IIRC the default 
> policy.json files supplied by the various projects allow non-admin 
> operations from any account with a role in the project.

There are things I want to implement to solve this.  Locking a token 
(and a trust) to a service and/or Endpoint is the primary thing. More 
finely grained roles.  Delegating operations instead of roles. 
Additional constraints on tokens.

Basically, I want the moon on a stick.

Keep asking.  I can't justify the effort to build this stuff until 
people show they need it.  Heat has been the primary driver for so much 
of Keystone already.

>
> thanks,
> Zane.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev