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

[Adam Young]

On 06/04/2015 05:49 PM, Morgan Fainberg wrote:

Hi Everyone!

I've been reading through this thread and have had some conversations 
along the side and wanted to jump in to distill out what I think are 
the key points we are trying to address here. I'm going to outline 
about 4 items that seem to make sense to me regarding the evolution of 
policy. I also want to say that the "notification" that something has 
changed from the defaults in a way that may cause odd behavior to the 
side (the warning Sean was outlining); we can keep the desire to have 
those types of warnings for operators down the line (nothing that is 
being proposed here or what I'm going to outline will make it more or 
less difficult to add the functionality later on). This is not to say 
we wouldn't provide validation of an override, but a subjective "this 
is a problematic policy configuration" doesn't need to be directly 
part of this conversation today (it can happen once we know what the 
model of policy looks like going forward).


1. The first thing that I'm hearing from the conversation (this is 
based upon Sean's proposal) is that we already trust the individual 
projects to know the enforcement profile for their resources. It seems 
like the project should be authoritative on what that enforcement 
should look like. Handing off the enforcement definition to Keystone 
is the wrong direction. I really like the concept of defining within 
Nova the default policy that nova works with (we do this already 
today, and I don't want to require the nova team to come to Keystone 
to make changes to the policy down the line). The Projects are trusted 
to know what the enforcement points are and trusted to distribute a 
basic profile of enforcement.


To the end that the enforcement definition is handled by the 
individual projects, making it something that is more than a "blob of 
text" also makes a lot of sense. A code-like model that is easier to 
understand for the developers that are implementing enforcement would 
be useful. The key pieces are that this code-like-construct must be 
able to be serialized out into the "common" format.
The policy file format is JSON, which is the standard for all of the 
APIs in OpenStack thus far.


Second, this code-construct is just the basic level of "truth", the 
idea is that the dynamic policy will provide the overrides - and 
*everything* can be overridden.  The code-like construct will also aid 
in profiling/testing the base/defaults (and then the dynamic policy 
overrides) without having to standup the entire stack. We can enable 
base functionality testing / validation and then the more integrated 
testing with the full stack (in different environments). This will 
enable more accurate and better base policy development by the teams 
we already trust to build the enforcement for a given project (e.g. Nova).
We already have this.  It is the default policy.json that each project 
keeps up to date.


Please don't suggest putting annotations on the coder and running a 
preprocessor.  That way leads to madness.  I see no reason to have a 
team write  policy in Python and then serialize to JSON.



--


The real current problem we have is this:  On a given API, we don't know 
where to look for the project ID and (almost all) policy needs to be 
enforced on the project scope.  What is required is for the base 
repository to have a document of how to set up the scoping for the call 
(token.proiject.id must match fetched_object.tenant_id), and we could 
mark that as "dangerous to change".  What I would not want is to have 
the project hardcode the Role required.  Perhaps the API indicates one 
of two levels:  Admin vs Member, on an API, indicating the expected 
consumer of the API.  However, the current Policy file format represents 
this sufficiently.  We just need the Nova team to stay on top of this 
for Nova, and the other teams for their projects.


What I would love to be able to get from Nova is "this api will end up 
calling these apis in Glance, Cinder, and neutron."  So we can properly 
delegate.





2. We will need a way to handle the bi-directional notifications for 
policy changes. This would encompass when a project is restarted and 
has a new code-policy construct and how that gets to Keystone. We also 
need to ensure that changes to the overrides are pushed down to the 
projects. This is not an easy canned solution today, but I am sure we 
can solve it. Likely this is tied to Keystone Middleware or something 
similar (I believe code is already in the works to this end).


I appreciate that Nova is growing, but I would not expect huge amounts 
of new policy code with each updtate...at this point, new policy would 
be "deny until there is a new rule to handle it" and "upload these new 
rules".  Upgrading code is already part of an organizations deployment 
stategy, and trying to build in an additional two way notification 
system is more than we should be doing here.


If Nova feels that

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

[Morgan Fainberg]

Hi Everyone!

I've been reading through this thread and have had some conversations along
the side and wanted to jump in to distill out what I think are the key
points we are trying to address here. I'm going to outline about 4 items
that seem to make sense to me regarding the evolution of policy. I also
want to say that the "notification" that something has changed from the
defaults in a way that may cause odd behavior to the side (the warning Sean
was outlining); we can keep the desire to have those types of warnings for
operators down the line (nothing that is being proposed here or what I'm
going to outline will make it more or less difficult to add the
functionality later on). This is not to say we wouldn't provide validation
of an override, but a subjective "this is a problematic policy
configuration" doesn't need to be directly part of this conversation today
(it can happen once we know what the model of policy looks like going
forward).

1. The first thing that I'm hearing from the conversation (this is based
upon Sean's proposal) is that we already trust the individual projects to
know the enforcement profile for their resources. It seems like the project
should be authoritative on what that enforcement should look like. Handing
off the enforcement definition to Keystone is the wrong direction. I really
like the concept of defining within Nova the default policy that nova works
with (we do this already today, and I don't want to require the nova team
to come to Keystone to make changes to the policy down the line). The
Projects are trusted to know what the enforcement points are and trusted to
distribute a basic profile of enforcement.

