[all][tc][goals] Migrate RBAC Policy Format from JSON to YAML: Week R-16 Update

Sean Mooney smooney at redhat.com
Wed Jan 20 13:01:11 UTC 2021


On Wed, 2021-01-20 at 00:25 +0100, Thomas Goirand wrote:
> On 1/19/21 9:04 PM, Ben Nemec wrote:
> > There was also a security concern with potentially having multiple
> > policy files and it not being clear which was in use. If someone
> > converted their JSON policy to YAML, but left the JSON one in place, it
> > could result in oslo.policy using the wrong one (or not the one they
> > expect). We decided it was better for each project to make a clean
> > switchover, which allows for things like upgrade checks that oslo.policy
> > couldn't have itself, than to try to handle it all in oslo.policy.
> 
> IMO, that's a downstream distro thing.
> 
> What I did in Debian (and for Victoria already) was having the postinst
> of each package to rename any existing policy.json into a disabled
> version. Here's an example with Cinder:
> 
> if [ -r /etc/cinder/policy.json ] ; then
>     mv /etc/cinder/policy.json /etc/cinder/disabled.policy.json.old
> fi
> 
> and then package the yaml file as (example from Nova):
> /etc/nova/policy.d/00_default_policy.yaml
> 
> and then setting-up this:
> policy_dirs = /etc/nova/policy.d
> 
> The reason I'm doing this way, is that I'm expecting upstream to
> generate a commented-only yaml file, and final users to drop non-default
> supplementary files without touching the package default file.
> 
> So, someone upgrading to Victoria with a non-default policy.json will
> see its manual tweaks go away, but not completely gone (ie: recoverable
> from disabled.policy.json.old).
> 
> Does this seem to be a correct approach?
that seams kind of dangorus to me
or at least unexpected
if i have custom policy and i upgrade i dont expect that to revert back to default policy.
if it does not exists autogeneratin a default policy.yaml with everything commented could work
but im not sure if that is better then leaving it blank and insted generating on in /usr/share/<project>/policy.yaml.example
i dont have a strong oppion on this approach beyond that really. i just find it unintuitve.
what you descibe i guess would make sense if you had the popup whwere it ask do you want to use teh package maintaners version
if you do that implictly without askign the user i would be concerned it will either break there production system if they had
replaxed the policy constarits or added new roles or worse expose capablities they had locked down.
so what ever you do make sure its telegraphed well.
> 
> Cheers,
> 
> Thomas Goirand (zigo)
> 





More information about the openstack-discuss mailing list