Re: [openstack-dev] Dynamic Policy for Access Control Subteam Meeting
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
