[openstack-dev] Dynamic Policy for Access Control Subteam Meeting

Sean Dague sean at dague.net
Thu Jun 4 13:40:39 UTC 2015

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.

> 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 Dague

More information about the OpenStack-dev mailing list