To the end that the enforcement definition is handled by the individual
projects, making it something that is more than a "blob of text" also makes
a lot of sense. A code-like model that is easier to understand for the
developers that are implementing enforcement would be useful. The key
pieces are that this code-like-construct must be able to be serialized out
into the "common" format. Second, this code-construct is just the basic
level of "truth", the idea is that the dynamic policy will provide the
overrides - and *everything* can be overridden.  The code-like construct
will also aid in profiling/testing the base/defaults (and then the dynamic
policy overrides) without having to standup the entire stack. We can enable
base functionality testing / validation and then the more integrated
testing with the full stack (in different environments). This will enable
more accurate and better base policy development by the teams we already
trust to build the enforcement for a given project (e.g. Nova).
--

2. We will need a way to handle the bi-directional notifications for policy
changes. This would encompass when a project is restarted and has a new
code-policy construct and how that gets to Keystone. We also need to ensure
that changes to the overrides are pushed down to the projects. This is not
an easy canned solution today, but I am sure we can solve it. Likely this
is tied to Keystone Middleware or something similar (I believe code is
already in the works to this end).
--

3. The HA-Proxy mode of deployment with projects that can handle
no-downtime upgrades mean that we need to add in versioning into the policy
structures. The policy files for a "Kilo" vintage of Nova may (likely) will
be incompatible with "Liberty" nova. This means we cannot assume that
policy can be centralized easily even for a specific grouping of
api-services running as a single endpoint. This becomes an even more
important mechanism as we move towards more and more services with
microversioned APIs. It means it is totally reasonable to upgrade 1 or 2
nova APIs behind an HA Proxy since the new APIs will handle the old
microversion of the API.

This leads to needing policy to likewise be versioned. This also means that
only the service can be authoritative with the base-policy construct. This
means whatever tool we use for handling the overrides on the Keystone side
will need to be aware of policy versions as well. Having Keystone side
being exclusively authoratative for the entire policy makes development,
testing, and understanding of policy harder. This is another case of the
project itself should be in control of the base policy definition.
--

4. As a note that came out of the conversation I had with Sean, we should
look at no longer making the policy definition for an API keyed on the
intern-method name of a project. While "instance_create" is relatively
descriptive, there are many other API calls that you cannot really know
what changing the policy will do without trying it. Sean and I were
discussing moving towards supplying a representation of the URI path
instead of "image_create". This is something that consumers and deployers
of OpenStack will be more familiar with. It also eliminates some of the
mapping needed to know what the URI of "image create" is when utilized in
the Horizon c

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

[Adam Young]

On 06/04/2015 01:16 PM, Sean Dague wrote:

It gets overwritten by the central store.

And you are wrong, that gives me what I want, because we can emit a
WARNING in the logs if the patch is something crazy. The operators will
see it, and be able to fix it later.

I'm not trying to prevent people from changing their policy in crazy
ways. I'm trying to build in some safety net where we can detect it's
kind of a bad idea and emit that information a place that Operators can
see and sort out later, instead of pulling their hair out.

But you can only do that if you have encoded what's the default, plus
annotations about ways that changing the default are unwise.
When would you expect this warning to be emitted, and to whom?  I think 
you have the right idea, but I suggest that the appropriate time to give 
that warning would be back when the policy is written, which would be 
under the scope of the Database-Driven policy management.  I would think 
that, if a user changes a policy, it would go to a staged state, not 
deployed immediately, and at that point, we'd want a check to run.  That 
check would be what told the author they did something unexpected.  
Waiting until the policy hits the server is probably too late.





__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Yee, Guang]

I am confused about the goal. Are we saying we should allow operators to modify 
the access policies but then warn them if they do? But if operators *intend* to 
modify the policies in order to fit their compliance/security needs, which is 
likely the case, aren't the warning messages confusing and counterintuitive?


Guang


-Original Message-
From: Sean Dague [mailto:s...@dague.net] 
Sent: Thursday, June 04, 2015 10:16 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Dynamic Policy for Access Control Subteam Meeting

On 06/04/2015 01:03 PM, Adam Young wrote:
> On 06/04/2015 09:40 AM, Sean Dague wrote:
>> 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.
> 
> Policy is not currently designed to be additive;  let's take the Nova 
> rule||
> ||
> ||"get_network": "rule:admin_or_owner or rule:shared or rule:external 
> ||or
> rule:context_is_advsvc"||
> ||
> |FROM
> http://git.openstack.org/cgit/openstack/neutron/tree/etc/policy.json#n
> 27|
> ||
> |This pulls in |
> 
> "external": "field:networks:router:external=True",
> |
> Now, we have a single JSON file that implements this. Lets say that 
> you ended up coding exactly this rule in python. What would that mean?
> Either you make some way of initializing oslo.policy from a Python 
> object, or you enforce outside of Oslo.policy (custom nova Code).  If 
> it is custom code, you  have to say "run oslo or run my logic"
> everywhere...you can see that this approach leads to fragementation of 
> policy enforcement.
> 
> So, instead, you go the "initialize oslo from Python."  We currentl 
> have the idea of multiple policy files in the directory, so you just 
> treat the Python code as a file with either the lowest or highest ABC 
> order, depending.  Now, each policy file gets read, and the rules are 
> a hashtable, keyed by the rule name.  So both get_network and external 
> are keys that get read in.  If 'overwrite' is set, it will only 
> process the last set of rules (replaces all rules)  but I think what 
> we want here is just update:
> 
> http://git.openstack.org/cgit/openstack/oslo.policy/tree/oslo_policy/p
> olicy.py#n361 Which would mix together the existing rules with the 
> rules from the policy files.
> 
> 
> So...what would your intention be with hardcoding the policy in Nova? 
> That your rule gets overwritten with the rule that comes from the 
> centralized policy store, or that you rule gets executed in addition 
> to the rule from central?  Neither are going to get you what you want, 
> which is "Make sure you can't break Nova by changing Policy"

