---- On Wed, 09 Dec 2020 14:04:57 -0600 Lance Bragstad <lbragstad@gmail.com> wrote ----
Hey everyone,
I wanted to take an opportunity to clarify some work we have been doing upstream, specifically modifying the default policies across projects.
These changes are the next phase of an initiative that’s been underway since Queens to fix some long-standing security concerns in OpenStack [0]. For context, we have been gradually improving policy enforcement for years. We started by improving policy formats, registering default policies into code [1], providing better documentation for policy writers, implementing necessary identity concepts in keystone [2], developing support for those concepts in libraries [3][4][5][6][7][8], and consuming all of those changes to provide secure default policies in a way operators can consume and roll out to their users [9][10].
All of this work is in line with some high-level documentation we started writing about three years ago [11][12][13].
There are a handful of services that have implemented the goals that define secure RBAC by default, but a community-wide goal is still out-of-reach. To help with that, the community formed a pop-up team with a focused objective and disbanding criteria [14].
The work we currently have in progress [15] is an attempt to start applying what we have learned from existing implementations to other projects. The hope is that we can complete the work for even more projects in Wallaby. Most deployers looking for this functionality won't be able to use it effectively until all services in their deployment support it.
Thanks, Lance for pushing this work forwards. I completely agree and that is what we get feedback in forum sessions also that we should implement this in all the services first before we ask operators to move their cloud to the new RBAC. We discussed these in today's policy-popup meeting also and encourage every project to help in those patches to add tests and review. This will help to finish the work on priority and we can provide better RBAC experience to the deployer. -gmann
I hope this helps clarify or explain the patches being proposed.
As always, I'm happy to elaborate on specific concerns if folks have them.
Thanks,
Lance
[0] https://bugs.launchpad.net/keystone/+bug/968696/ [1] https://governance.openstack.org/tc/goals/selected/queens/policy-in-code.htm... [2] https://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/s... [3] https://review.opendev.org/c/openstack/keystoneauth/+/529665 [4] https://review.opendev.org/c/openstack/python-keystoneclient/+/524415 [5] https://review.opendev.org/c/openstack/oslo.context/+/530509 [6] https://review.opendev.org/c/openstack/keystonemiddleware/+/564072 [7] https://review.opendev.org/c/openstack/oslo.policy/+/578995 [8] https://review.opendev.org/q/topic:%22system-scope%22+(status:open%20OR%20st...) [9] https://review.opendev.org/q/status:merged+topic:bp/policy-defaults-refresh+... [10] https://review.opendev.org/q/topic:%22implement-default-roles%22+(status:ope...) [11] https://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/... [12] https://docs.openstack.org/keystone/latest/admin/service-api-protection.html [13] https://docs.openstack.org/keystone/latest/contributor/services.html#authori... [14] https://governance.openstack.org/tc/reference/popup-teams.html#secure-defaul... [15] https://review.opendev.org/q/topic:%2522secure-rbac%2522+status:open