Open Stack

Inline.

On Thu, Jun 4, 2015 at 6:40 AM, Sean Dague <sean at dague.net> wrote:

> On 06/04/2015 08:52 AM, Adam Young wrote:
> > 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.
>
> Um, I don't understand that.
>
> I'm saying that you'd "GET https://my.nova.api.server/policy"
>
> And it would return basically policy.json. There is no crawling every
> bit, this is a standard entry point to return a policy representation.
> Getting all services to implement this would mean that Keystone could
> support interesting policy things with arbitrary projects, not just a
> small curated list, which is going to be really important in a big tent
> world. Monasca and  Murano are just as important to support here as Nova
> and Swift.
>


Definitely agree it'd be great to have an API call that returns policy.
The question that I think Adam and I are trying to answer is how do
projects implement that call?  We've (perhaps implicitly) suggested 3
different options.

1. Have a data file called say 'default_policy.json' that the oslo-policy
engine knows how to use (and override with policy.json or whatever).  The
policy-API call that returns policy then just reads in this file and
returns it.

2. Hard-code the return value of the Python function that implements the
policy-API call.  Different options as to how to do this.

3. Write code that automatically generates the policy-API result by
analyzing the code that implements the rest of the API calls (like
create_vm, delete_vm) and extracting the policy that they implement.  This
would require hitting all code paths that implement policy, etc.

I'm guessing you had option (2) in mind.  Is that right?  Assuming that's
the case I see two possibilities.

a. The policy-API call is used internally by Nova to check that an API call
is permitted before executing it.  (I'm talking conceptually.  Obviously
you'd not go through http.)

b. The policy-API call is never used internally; rather, each of the other
API calls (like create-server, delete-server) just use arbitrary Python
logic to decide whether an API call is permitted or not.  This requires the
policy-API call implementation to be kept in sync manually with the other
API calls to ensure the policy-API call returns the actual policy.

I'd be happy with (a) and doubt the practicality of (b).

Tim




> 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 don't understand why having hard coded defaults makes things harder,
> as long as they are discoverable. Defaults typically make things easier,
> because people then only change what they need, instead of setting a
> value for everything, having the deployment code update, and making
> their policy miss an important thing, or make something wrong because
> they didn't update it correctly at the same time as code.
>
> > 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.
>
> 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. I'll be honest, if the only way to collaborate here is
> for every project to fully load all of keystone architecture into their
> heads, I think this effort is going to stall out. Which would suck.
>
> So maybe we need to step back and explain what the challenges are, what
> changes are expected at each step (for developers and operators), and
> err on the side of over explaining things so folks that are not familiar
> with all the nuances addressed here can still see the flow.
>
>         -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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150604/fda0316b/attachment.html>