Open Stack

On Thu, Dec 20, 2018 at 3:50 PM Matt Riedemann <mriedemos at gmail.com> wrote:

> On 12/20/2018 1:45 PM, Lance Bragstad wrote:
> >
> > One way you might be able to do this is by shoveling off the policy
> > check using oslo.policy's http_check functionality [0]. But, it still
> > doesn't fix the problem that users have roles on projects, and that's
> > the standard for relaying information from keystone to services today.
> >
> > Hypothetically, the external policy system *could* be an API that allows
> > operators to associate users to different policies that are more
> > granular than what OpenStack offers today (I could POST to this policy
> > system that a specific user can do everything but resize up this
> > *specific* instance). When nova parses a policy check, it hands control
> > to oslo.policy, which shuffles it off to this external system for
> > enforcement. This external policy system evaluates the policies based on
> > what information nova passes it, which would require the policy check
> > string, context of the request like the user, and the resource they are
> > trying operate on (the instance in this case). The external policy
> > system could query it's own policy database for any policies matching
> > that data, run the decisions, and return the enforcement decision per
> > the oslo.limit API.
>
> One thing I'm pretty sure of in nova is we do not do a great job of
> getting the target of the policy check before actually doing the check.
> In other words, our target is almost always the project/user from the
> request context, and not the actual resource upon which the action is
> being performed (the server in most cases). I know John Garbutt had a
> spec for this before. It always confused me.
>

I doubt nova is alone in this position. I would bet there are a lot of
cases across OpenStack where we could be more consistent in how this
information is handed to oslo.policy. We attempted to solve this for the
other half of the equation, which is the `creds` dictionary. Turns out a
lot of what was in this arbitrary `creds` dict, was actually just
information from the request context object. The oslo.policy library now
supports context objects directly [0], as opposed to hoping services build
the dictionary properly. Target information will be a bit harder to do
because it's different across services and even APIs within the same
service. But yeah, I totally sympathize with the complexity it puts on
developers.

[0] https://review.openstack.org/#/c/578995/


>
> >
> > Conversely, you'll have a performance hit since the policy decision and
> > policy enforcement points are no longer oslo.policy *within* nova, but
> > some external system being called by oslo.policy...
>
> Yeah. The other thing is if I'm just looking at my server, I can see if
> it's locked or not since it's an attribute of the server resource. With
> policy I would only know if I can perform a certain action if I get a
> 403 or not, which is fine in most cases. Being able to see via some list
> of locked actions per server is arguably more user friendly. This also
> reminds me of reporting / capabilities APIs we've talked about over the
> years, e.g. what I can do on this cloud, on this host, or with this
> specific server?
>

Yeah - I wouldn't mind picking that conversation up, maybe in a separate
thread. An idea we had with keystone was to run a user's request through
all registered policies and return a list of the ones they could access
(e.g., take my token and tell me what I can do with it.) There are probably
other issues with this, since policy names are mostly operator facing and
end users don't really care at the moment.


>
> >
> > Might not be the best idea, but food for thought based on the
> > architecture we have today.
>
> Definitely, thanks for the alternative. This is something one could
> implement per-provider based on need if we don't have a standard solution.
>

Right, I always thought it would be a good fit for people providing
super-specific policy checks or have a custom syntax they want to
implement. It keeps most of that separate from the services and
oslo.policy. So long as we pass target and context information
consistently, they essentially have an API they can write policies against.


>
> --
>
> Thanks,
>
> Matt
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20181220/84f4ec88/attachment.html>