<div dir="ltr">Inline.<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 4, 2015 at 6:40 AM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><span class="">On 06/04/2015 08:52 AM, Adam Young wrote:<br>
> On 06/04/2015 06:32 AM, Sean Dague wrote:<br>
>> On 06/03/2015 08:40 PM, Tim Hinrichs wrote:<br>
>>> As long as there's some way to get the *declarative* policy from the<br>
>>> system (as a data file or as an API call) that sounds fine.  But I'm<br>
>>> dubious that it will be easy to keep the API call that returns the<br>
>>> declarative policy in sync with the actual code that implements that<br>
>>> policy.<br>
>> Um... why? Nova (or any other server project) needs to know what the<br>
>> currently computed policy is to actually enforce it internally. Turning<br>
>> around and spitting that back out on the wire is pretty straight forward.<br>
>><br>
>> Is there some secret dragon I'm missing here?<br>
><br>
> No.  But it is a significant bit of coding to do;  you would need to<br>
> crawl every API and make sure you hit every code path that could enforce<br>
> policy.<br>
<br>
</span>Um, I don't understand that.<br>
<br>
I'm saying that you'd "GET <a href="https://my.nova.api.server/policy" target="_blank">https://my.nova.api.server/policy</a>"<br>
<br>
And it would return basically policy.json. There is no crawling every<br>
bit, this is a standard entry point to return a policy representation.<br>
Getting all services to implement this would mean that Keystone could<br>
support interesting policy things with arbitrary projects, not just a<br>
small curated list, which is going to be really important in a big tent<br>
world. Monasca and  Murano are just as important to support here as Nova<br></div>
and Swift.<br></blockquote><div><br></div><div><br>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.<br><br></div><div>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.  <br><br></div><div>2. Hard-code the return value of the Python function that implements the policy-API call.  Different options as to how to do this.  <br><br></div><div>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.<br></div><div><br></div><div>I'm guessing you had option (2) in mind.  Is that right?  Assuming that's the case I see two possibilities.<br><br></div><div>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.)<br><br></div><div>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.<br><br></div><div>I'd be happy with (a) and doubt the practicality of (b).<br><br></div><div>Tim<br></div><div><br><br></div><div><br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> However, I've contemplated doing something like that with<br>
> oslo.policy already;  run a workload through a server with policy<br>
> non-enforcing (Permissive mode) and log the output to a file, then use<br>
> that output to modify either the policy or the delegations (role<br>
> assignments or trusts) used in a workflow.<br>
><br>
> The Hard coded defaults worry me, though.  Nova is one piece (a big one,<br>
> admittedly) of a delicate dance across multiple (not-so-micro) services<br>
> that make up OpenStack.  Other serivces are going to take their cue from<br>
> what Nova does, and that would make the overall flow that much harder to<br>
> maintain.<br>
<br>
</span>I don't understand why having hard coded defaults makes things harder,<br>
as long as they are discoverable. Defaults typically make things easier,<br>
because people then only change what they need, instead of setting a<br>
value for everything, having the deployment code update, and making<br>
their policy miss an important thing, or make something wrong because<br>
they didn't update it correctly at the same time as code.<br>
<span class=""><br>
> I think we need to break some very ingrained patterns in out policy<br>
> enforcement.  I would worry that enforcing policy in code would give us<br>
> something that we could not work around.  Instead, I think we need to<br>
> ensure that the  Nova team leads the rest of the OpenStack core services<br>
> in setting up best practices, and that is primarily a communication<br>
> issue.  Getting to a common understanding of RBAC, and making it clear<br>
> how roles are modified on a per-api basis will make Nova more robust.<br>
<br>
</span>So I feel like I understand the high level dynamic policy end game. I<br>
feel like what I'm proposing for policy engine with encoded defaults<br>
doesn't negatively impact that. I feel there is a middle chunk where<br>
perhaps we've got different concerns or different dragons that we see,<br>
and are mostly talking past each other. And I don't know how to bridge<br>
that. All the keystone specs I've dived into definitely assume a level<br>
of understanding of keystone internals and culture that aren't obvious<br>
from the outside. I'll be honest, if the only way to collaborate here is<br>
for every project to fully load all of keystone architecture into their<br>
heads, I think this effort is going to stall out. Which would suck.<br>
<br>
So maybe we need to step back and explain what the challenges are, what<br>
changes are expected at each step (for developers and operators), and<br>
err on the side of over explaining things so folks that are not familiar<br>
with all the nuances addressed here can still see the flow.<br>
<span class="HOEnZb"><font color="#888888"><br>
        -Sean<br>
</font></span><span class="im HOEnZb"><br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
</span><div class="HOEnZb"><div class="h5">__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>