Open Stack

On 06/04/2015 12:12 PM, Tim Hinrichs wrote:
> Inline.
> 
> On Thu, Jun 4, 2015 at 6:40 AM, Sean Dague <sean at dague.net
> <mailto: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).

Right, I'm thinking 2 (a). There is some engine internally (presumably
part of oslo.policy) where we can feed it sources in order (sources
could be code structures or files on disk, we already support multi file
with current oslo.policy and incubator code):

  Base + Patch1 + Patch2 + ...

  policy.add(Base)
  policy.add(Patch1)
  policy.add(Patch2)

You can then call:

  policy.enforce(context, rulename, ...) like you do today, it knows
what it's doing.

And you can also call:

  for_export = policy.export()

To dump the computed policy back out. Which is a thing that doesn't
exist today. The "GET /policy" would just build the same policy engine,
which computes the final rule set, and exports it.

The bulk of the complicated code would be in oslo.policy, so shared.
Different projects have different wsgi stacks, so will have a bit of
different handling code for the request, but the fact that all the
interesting payload is a policy.export() means the development overhead
should be pretty minimal.

	-Sean

-- 
Sean Dague
http://dague.net