It gets overwritten by the central store.

And you are wrong, that gives me what I want, because we can emit a WARNING in 
the logs if the patch is something crazy. The operators will see it, and be 
able to fix it later.

I'm not trying to prevent people from changing their policy in crazy ways. I'm 
trying to build in some safety net where we can detect it's kind of a bad idea 
and emit that information a place that Operators can see and sort out later, 
instead of pulling their hair out.

But you can only do that if you have encoded what's the default, plus 
annotations about ways that changing the default are unwise.

-Sean

--
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Sean Dague]

On 06/04/2015 01:03 PM, Adam Young wrote:
> On 06/04/2015 09:40 AM, Sean Dague wrote:
>> 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. 
> 
> Policy is not currently designed to be additive;  let's take the Nova rule||
> ||
> ||"get_network": "rule:admin_or_owner or rule:shared or rule:external or
> rule:context_is_advsvc"||
> ||
> |FROM
> http://git.openstack.org/cgit/openstack/neutron/tree/etc/policy.json#n27|
> ||
> |This pulls in |
> 
> "external": "field:networks:router:external=True",
> |
> Now, we have a single JSON file that implements this. Lets say that you
> ended up coding exactly this rule in python. What would that mean? 
> Either you make some way of initializing oslo.policy from a Python
> object, or you enforce outside of Oslo.policy (custom nova Code).  If it
> is custom code, you  have to say "run oslo or run my logic"
> everywhere...you can see that this approach leads to fragementation of
> policy enforcement.
> 
> So, instead, you go the "initialize oslo from Python."  We currentl have
> the idea of multiple policy files in the directory, so you just treat
> the Python code as a file with either the lowest or highest ABC order,
> depending.  Now, each policy file gets read, and the rules are a
> hashtable, keyed by the rule name.  So both get_network and external are
> keys that get read in.  If 'overwrite' is set, it will only process the
> last set of rules (replaces all rules)  but I think what we want here is
> just update:
> 
> http://git.openstack.org/cgit/openstack/oslo.policy/tree/oslo_policy/policy.py#n361
> Which would mix together the existing rules with the rules from the
> policy files. 
> 
> 
> So...what would your intention be with hardcoding the policy in Nova? 
> That your rule gets overwritten with the rule that comes from the
> centralized policy store, or that you rule gets executed in addition to
> the rule from central?  Neither are going to get you what you want,
> which is "Make sure you can't break Nova by changing Policy"

It gets overwritten by the central store.

And you are wrong, that gives me what I want, because we can emit a
WARNING in the logs if the patch is something crazy. The operators will
see it, and be able to fix it later.

I'm not trying to prevent people from changing their policy in crazy
ways. I'm trying to build in some safety net where we can detect it's
kind of a bad idea and emit that information a place that Operators can
see and sort out later, instead of pulling their hair out.

But you can only do that if you have encoded what's the default, plus
annotations about ways that changing the default are unwise.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Adam Young]

On 06/04/2015 09:40 AM, Sean Dague wrote:

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.


Policy is not currently designed to be additive;  let's take the Nova rule||
||
||"get_network": "rule:admin_or_owner or rule:shared or rule:external or 
rule:context_is_advsvc"||

||
|FROM 
http://git.openstack.org/cgit/openstack/neutron/tree/etc/policy.json#n27|

||
|This pulls in |

"external": "field:networks:router:external=True",
|
Now, we have a single JSON file that implements this. Lets say that you 
ended up coding exactly this rule in python. What would that mean?  
Either you make some way of initializing oslo.policy from a Python 
object, or you enforce outside of Oslo.policy (custom nova Code).  If it 
is custom code, you  have to say "run oslo or run my logic" 
everywhere...you can see that this approach leads to fragementation of 
policy enforcement.


So, instead, you go the "initialize oslo from Python."  We currentl have 
the idea of multiple policy files in the directory, so you just treat 
the Python code as a file with either the lowest or highest ABC order, 
depending.  Now, each policy file gets read, and the rules are a 
hashtable, keyed by the rule name.  So both get_network and external are 
keys that get read in.  If 'overwrite' is set, it will only process the 
last set of rules (replaces all rules)  but I think what we want here is 
just update:


http://git.openstack.org/cgit/openstack/oslo.policy/tree/oslo_policy/policy.py#n361
Which would mix together the existing rules with the rules from the 
policy files.



So...what would your intention be with hardcoding the policy in Nova?  
That your rule gets overwritten with the rule that comes from the 
centralized policy store, or that you rule gets executed in addition to 
the rule from central?  Neither are going to get you what you want, 
which is "Make sure you can't break Nova by changing Policy"









|

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Sean Dague]

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

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Adam Young]

On 06/04/2015 09:40 AM, Sean Dague wrote:

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 "GEThttps://my.nova.api.server/policy";
What would that return?  The default policy.json file that you ship?  Or 
would it be auto-generated based on enforcement in the code?


If it is auto-generated, you need to crawl the code, somehow, to 
generate that.


If it is policy.json, then you are not implementing the defaults in 
code, just returning the one managed by the CMS and deployed with the 
Service endpoint.




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Tim Hinrichs]

