[tc][all][goal]: Ussuri community goal candidate 3: 'Consistent and secure default policies'
Hello Everyone,
This is 3rd proposal candidate for the Ussuri cycle community-wide goal. The other two are [1].
Colleen proposed this idea for the Ussuri cycle community goal.
Projects implemented/plan to implement this: *Keystone already implemented this with all necessary support in oslo.policy with nice documentation. * We discussed this in nova train PTG to implement it in nova [2]. Nova spec was merged in Train but could not implement. I have re-proposed the spec for the Ussuri cycle [3].
This is nice idea as a goal from the user perspective. Colleen has less bandwidth to drive this goal alone. We are looking for a champion or co-champions (1-2 people will be much better) this goal along with Colleen.
Also, let us know what do you think of this as a community goal? Any query or Improvement Feedback?
You can refer the detailed on etherpad or I am copying the same here too to get feedback/queries in each item. Existing policy defaults suffer from three major faults: #1: the admin-ness problem: use of policy rules like 'is_admin' or hard-coded is-admin checks results in the admin-anywhere-admin-everywhere problem and drastically inhibits true multitenancy since by default customers cannot have admin rights on their own projects or domains #2: insecure custom roles: many policy rules simply use "" as the rule, which means there is no rule: anyone can perform that action. This means creation of a custom role (say, "nova-autoscaler" requires editing every policy file across every service to block users with such a rule from performing actions unrelated to their role #3: related to #2, no support for read-only roles: keystone now has a "reader" role that comes out of the box when keystone is bootstrapped, but it currently has very little value because of the use of empty rules in service policies: users with the "reader" role can still perform write actions on services if the policy rule for such an action is empty.
The keystone project has migrated all of its default policies to 1) use oslo.policy's scope_types attribute, which allows the policy engine to understand "system scope" and distinguish between an admin role assignment on a project versus an admin role assignment on the entire system, 2) ensure all rules use one of the default roles (admin, member, and reader) which both ensures support for a read-only role and prevents custom roles from accidental over-permissiveness. Although the problems being solved are slightly different, the keystone team found it was easiest to migrate everything at once. The rest of the OpenStack services can use this migration as a template for securing their own policies.
[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010287.h... http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010290.h... [2] https://etherpad.openstack.org/p/ptg-train-xproj-nova-keystone [3] https://review.opendev.org/#/q/topic:bp/policy-defaults-refresh+(status:open...)
-gmann
On Tue, Oct 22, 2019, at 09:50, Ghanshyam Mann wrote:
Hello Everyone,
This is 3rd proposal candidate for the Ussuri cycle community-wide goal. The other two are [1].
Colleen proposed this idea for the Ussuri cycle community goal.
Projects implemented/plan to implement this: *Keystone already implemented this with all necessary support in oslo.policy with nice documentation.
- We discussed this in nova train PTG to implement it in nova [2]. Nova
spec was merged in Train but could not implement. I have re-proposed the spec for the Ussuri cycle [3].
This is nice idea as a goal from the user perspective. Colleen has less bandwidth to drive this goal alone. We are looking for a champion or co-champions (1-2 people will be much better) this goal along with Colleen.
Also, let us know what do you think of this as a community goal? Any query or Improvement Feedback?
[snipped]
It's possible that this won't work very well as a community goal. This migration took the keystone team about two cycles to implement, not including all the planning and foundational work that needed to happen first. In our virtual PTG meeting today we discussed the possibility of instead forming a pop-up team around this work so that a group of individuals (across several teams, not just the keystone team) could target the largest projects and make more of a dent in the work over a couple of cycles before using the community goal model to close the gaps in the smaller or more peripheral projects. However, we will still need to get buy-in from the projects so that we can be sure that the work the pop-up team does gets prioritized and reviewed.
I've drafted a set of steps that we'd expect projects to follow to get this done:
https://etherpad.openstack.org/p/policy-migration-steps
And we're holding a forum session on it next week:
https://www.openstack.org/summit/shanghai-2019/summit-schedule/events/24357/...
Colleen
Hi Colleen,
We have this as one of the topic to discuss during PTG in Neutron team. I don't have full agenda ready yet, but I can ping You when it will be exactly if You would like to join.
On Tue, Oct 29, 2019 at 04:53:19PM -0700, Colleen Murphy wrote:
On Tue, Oct 22, 2019, at 09:50, Ghanshyam Mann wrote:
Hello Everyone,
This is 3rd proposal candidate for the Ussuri cycle community-wide goal. The other two are [1].
Colleen proposed this idea for the Ussuri cycle community goal.
Projects implemented/plan to implement this: *Keystone already implemented this with all necessary support in oslo.policy with nice documentation.
- We discussed this in nova train PTG to implement it in nova [2]. Nova
spec was merged in Train but could not implement. I have re-proposed the spec for the Ussuri cycle [3].
This is nice idea as a goal from the user perspective. Colleen has less bandwidth to drive this goal alone. We are looking for a champion or co-champions (1-2 people will be much better) this goal along with Colleen.
Also, let us know what do you think of this as a community goal? Any query or Improvement Feedback?
[snipped]
It's possible that this won't work very well as a community goal. This migration took the keystone team about two cycles to implement, not including all the planning and foundational work that needed to happen first. In our virtual PTG meeting today we discussed the possibility of instead forming a pop-up team around this work so that a group of individuals (across several teams, not just the keystone team) could target the largest projects and make more of a dent in the work over a couple of cycles before using the community goal model to close the gaps in the smaller or more peripheral projects. However, we will still need to get buy-in from the projects so that we can be sure that the work the pop-up team does gets prioritized and reviewed.
I've drafted a set of steps that we'd expect projects to follow to get this done:
https://etherpad.openstack.org/p/policy-migration-steps
And we're holding a forum session on it next week:
https://www.openstack.org/summit/shanghai-2019/summit-schedule/events/24357/...
Colleen
On Wed, Oct 30, 2019, at 03:00, Slawek Kaplonski wrote:
Hi Colleen,
We have this as one of the topic to discuss during PTG in Neutron team. I don't have full agenda ready yet, but I can ping You when it will be exactly if You would like to join.
I'd be happy to join, please do let me know.
Colleen
On Tue, Oct 29, 2019 at 04:53:19PM -0700, Colleen Murphy wrote:
On Tue, Oct 22, 2019, at 09:50, Ghanshyam Mann wrote:
Hello Everyone,
This is 3rd proposal candidate for the Ussuri cycle community-wide goal. The other two are [1].
Colleen proposed this idea for the Ussuri cycle community goal.
Projects implemented/plan to implement this: *Keystone already implemented this with all necessary support in oslo.policy with nice documentation.
- We discussed this in nova train PTG to implement it in nova [2]. Nova
spec was merged in Train but could not implement. I have re-proposed the spec for the Ussuri cycle [3].
This is nice idea as a goal from the user perspective. Colleen has less bandwidth to drive this goal alone. We are looking for a champion or co-champions (1-2 people will be much better) this goal along with Colleen.
Also, let us know what do you think of this as a community goal? Any query or Improvement Feedback?
[snipped]
It's possible that this won't work very well as a community goal. This migration took the keystone team about two cycles to implement, not including all the planning and foundational work that needed to happen first. In our virtual PTG meeting today we discussed the possibility of instead forming a pop-up team around this work so that a group of individuals (across several teams, not just the keystone team) could target the largest projects and make more of a dent in the work over a couple of cycles before using the community goal model to close the gaps in the smaller or more peripheral projects. However, we will still need to get buy-in from the projects so that we can be sure that the work the pop-up team does gets prioritized and reviewed.
I've drafted a set of steps that we'd expect projects to follow to get this done:
https://etherpad.openstack.org/p/policy-migration-steps
And we're holding a forum session on it next week:
https://www.openstack.org/summit/shanghai-2019/summit-schedule/events/24357/...
Colleen
-- Slawek Kaplonski Senior software engineer Red Hat
On Wed, Oct 30, 2019 at 05:50:08AM -0700, Colleen Murphy wrote:
On Wed, Oct 30, 2019, at 03:00, Slawek Kaplonski wrote:
Hi Colleen,
We have this as one of the topic to discuss during PTG in Neutron team. I don't have full agenda ready yet, but I can ping You when it will be exactly if You would like to join.
I'd be happy to join, please do let me know.
Great to see that. It is scheduled to be on Thursday at 14:40 - 16:00, see https://etherpad.openstack.org/p/Shanghai-Neutron-Planning line 109
Colleen
On Tue, Oct 29, 2019 at 04:53:19PM -0700, Colleen Murphy wrote:
On Tue, Oct 22, 2019, at 09:50, Ghanshyam Mann wrote:
Hello Everyone,
This is 3rd proposal candidate for the Ussuri cycle community-wide goal. The other two are [1].
Colleen proposed this idea for the Ussuri cycle community goal.
Projects implemented/plan to implement this: *Keystone already implemented this with all necessary support in oslo.policy with nice documentation.
- We discussed this in nova train PTG to implement it in nova [2]. Nova
spec was merged in Train but could not implement. I have re-proposed the spec for the Ussuri cycle [3].
This is nice idea as a goal from the user perspective. Colleen has less bandwidth to drive this goal alone. We are looking for a champion or co-champions (1-2 people will be much better) this goal along with Colleen.
Also, let us know what do you think of this as a community goal? Any query or Improvement Feedback?
[snipped]
It's possible that this won't work very well as a community goal. This migration took the keystone team about two cycles to implement, not including all the planning and foundational work that needed to happen first. In our virtual PTG meeting today we discussed the possibility of instead forming a pop-up team around this work so that a group of individuals (across several teams, not just the keystone team) could target the largest projects and make more of a dent in the work over a couple of cycles before using the community goal model to close the gaps in the smaller or more peripheral projects. However, we will still need to get buy-in from the projects so that we can be sure that the work the pop-up team does gets prioritized and reviewed.
I've drafted a set of steps that we'd expect projects to follow to get this done:
https://etherpad.openstack.org/p/policy-migration-steps
And we're holding a forum session on it next week:
https://www.openstack.org/summit/shanghai-2019/summit-schedule/events/24357/...
Colleen
-- Slawek Kaplonski Senior software engineer Red Hat
participants (3)
-
Colleen Murphy
-
Ghanshyam Mann
-
Slawek Kaplonski