Open Stack

On 06/11/2015 05:35 PM, Salvatore Orlando wrote:
> I am not able to say whether this works for Nova. Surely works for 
> Neutron - from a functional perspective at least.
>
> I still don't know however whether this choice is the best way to 
> proceed, and perhaps you can help me understand better.
>
> Role checks are always expressed through policy.json and can be 
> enforced in middleware. Does this mean that there is also a 
> centralized policy.json, or will we keep per-project policy files even 
> for role checks?
The focus of the centralized policy has always been the role 
management.  I don't propose changing course on that.  We want the role 
names to be consistant across all the projects.

I see the starting lapproach being that users get one of two roles by 
default;  Administrator or Member.  While these will still be scoped to 
the project, only the role assignment itself would be checked by the 
dynamic policy.  The scope would be checked by static policy.

>
> Scope checks - ie: application-specific checks - can be enforced in 
> any way the application developers wish. They can use policy.json, be 
> hardcoded or, if they wish ask Pythia, the Oracle of Delphi. From an 
> operator perspective, this means that every project can enforce 
> policies in a different way. Is this going to be practical and 
> maintainable? I can't speak for operators, but I would like to 
> understand a bit better what this implies for them.

If the project already has logic doing the policy check using oslo, and 
they want to keep using oslo, they can do so.  Relaly,only Keystone has 
any deep need to do so.  The rules that I saw in Nova were simple enough 
that they could be checked in oslo or with simple python code.  The 
limiting thing here is that the object in the database needs to be 
checked against the scope anyway;  it doesn't matter if the scope on my 
token matches the scope on my roject as specified in the URL, if the 
object fetched back does not belong to that project.  How this check is 
done differes from project to project, it is just essential that the 
check be done.

For a project that is not doing the check, and needs to start doing so, 
it probably makes sense to use oslo.policy.


Thanks for the questions



>
> Salvatore
>
>
>
>
>
>
>
> On 11 June 2015 at 17:47, Adam Young <ayoung at redhat.com 
> <mailto:ayoung at redhat.com>> wrote:
>
>     Sean had a really good point when he mentioned that the Developers
>     know what need to be enforced, and I think this is why he
>     suggested that the base policy implementation be in Python code,
>     not the policy JSON DSL.
>
>     The main thrust of the dynamic policy has been to get the
>     role-to-api assignment more flexible.  However, there is another
>     side to each policy rule; figureing out where the project (nee'
>     tenant) id is in the request;  is it part of the URL, part of the
>     request body, or in the object returned from the database.  This
>     part really should be handled by the developer working on the
>     policy rule, and it should not be changed.
>
>     So...what if we say that we split policy into two checks; a role
>     check, and a scope check.  Both checks must pass in order for the
>     user to get access to the API.  The Scope check is not going to be
>     dynamic;  once set, they will pretty much stay set.   It might be
>     done using the policy.json, or done in code, but it will be
>     separate from the role check.
>
>
>     The Neutron policy checks for things like
>
>     |"shared": "field:networks:shared=True", "shared_firewalls":
>     "field:firewalls:shared=True", "shared_firewall_policies":
>     "field:firewall_policies:shared=True", "shared_subnetpools":
>     "field:subnetpools:shared=True",
>
>     Would be handled by the dev teams later policy check; anything
>     that requires actually fetching the object from the database is
>     postponed to this stage.
>     |
>
>
>
>     The role check will come from the policy.json file.  This will
>     allow the operator to fine tune how roles are handled.  Any thing
>     else that can be explicitly checked based on the token will be
>     fair game, but not API specific values;  no database fetch will be
>     performed at this point.  The assumption is that this policy check
>     could be generic enough to be performed in middleware, and might
>     even be enforced based on the URL instead of the pseudo random
>     namespacing we do now.
>
>     Does this suggestion work for Nova?  I think it will make the
>     overall policy much easier to maintain in the field.
>
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150611/a26a3a5a/attachment.html>