Inline.

On Thu, Jun 4, 2015 at 6:40 AM, Sean Dague  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 

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

[Sean Dague]

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

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Adam Young]

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




-Sean


Tim

On Wed, Jun 3, 2015 at 1:53 PM, Doug Hellmann mailto:d...@doughellmann.com>> wrote:

 Excerpts from Sean Dague's message of 2015-06-03 13:34:11 -0400:
 > On 06/03/2015 12:10 PM, Tim Hinrichs wrote:
 > > I definitely buy the idea of layering policies on top of each other.
 > > But I'd worry about the long-term feasibility of putting default
 > > policies into code mainly because it ensures we'll never be able to
 > > provide any tools that help users (or other services like
 Horizon) know
 > > what the effective policy actually is.  In contrast, if the code
 is just
 > > an implementation of the API, and there is some (or perhaps several)
 > > declarative description(s) of which of those APis are permitted
 to be
 > > executed by whom, we can build tools to analyze those policies.  Two
 > > thoughts.
 > >
 > > 1) If the goal is to provide warnings to the user about
 questionable API
 > > policy choices, I'd suggest adding policy-analysis functionality
 to say
 > > oslo_policy.  The policy-analysis code would take 2 inputs: (i) the
 > > policy and (ii) a list of policy properties, and would generate a
 > > warning if any of the properties are true for the given policy.
  Then
 > > each project could provide a file that describes which policy
 properties
 > > are questionable, and anyone wanting to see the warnings run the
 > > functionality on that project's policy and the project's policy
 property
 > > file.
 > >
 > > It would definitely help me if we saw a handful of examples of the
 > > warnings we'd want to generate.
 >
 > WARN: "server create permissions have been restricted from the
 default,
 > this may impede operation and interoperability of your OpenStack
 > installation"
 >
 > > 2) If the goal is to provide sensible defaults so the system
 functions
 > > if there's no policy.json (or a dynamic policy cached from
 Keystone),
 > > why not create a default_policy.json file and use that whenever
 > > policy.json doesn't exist (or more precisely to use policy.json to
 > > override default_policy.json in some reasonable way).
 >
 > Because it's still a file, living in /etc. Files living in etc are
 > things people feel they can modify. They are also things that don't
 > always get deployed correctly with code deploys. People might not
 > realize that default_policy.json is super important to be updated
 every
 > time the code is rolled out.

 It doesn't have to live in /etc, though. It could be packaged in the
 nova code namespace as a data file, and accessed from there.

 Doug

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 
 http://list

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

[Sean Dague]

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?

-Sean

> 
> Tim
> 
> On Wed, Jun 3, 2015 at 1:53 PM, Doug Hellmann  > wrote:
> 
> Excerpts from Sean Dague's message of 2015-06-03 13:34:11 -0400:
> > On 06/03/2015 12:10 PM, Tim Hinrichs wrote:
> > > I definitely buy the idea of layering policies on top of each other.
> > > But I'd worry about the long-term feasibility of putting default
> > > policies into code mainly because it ensures we'll never be able to
> > > provide any tools that help users (or other services like
> Horizon) know
> > > what the effective policy actually is.  In contrast, if the code
> is just
> > > an implementation of the API, and there is some (or perhaps several)
> > > declarative description(s) of which of those APis are permitted
> to be
> > > executed by whom, we can build tools to analyze those policies.  Two
> > > thoughts.
> > >
> > > 1) If the goal is to provide warnings to the user about
> questionable API
> > > policy choices, I'd suggest adding policy-analysis functionality
> to say
> > > oslo_policy.  The policy-analysis code would take 2 inputs: (i) the
> > > policy and (ii) a list of policy properties, and would generate a
> > > warning if any of the properties are true for the given policy. 
>  Then
> > > each project could provide a file that describes which policy
> properties
> > > are questionable, and anyone wanting to see the warnings run the
> > > functionality on that project's policy and the project's policy
> property
> > > file.
> > >
> > > It would definitely help me if we saw a handful of examples of the
> > > warnings we'd want to generate.
> >
> > WARN: "server create permissions have been restricted from the
> default,
> > this may impede operation and interoperability of your OpenStack
> > installation"
> >
> > > 2) If the goal is to provide sensible defaults so the system
> functions
> > > if there's no policy.json (or a dynamic policy cached from
> Keystone),
> > > why not create a default_policy.json file and use that whenever
> > > policy.json doesn't exist (or more precisely to use policy.json to
> > > override default_policy.json in some reasonable way).
> >
> > Because it's still a file, living in /etc. Files living in etc are
> > things people feel they can modify. They are also things that don't
> > always get deployed correctly with code deploys. People might not
> > realize that default_policy.json is super important to be updated
> every
> > time the code is rolled out.
> 
> It doesn't have to live in /etc, though. It could be packaged in the
> nova code namespace as a data file, and accessed from there.
> 
> Doug
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Tim Hinrichs]

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.

Tim

On Wed, Jun 3, 2015 at 1:53 PM, Doug Hellmann  wrote:

