Open Stack

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 <doug at doughellmann.com
>> <mailto:doug at 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-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
>>
>