In theory the new Keystone role model supports a model closer to the model that we've set up with custom policies. Let's see which of our customizations we can remove in favor of standard upstream models.
Description
Details
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | Andrew | T276018 Investigate new roles and policies in openstack Xena | |||
Resolved | Andrew | T274385 rework novaadmin and novaobserver project memberships | |||
Resolved | Andrew | T279845 Openstack policy tests | |||
Stalled | Andrew | T330759 Modernize openstack rbac | |||
Resolved | BUG REPORT | bd808 | T331674 Some tool maintainers not showing in Striker UI following config change | ||
Resolved | Andrew | T336670 openstack cli: clarify and document usage | |||
Open | None | T336678 wmcs cookbooks: automate reset nova state of a VM | |||
Open | Andrew | T337577 Replace use of openstack environment settings with clouds.yaml |
Event Timeline
It looks like the reader/member/admin model is in Keystone Train but didn't make it to nova until Ussuri. So there are limited things we can do with this immediately.
I'm going to rename 'observer' to 'reader' so that we've taken at least one step in the right direction before the upgrade to U.
Change 668789 had a related patch set uploaded (by Andrew Bogott; owner: Andrew Bogott):
[operations/puppet@production] cloud-vps rename 'observer' role to 'reader'
Change 668789 merged by Andrew Bogott:
[operations/puppet@production] cloud-vps rename 'observer' role to 'reader'
Mentioned in SAL (#wikimedia-cloud) [2021-03-05T21:40:49Z] <andrewbogott> replacing 'observer' role with 'reader' role in eqiad1 T276018
The next thing we can do to converge on Ussuri standards is to locate all the "" policies in our policy.yaml files that correspond to an upstream default of 'owner' or 'admin_or_owner'. The effect of a "" policy is to provide access to any project member which is ~ the same as what 'owner' means in the upstream defaults and what will become 'reader' access in future releases.
I'm marking this as blocked so it can wait for future OpenStack upgrades. It will be a lot easier to simplify our policies when we have existing upstream policies in code to compare with.
Change 675204 had a related patch set uploaded (by Andrew Bogott; author: Andrew Bogott):
[operations/puppet@production] keystone policy.yaml: reformat yaml
Change 675204 merged by Andrew Bogott:
[operations/puppet@production] keystone policy.yaml: reformat yaml
Change 675205 had a related patch set uploaded (by Andrew Bogott; author: Andrew Bogott):
[operations/puppet@production] Keystone policy.yaml: apply changes from oslopolicy-policy-upgrade
Change 675205 merged by Andrew Bogott:
[operations/puppet@production] Keystone policy.yaml: apply changes from oslopolicy-policy-upgrade
I just overheard people in the Horizon irc channel talking about future support for scoped roles, so we probably don't want to adopt them just yet.
Change 681101 had a related patch set uploaded (by Andrew Bogott; author: Andrew Bogott):
[operations/puppet@production] OpenStack Keystone: Remove some unneeded policy rules
Change 681101 merged by Andrew Bogott:
[operations/puppet@production] OpenStack Keystone: Remove some unneeded policy rules
@Andrew: Per emails from Sep18 and Oct20 and https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup , I am resetting the assignee of this task because there has not been progress lately (please correct me if I am wrong!). Resetting the assignee avoids the impression that somebody is already working on this task. It also allows others to potentially work towards fixing this task. Please claim this task again when you plan to work on it (via Add Action... → Assign / Claim in the dropdown menu) - it would be welcome. Thanks for your understanding!
This is partially done, and partially blocked by upstream dithering. Either way, this task can be closed.