> Excerpts from Sean Dague's message of 2015-06-03 13:34:11 -0400:
> > On 06/03/2015 12:10 PM, Tim Hinrichs wrote:
> > > I definitely buy the idea of layering policies on top of each other.
> > > But I'd worry about the long-term feasibility of putting default
> > > policies into code mainly because it ensures we'll never be able to
> > > provide any tools that help users (or other services like Horizon) know
> > > what the effective policy actually is.  In contrast, if the code is
> just
> > > an implementation of the API, and there is some (or perhaps several)
> > > declarative description(s) of which of those APis are permitted to be
> > > executed by whom, we can build tools to analyze those policies.  Two
> > > thoughts.
> > >
> > > 1) If the goal is to provide warnings to the user about questionable
> API
> > > policy choices, I'd suggest adding policy-analysis functionality to say
> > > oslo_policy.  The policy-analysis code would take 2 inputs: (i) the
> > > policy and (ii) a list of policy properties, and would generate a
> > > warning if any of the properties are true for the given policy.   Then
> > > each project could provide a file that describes which policy
> properties
> > > are questionable, and anyone wanting to see the warnings run the
> > > functionality on that project's policy and the project's policy
> property
> > > file.
> > >
> > > It would definitely help me if we saw a handful of examples of the
> > > warnings we'd want to generate.
> >
> > WARN: "server create permissions have been restricted from the default,
> > this may impede operation and interoperability of your OpenStack
> > installation"
> >
> > > 2) If the goal is to provide sensible defaults so the system functions
> > > if there's no policy.json (or a dynamic policy cached from Keystone),
> > > why not create a default_policy.json file and use that whenever
> > > policy.json doesn't exist (or more precisely to use policy.json to
> > > override default_policy.json in some reasonable way).
> >
> > Because it's still a file, living in /etc. Files living in etc are
> > things people feel they can modify. They are also things that don't
> > always get deployed correctly with code deploys. People might not
> > realize that default_policy.json is super important to be updated every
> > time the code is rolled out.
>
> It doesn't have to live in /etc, though. It could be packaged in the
> nova code namespace as a data file, and accessed from there.
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Doug Hellmann]

Excerpts from Sean Dague's message of 2015-06-03 13:34:11 -0400:
> On 06/03/2015 12:10 PM, Tim Hinrichs wrote:
> > I definitely buy the idea of layering policies on top of each other. 
> > But I'd worry about the long-term feasibility of putting default
> > policies into code mainly because it ensures we'll never be able to
> > provide any tools that help users (or other services like Horizon) know
> > what the effective policy actually is.  In contrast, if the code is just
> > an implementation of the API, and there is some (or perhaps several)
> > declarative description(s) of which of those APis are permitted to be
> > executed by whom, we can build tools to analyze those policies.  Two
> > thoughts.
> > 
> > 1) If the goal is to provide warnings to the user about questionable API
> > policy choices, I'd suggest adding policy-analysis functionality to say
> > oslo_policy.  The policy-analysis code would take 2 inputs: (i) the
> > policy and (ii) a list of policy properties, and would generate a
> > warning if any of the properties are true for the given policy.   Then
> > each project could provide a file that describes which policy properties
> > are questionable, and anyone wanting to see the warnings run the
> > functionality on that project's policy and the project's policy property
> > file.
> > 
> > It would definitely help me if we saw a handful of examples of the
> > warnings we'd want to generate.
> 
> WARN: "server create permissions have been restricted from the default,
> this may impede operation and interoperability of your OpenStack
> installation"
> 
> > 2) If the goal is to provide sensible defaults so the system functions
> > if there's no policy.json (or a dynamic policy cached from Keystone),
> > why not create a default_policy.json file and use that whenever
> > policy.json doesn't exist (or more precisely to use policy.json to
> > override default_policy.json in some reasonable way).
> 
> Because it's still a file, living in /etc. Files living in etc are
> things people feel they can modify. They are also things that don't
> always get deployed correctly with code deploys. People might not
> realize that default_policy.json is super important to be updated every
> time the code is rolled out.

It doesn't have to live in /etc, though. It could be packaged in the
nova code namespace as a data file, and accessed from there.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Sean Dague]

On 06/03/2015 12:10 PM, Tim Hinrichs wrote:
> I definitely buy the idea of layering policies on top of each other. 
> But I'd worry about the long-term feasibility of putting default
> policies into code mainly because it ensures we'll never be able to
> provide any tools that help users (or other services like Horizon) know
> what the effective policy actually is.  In contrast, if the code is just
> an implementation of the API, and there is some (or perhaps several)
> declarative description(s) of which of those APis are permitted to be
> executed by whom, we can build tools to analyze those policies.  Two
> thoughts.
> 
> 1) If the goal is to provide warnings to the user about questionable API
> policy choices, I'd suggest adding policy-analysis functionality to say
> oslo_policy.  The policy-analysis code would take 2 inputs: (i) the
> policy and (ii) a list of policy properties, and would generate a
> warning if any of the properties are true for the given policy.   Then
> each project could provide a file that describes which policy properties
> are questionable, and anyone wanting to see the warnings run the
> functionality on that project's policy and the project's policy property
> file.
> 
> It would definitely help me if we saw a handful of examples of the
> warnings we'd want to generate.

WARN: "server create permissions have been restricted from the default,
this may impede operation and interoperability of your OpenStack
installation"

> 2) If the goal is to provide sensible defaults so the system functions
> if there's no policy.json (or a dynamic policy cached from Keystone),
> why not create a default_policy.json file and use that whenever
> policy.json doesn't exist (or more precisely to use policy.json to
> override default_policy.json in some reasonable way).

