Open Stack

Andrew,

the idea is to shift existing RBAC implementation:
currently policy is enforced in the service (Nova, for instance)
against the result of token validation, which is, in general, an access 
check;
I'm thinking about performing policy enforcement along with access check
in a single operation and only if necessary -
not every operation is protected and requires token validation,
though now keystone middleware validates a token on every request.

AFAIK Nova is using some custom logic to change local policies at run-time,
so I assume there may be a benefit in dynamic centralized storage 
managed via API,
so that Horizon can even provide a UI for that.

There are many questions in the matter, and my main is:
if we do RBAC in OpenStack the best way?


On 21.09.2016 20:16, Andrew Laski wrote:
>
> On Wed, Sep 21, 2016, at 12:02 PM, Joshua Harlow wrote:
>> Andrew Laski wrote:
>>> However, I have asked twice now on the review what the benefit of doing
>>> this is and haven't received a response so I'll ask here. The proposal
>>> would add additional latency to nearly every API operation in a service
>>> and in return what do they get? Now that it's possible to register sane
>>> policy defaults within a project most operators do not even need to
>>> think about policy for projects that do that. And any policy changes
>>> that are necessary are easily handled by a config management system.
>>>
>>> I would expect to see a pretty significant benefit in exchange for
>>> moving policy control out of Nova, and so far it's not clear to me what
>>> that would be.
>> One way to do this is to setup something like etc.d or zookeeper and
>> have policy files be placed into certain 'keys' in there by keystone,
>> then consuming projects would 'watch' those keys for being changed (and
>> get notified when they are changed); the project would then reload its
>> policy when the other service (keystone) write a new key/policy.
>>
>> https://coreos.com/etcd/docs/latest/api.html#waiting-for-a-change
>>
>> or
>> https://zookeeper.apache.org/doc/r3.4.5/zookeeperProgrammers.html#ch_zkWatches
>>
>> or (pretty sure consul has something similar),
>>
>> This is pretty standard stuff folks :-/ and it's how afaik things like
>> https://github.com/skynetservices/skydns work (and more), and it would
>> avoid that 'additional latency' (unless the other service is adjusting
>> the policy key every millisecond, which seems sorta unreasonable).
> Sure. Or have Keystone be a frontend for ansible/puppet/chef/.... What's
> not clear to me in any of this is what's the benefit to having Keystone
> as a fronted to policy configuration/changes, or be involved in any real
> way with authorization decisions? What issue is being solved by getting
> Keystone involved?
>
>
>> -Josh
>>
>> __________________________________________________________________________
>> 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
> __________________________________________________________________________
> 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