On 06/04/2015 06:32 AM, Sean Dague wrote:
On 06/03/2015 08:40 PM, Tim Hinrichs wrote:
As long as there's some way to get the *declarative* policy from the
system (as a data file or as an API call) that sounds fine. But I'm
dubious that it will be easy to keep the API call that returns the
declarative policy in sync with the actual code that implements that policy.
Um... why? Nova (or any other server project) needs to know what the
currently computed policy is to actually enforce it internally. Turning
around and spitting that back out on the wire is pretty straight forward.
Is there some secret dragon I'm missing here?
No. But it is a significant bit of coding to do; you would need to
crawl every API and make sure you hit every code path that could enforce
policy. However, I've contemplated doing something like that with
oslo.policy already; run a workload through a server with policy
non-enforcing (Permissive mode) and log the output to a file, then use
that output to modify either the policy or the delegations (role
assignments or trusts) used in a workflow.
The Hard coded defaults worry me, though. Nova is one piece (a big one,
admittedly) of a delicate dance across multiple (not-so-micro) services
that make up OpenStack. Other serivces are going to take their cue from
what Nova does, and that would make the overall flow that much harder to
maintain.
I think we need to break some very ingrained patterns in out policy
enforcement. I would worry that enforcing policy in code would give us
something that we could not work around. Instead, I think we need to
ensure that the Nova team leads the rest of the OpenStack core services
in setting up best practices, and that is primarily a communication
issue. Getting to a common understanding of RBAC, and making it clear
how roles are modified on a per-api basis will make Nova more robust.
-Sean
Tim
On Wed, Jun 3, 2015 at 1:53 PM, Doug Hellmann <d...@doughellmann.com
<mailto:d...@doughellmann.com>> wrote:
Excerpts from Sean Dague's message of 2015-06-03 13:34:11 -0400:
> On 06/03/2015 12:10 PM, Tim Hinrichs wrote:
> > I definitely buy the idea of layering policies on top of each other.
> > But I'd worry about the long-term feasibility of putting default
> > policies into code mainly because it ensures we'll never be able to
> > provide any tools that help users (or other services like
Horizon) know
> > what the effective policy actually is. In contrast, if the code
is just
> > an implementation of the API, and there is some (or perhaps several)
> > declarative description(s) of which of those APis are permitted
to be
> > executed by whom, we can build tools to analyze those policies. Two
> > thoughts.
> >
> > 1) If the goal is to provide warnings to the user about
questionable API
> > policy choices, I'd suggest adding policy-analysis functionality
to say
> > oslo_policy. The policy-analysis code would take 2 inputs: (i) the
> > policy and (ii) a list of policy properties, and would generate a
> > warning if any of the properties are true for the given policy.
Then
> > each project could provide a file that describes which policy
properties
> > are questionable, and anyone wanting to see the warnings run the
> > functionality on that project's policy and the project's policy
property
> > file.
> >
> > It would definitely help me if we saw a handful of examples of the
> > warnings we'd want to generate.
>
> WARN: "server create permissions have been restricted from the
default,
> this may impede operation and interoperability of your OpenStack
> installation"
>
> > 2) If the goal is to provide sensible defaults so the system
functions
> > if there's no policy.json (or a dynamic policy cached from
Keystone),
> > why not create a default_policy.json file and use that whenever
> > policy.json doesn't exist (or more precisely to use policy.json to
> > override default_policy.json in some reasonable way).
>
> Because it's still a file, living in /etc. Files living in etc are
> things people feel they can modify. They are also things that don't
> always get deployed correctly with code deploys. People might not
> realize that default_policy.json is super important to be updated
every
> time the code is rolled out.
It doesn't have to live in /etc, though. It could be packaged in the
nova code namespace as a data file, and accessed from there.
Doug
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