Because it's still a file, living in /etc. Files living in etc are
things people feel they can modify. They are also things that don't
always get deployed correctly with code deploys. People might not
realize that default_policy.json is super important to be updated every
time the code is rolled out.

With Nova microversions it's not unexpected that we're going to change
policy a number of times during a cycle (with additional items), and the
layering model only really works if, like db migrations, the model is
strongly coupled to the code.

It's only not discoverable if we don't make it so. See the concept of
"GET /policy" as a way to REST expose this from services. That could be
consumed by Horizon, Keystone, whatever, to get a start of truth version
of policy.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Adam Young]

On 06/03/2015 06:47 AM, Sean Dague wrote:

Where I get fuzzy on what I've read / discussed on Dynamic Policy right
now is the fact that every API call is going to need another round trip
to Keystone for a policy check (which would be db calls in keystone?)
Which, maybe is fine, but it seems like there are some challenges and
details around how this consolidated view of the world gets back to the
servers. It*almost*  feels like that /policy API could be used to signal
catch flush as well on changes in Keystone (though we'd need to handle
the HA proxy case). I don't know, this seems a place where devil is in
the details, and lots of people probably need to weigh in on options.
Don't worry, I am not proposing this. I am proposing extending the 
existing mechanism to fetch and cache the policy.json file.  I'm 
currently thinking a default of 1-5 minutes...feedback?
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Tim Hinrichs]

I definitely buy the idea of layering policies on top of each other.  But
I'd worry about the long-term feasibility of putting default policies into
code mainly because it ensures we'll never be able to provide any tools
that help users (or other services like Horizon) know what the effective
policy actually is.  In contrast, if the code is just an implementation of
the API, and there is some (or perhaps several) declarative description(s)
of which of those APis are permitted to be executed by whom, we can build
tools to analyze those policies.  Two thoughts.

1) If the goal is to provide warnings to the user about questionable API
policy choices, I'd suggest adding policy-analysis functionality to say
oslo_policy.  The policy-analysis code would take 2 inputs: (i) the policy
and (ii) a list of policy properties, and would generate a warning if any
of the properties are true for the given policy.   Then each project could
provide a file that describes which policy properties are questionable, and
anyone wanting to see the warnings run the functionality on that project's
policy and the project's policy property file.

It would definitely help me if we saw a handful of examples of the warnings
we'd want to generate.

2) If the goal is to provide sensible defaults so the system functions if
there's no policy.json (or a dynamic policy cached from Keystone), why not
create a default_policy.json file and use that whenever policy.json doesn't
exist (or more precisely to use policy.json to override default_policy.json
in some reasonable way).

Tim




On Wed, Jun 3, 2015 at 3:47 AM, Sean Dague  wrote:

