Open Stack

I am confused about the goal. Are we saying we should allow operators to modify the access policies but then warn them if they do? But if operators *intend* to modify the policies in order to fit their compliance/security needs, which is likely the case, aren't the warning messages confusing and counterintuitive?


Guang


-----Original Message-----
From: Sean Dague [mailto:sean at dague.net] 
Sent: Thursday, June 04, 2015 10:16 AM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] Dynamic Policy for Access Control Subteam Meeting

On 06/04/2015 01:03 PM, Adam Young wrote:
> On 06/04/2015 09:40 AM, Sean Dague wrote:
>> So I feel like I understand the high level dynamic policy end game. I 
>> feel like what I'm proposing for policy engine with encoded defaults 
>> doesn't negatively impact that. I feel there is a middle chunk where 
>> perhaps we've got different concerns or different dragons that we 
>> see, and are mostly talking past each other. And I don't know how to 
>> bridge that. All the keystone specs I've dived into definitely assume 
>> a level of understanding of keystone internals and culture that 
>> aren't obvious from the outside.
> 
> Policy is not currently designed to be additive;  let's take the Nova 
> rule||
> ||
> ||"get_network": "rule:admin_or_owner or rule:shared or rule:external 
> ||or
> rule:context_is_advsvc"||
> ||
> |FROM
> http://git.openstack.org/cgit/openstack/neutron/tree/etc/policy.json#n
> 27|
> ||
> |This pulls in |
> 
> "external": "field:networks:router:external=True",
> |
> Now, we have a single JSON file that implements this. Lets say that 
> you ended up coding exactly this rule in python. What would that mean?
> Either you make some way of initializing oslo.policy from a Python 
> object, or you enforce outside of Oslo.policy (custom nova Code).  If 
> it is custom code, you  have to say "run oslo or run my logic"
> everywhere...you can see that this approach leads to fragementation of 
> policy enforcement.
> 
> So, instead, you go the "initialize oslo from Python."  We currentl 
> have the idea of multiple policy files in the directory, so you just 
> treat the Python code as a file with either the lowest or highest ABC 
> order, depending.  Now, each policy file gets read, and the rules are 
> a hashtable, keyed by the rule name.  So both get_network and external 
> are keys that get read in.  If 'overwrite' is set, it will only 
> process the last set of rules (replaces all rules)  but I think what 
> we want here is just update:
> 
> http://git.openstack.org/cgit/openstack/oslo.policy/tree/oslo_policy/p
> olicy.py#n361 Which would mix together the existing rules with the 
> rules from the policy files.
> 
> 
> So...what would your intention be with hardcoding the policy in Nova? 
> That your rule gets overwritten with the rule that comes from the 
> centralized policy store, or that you rule gets executed in addition 
> to the rule from central?  Neither are going to get you what you want, 
> which is "Make sure you can't break Nova by changing Policy"

It gets overwritten by the central store.

And you are wrong, that gives me what I want, because we can emit a WARNING in the logs if the patch is something crazy. The operators will see it, and be able to fix it later.

I'm not trying to prevent people from changing their policy in crazy ways. I'm trying to build in some safety net where we can detect it's kind of a bad idea and emit that information a place that Operators can see and sort out later, instead of pulling their hair out.

But you can only do that if you have encoded what's the default, plus annotations about ways that changing the default are unwise.

	-Sean

--
Sean Dague
http://dague.net

__________________________________________________________________________
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