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

2015-06-04 Thread 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 each micro 

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

2015-06-04 Thread 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 context (asking 

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

2015-06-04 Thread 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

2015-06-04 Thread 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

2015-06-04 Thread 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

2015-06-04 Thread 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

2015-06-04 Thread Tim Hinrichs
Inline.

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

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 mostly talking past each other. And I don't know how to bridge
 that. All the keystone specs I've 

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

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

__
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

2015-06-04 Thread 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 d...@doughellmann.com
 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://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

2015-06-04 Thread 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

2015-06-04 Thread 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 d...@doughellmann.com
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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 

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

2015-06-04 Thread 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

2015-06-03 Thread 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

2015-06-03 Thread 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 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://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

2015-06-03 Thread Sean Dague
On 06/02/2015 06:27 PM, Morgan Fainberg wrote:
 
 
 On Tue, Jun 2, 2015 at 12:09 PM, Adam Young ayo...@redhat.com
 mailto:ayo...@redhat.com 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

2015-06-03 Thread 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 s...@dague.net wrote:

 On 06/02/2015 06:27 PM, Morgan Fainberg wrote:
 
 
  On Tue, Jun 2, 2015 at 12:09 PM, Adam Young ayo...@redhat.com
  mailto:ayo...@redhat.com 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 

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

2015-06-03 Thread 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

2015-06-03 Thread 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

2015-06-02 Thread Morgan Fainberg
On Tue, Jun 2, 2015 at 12:09 PM, Adam Young ayo...@redhat.com 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


Re: [openstack-dev] Dynamic Policy

2014-11-19 Thread 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 ayo...@redhat.com 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