> On 06/02/2015 06:27 PM, Morgan Fainberg wrote:
> >
> >
> > On Tue, Jun 2, 2015 at 12:09 PM, Adam Young  > > wrote:
> >
> > Since this a cross project concern, sending it out to the wider
> > mailing list:
> >
> > We have a sub-effort in Keystone to do better access control policy
> > (not the  Neutron or  Congress based policy efforts).
> >
> > I presented on this at the summit, and the effort is under full
> > swing.  We are going to set up a subteam meeting for this, but would
> > like to get some input from outside the Keystone developers working
> > on it.  In particular, we'd like input from the Nova team that was
> > thinking about hard-coding policy decisions in Python, and ask you,
> > instead, to work with us to come up with a solution that works for
> > all the service.
> >
> >
> > I want to be sure we look at what Nova is presenting here. While
> > building policy into python may not (on the surface) look like an
> > approach that is wanted due to it restricting the flexibility that we've
> > had with policy.json, I don't want to exclude the concept without
> > examination. If there is a series of base level functionality that is
> > expected to work with Nova in all cases - is that something that should
> > be codified in the policy rules? This doesn't preclude having a mix
> > between the two approaches (allowing custom roles, etc, but having a
> > baseline for a project that is a known quantity that could be
> overridden).
> >
> > Is there real value (from a UX and interoperability standpoint) to have
> > everything 100% flexible in all the ways? If we are working to redesign
> > how policy works, we should be very careful of excluding the (more)
> > radical ideas without consideration. I'd argue that dynamic policy does
> > fall on the opposite side of the spectrum from the Nova proposal. In
> > truth I'm going to guess we end up somewhere in the middle.
>
> I also don't think it's removing any flexibility at all. Moving the
> default policy into code is about having sane defaults encoded somewhere
> that we can analyze what people did with the policy, and WARN them when
> they did something odd. That odd might be an interop thing, it might
> also be 'you realize you disabled server creation, right, probably want
> to go look at that'.
>
> Our intent is this applies in layers.
>
> You start with policy in code, that's a set of defaults, which can be
> annotated with ("WARN if policy is restricted further than these
> defaults") for specific rules.
>
> Then you apply policy.json as a set of overrides. Compute and emit any
> warnings.
>
> Where this comes into dynamic policy I think is interesting, because
> dynamic policy seems to require a few things.
>
> Where is the start of day origin seed for policy?
>
> There are a few options here. But if we think about a world where
> components are releasing on different schedules, and being upgraded at
> different times, it seems like the Nova installation has to be that
> source of original truth.
>
> So having a GET /policy API call that would provide the composite policy
> that Nova knows about (code + json patch) would make a lot of sense. It
> would make that discoverable to all kinds of folks on the network, not
> just Keystone. Win.
>
> This also seems like the only sane thing in a

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

[Sean Dague]

On 06/02/2015 06:27 PM, Morgan Fainberg wrote:
> 
> 
> On Tue, Jun 2, 2015 at 12:09 PM, Adam Young  > wrote:
> 
> Since this a cross project concern, sending it out to the wider
> mailing list:
> 
> We have a sub-effort in Keystone to do better access control policy
> (not the  Neutron or  Congress based policy efforts).
> 
> I presented on this at the summit, and the effort is under full
> swing.  We are going to set up a subteam meeting for this, but would
> like to get some input from outside the Keystone developers working
> on it.  In particular, we'd like input from the Nova team that was
> thinking about hard-coding policy decisions in Python, and ask you,
> instead, to work with us to come up with a solution that works for
> all the service.
> 
> 
> I want to be sure we look at what Nova is presenting here. While
> building policy into python may not (on the surface) look like an
> approach that is wanted due to it restricting the flexibility that we've
> had with policy.json, I don't want to exclude the concept without
> examination. If there is a series of base level functionality that is
> expected to work with Nova in all cases - is that something that should
> be codified in the policy rules? This doesn't preclude having a mix
> between the two approaches (allowing custom roles, etc, but having a
> baseline for a project that is a known quantity that could be overridden).
> 
> Is there real value (from a UX and interoperability standpoint) to have
> everything 100% flexible in all the ways? If we are working to redesign
> how policy works, we should be very careful of excluding the (more)
> radical ideas without consideration. I'd argue that dynamic policy does
> fall on the opposite side of the spectrum from the Nova proposal. In
> truth I'm going to guess we end up somewhere in the middle.

I also don't think it's removing any flexibility at all. Moving the
default policy into code is about having sane defaults encoded somewhere
that we can analyze what people did with the policy, and WARN them when
they did something odd. That odd might be an interop thing, it might
also be 'you realize you disabled server creation, right, probably want
to go look at that'.

Our intent is this applies in layers.

You start with policy in code, that's a set of defaults, which can be
annotated with ("WARN if policy is restricted further than these
defaults") for specific rules.

Then you apply policy.json as a set of overrides. Compute and emit any
warnings.

Where this comes into dynamic policy I think is interesting, because
dynamic policy seems to require a few things.

Where is the start of day origin seed for policy?

There are a few options here. But if we think about a world where
components are releasing on different schedules, and being upgraded at
different times, it seems like the Nova installation has to be that
source of original truth.

So having a GET /policy API call that would provide the composite policy
that Nova knows about (code + json patch) would make a lot of sense. It
would make that discoverable to all kinds of folks on the network, not
just Keystone. Win.

This also seems like the only sane thing in a big tent world where
Keystone might have a *ton* of projects in it's catalog. When something
registered in the catalog, Keystone would reach back into that end point
and look for /policy and populate it's base source of truth for that
service from there.

Dynamic Policy overrides in Keystone would just be another set of
patches (conceptually). These stored in a database instead. Thats fine.

Where I get fuzzy on what I've read / discussed on Dynamic Policy right
now is the fact that every API call is going to need another round trip
to Keystone for a policy check (which would be db calls in keystone?)
Which, maybe is fine, but it seems like there are some challenges and
details around how this consolidated view of the world gets back to the
servers. It *almost* feels like that /policy API could be used to signal
catch flush as well on changes in Keystone (though we'd need to handle
the HA proxy case). I don't know, this seems a place where devil is in
the details, and lots of people probably need to weigh in on options.


But, the tl;dr is that Nova wanting to put defaults in code doesn't hide
anything away, and doesn't break the Dynamic policy model. It just adds
another layer that needs to be computed, and make it so that you'd get
the policy from Nova via that API instead of rooting around in the
filesystem (which is a far more useful way for most people to get it).

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Morgan Fainberg]

On Tue, Jun 2, 2015 at 12:09 PM, Adam Young  wrote:

> Since this a cross project concern, sending it out to the wider mailing
> list:
>
> We have a sub-effort in Keystone to do better access control policy (not
> the  Neutron or  Congress based policy efforts).
>
> I presented on this at the summit, and the effort is under full swing.  We
> are going to set up a subteam meeting for this, but would like to get some
> input from outside the Keystone developers working on it.  In particular,
> we'd like input from the Nova team that was thinking about hard-coding
> policy decisions in Python, and ask you, instead, to work with us to come
> up with a solution that works for all the service.
>
>
I want to be sure we look at what Nova is presenting here. While building
policy into python may not (on the surface) look like an approach that is
wanted due to it restricting the flexibility that we've had with
policy.json, I don't want to exclude the concept without examination. If
there is a series of base level functionality that is expected to work with
Nova in all cases - is that something that should be codified in the policy
rules? This doesn't preclude having a mix between the two approaches
(allowing custom roles, etc, but having a baseline for a project that is a
known quantity that could be overridden).

Is there real value (from a UX and interoperability standpoint) to have
everything 100% flexible in all the ways? If we are working to redesign how
policy works, we should be very careful of excluding the (more) radical
ideas without consideration. I'd argue that dynamic policy does fall on the
opposite side of the spectrum from the Nova proposal. In truth I'm going to
guess we end up somewhere in the middle.




> If you are interested in being part of this effort, there is a Trello
> board set up here:
>
> https://trello.com/b/260v4Gs7/dynamic-policy
>
> It should be world readable.  I will provide you write access if you are
> interested in contributing.  In addition, let me know what your constraints
> are in setting up a weekly meeting and I will try to accommodate.  Right
> now, the people involved are primarily East-Coast of the Western Hemisphere
> and Europe, and the meeting time will likely be driven by that.
>
>
I definitely want to encourage this to be a cross-project / horizontal
effort as this will impact everything within OpenStack.

Cheers,
--Morgan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Adam Young]

