[RFE] Policy values should be as flexible as they look

[Jeremy Freudberg]

I have a (slightly imaginary) deployment in which I want to allow some service user to get information about networks belonging to other projects, but I don't want this user to be the admin of the entire Neutron.

To satisfy that requirement, I took a look in policy.json and found the following default entry:

"get_network": "rule:admin_or_owner or rule:shared or rule:external or rule:context_is_advsvc"

First I tried the following redefinition, with no success:
"get_network": "rule:admin_or_owner or rule:shared or rule:external or rule:context_is_advsvc or rule:some_new_rule"

I also tried the following redefinitions in the policy file, but with no effect:
"external": "field:networks:router:external=False" (formerly True)
"get_network": "rule:some_new_rule"

Redefining these policies as below did thankfully have the correct effect:
"context_is_admin": "role:admin or user_name:neutron or rule:some_new_rule"
"context_is_advsvc": "role:advsvc or rule:some_new_rule",

So from all these observations it turns out that, at least from my experience, this policy file entry is not interpreted in a totally meaningful way.

To summarize:
- It seems like the list of the four checks for "get_network" ('admin or owner', 'external', 'shared', and 'advsvc') are essentially hard-coded and that this list of checks cannot be expanded by policy file.
- The definitions of the 'external' and 'shared' checks cannot be redefined by policy file entries -- they are also essentially hardcoded
- The definitions of the 'advsvc' and 'admin' checks can be successfully redefined by policy file -- because they are not hardcoded, see [0], [1]

For my own use case mentioned at the beginning of the bug report, the 'advsvc' policy feature basically accomplishes what I want. (I can redefine the 'advsvc' rule to be reflective of my own custom roles.) Very interestingly, when I remove the 'advsvc' statements from the port policy definitions, those changes are actually respected.

[0] https://github.com/openstack/neutron-lib/blob/master/neutron_lib/context.py#L51
[1] https://github.com/openstack/neutron-lib/blob/master/neutron_lib/_policy.py#L50

[Armando Migliaccio (armando-migliaccio)]

I'd suggest to check out how Octavia+Neutron work and the respective policy.json configurations are, because if I understand your use case correctly, it should be quite similar to it. That's what rule:context_is_advsvc was built for. I can do some digging as there might be something missing in your policy.json.

Point taken that the handling of policy.json is a bit obscure, but that's one of those neutron things that have been hardly touched in ages and even though it's been extensively covered by unit testing, there may be a remote chance things might have been regressed.

[Jeremy Freudberg (jfreud)]

I'll have to play around with context_is_advsvc ... it seems pretty close to what i want. The only thing that would have to be different is that I don't want to give out those port-management permissions.

I'll see if removing rule:context_is_advsvc from the *_port policy.json entries is actually effective. If it is in fact effective, my own deployment case is solved. But we should still keep the bug open in some form because it seems like there still is some validity to my original reported issue.

[Armando Migliaccio (armando-migliaccio)]

OK great, thanks!

Can you re-elaborate on your initial issue reporting steps to repro/expected results and observed ones?