Since this a cross project concern, sending it out to the wider mailing 
list:


We have a sub-effort in Keystone to do better access control policy (not 
the  Neutron or  Congress based policy efforts).


I presented on this at the summit, and the effort is under full swing.  
We are going to set up a subteam meeting for this, but would like to get 
some input from outside the Keystone developers working on it.  In 
particular, we'd like input from the Nova team that was thinking about 
hard-coding policy decisions in Python, and ask you, instead, to work 
with us to come up with a solution that works for all the service.


If you are interested in being part of this effort, there is a Trello 
board set up here:


https://trello.com/b/260v4Gs7/dynamic-policy

It should be world readable.  I will provide you write access if you are 
interested in contributing.  In addition, let me know what your 
constraints are in setting up a weekly meeting and I will try to 
accommodate.  Right now, the people involved are primarily East-Coast of 
the Western Hemisphere and Europe, and the meeting time will likely be 
driven by that.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Dynamic Policy

[Henry Nash]

Hi Adam,

So a comprehensive write-up...although I'm not sure we have made the case for 
why we need a complete rewrite of how policy is managed.  We seemed to have 
lept into a solution without looking at other possible solutions to the 
problems we are trying to solve.  Here's a start at an alternative approach:

Problem 1: The current services don't use the centralised policy store/fetch of 
keystone, meaning that a) policy file management is hard, and b) we can't 
support the policy-per-endpoint style of working
Solution: Let's get the other services using it!  No code changes required in 
Keytsone.  The fact that we haven't succeeded before, just means we haven't 
tried hard enough.

Problem 2: Different domains want to be able to create their own "roles" which 
are more meaningful to their users...but our "roles" are global and are 
directly linked to the rules in the policy file - something only a cloud 
operator is going to want to own.
Solution: Have some kind of domain-scoped role-group (maybe just called 
"domain-roles"?) that a domain owner can define, that maps to a set of 
underlying roles that a policy file understands (see: 
https://review.openstack.org/#/c/133855/). [As has been pointed out, what we 
are really doing with this is finally doing real RBAC, where what we call roles 
today are really capabilities and domain-roles are really just roles].  As this 
evolves, cloud providers could slowly migrate to the position where each 
service API is effectively a role (i.e. a capability) and at the domain level 
there exists the "abstraction that makes sense for the users of that domain" 
into the underlying capabilities. No code changes...this just uses policy files 
as they are today (plus domain-groups) - and tokens as they are too. And I 
think that level of functionality would satisfy a lot of people. Eventually (as 
pointed out by samuelmz) the policy "file" could even simply become the 
definition of the service capabilities (and whether each capability is "open", 
"closed" or "is a role")...maybe just registered and stored in the service 
entity the keystone DB (allowing dynamic service registration). My point being, 
that we really didn't require much code change (nor really any conceptual 
changes) to get to this end point...and certainly no rewriting of policy/token 
formats etc.  [In reality, this last point would cause problems with token size 
(since a broad admin capability would need a lot of capabilities), so some kind 
a collections of capabilities would be required.]

Problem 3: A cloud operator wants to be able to enable resellers to white label 
her services (who in turn may resell to others) - so needs some kind of 
inheritance model so that service level agreements can be supported by policy 
(e.g. let the reseller give the support expert from the cloud provider have 
access to their projects).
Solution: We already have hierarchical inheritance in the works...so that we 
would allow a reseller to assign roles to a user/group from the parent onto 
their own domain/project. Further, domain-roles are just another thing that can 
(optionally) be inherited and used in this fashion.

My point about all the above is that I think while what you have laid out is a 
great set of stepsI don't think we have conceptual agreement as to whether 
that path is the only way we could go to solve out problems.

Henry
On 18 Nov 2014, at 23:40, Adam Young  wrote:

> There is a lot of discussion about policy.  I've attempted to pull the 
> majority of the work into a single document that explains the process in a 
> step-by-step manner:
> 
> 
> http://adam.younglogic.com/2014/11/dynamic-policy-in-keystone/
> 
> Its really long, so I won't bother reposting the whole article here.  
> Instead, I will post the links to the topic on Gerrit.
> 
> https://review.openstack.org/#/q/topic:dynamic-policy,n,z
> 
> 
> There is one additional review worth noting:
> 
> https://review.openstack.org/#/c/133855/
> 
> Which is for "private groups of roles"  specific to a domain.  This is 
> related, but not part of the critical path for the things I wrote above.
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Dynamic Policy

[Adam Young]

There is a lot of discussion about policy.  I've attempted to pull the 
majority of the work into a single document that explains the process in 
a step-by-step manner:



http://adam.younglogic.com/2014/11/dynamic-policy-in-keystone/

Its really long, so I won't bother reposting the whole article here.  
Instead, I will post the links to the topic on Gerrit.


https://review.openstack.org/#/q/topic:dynamic-policy,n,z


There is one additional review worth noting:

https://review.openstack.org/#/c/133855/

Which is for "private groups of roles"  specific to a domain.  This is 
related, but not part of the critical path for the things I wrote above.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev