For Adam's benefit continuing this a bit in email: regarding the noop role:
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-09-20.log.html#t2018-09-20T04:13:43 The first benefit of such a role (in the given policy scenario) is that you can now give a user explicit scope on a project (but they can't do anything) and then use that role for Swift ACLs with full knowledge they can't do anything other than auth, scope to the project, and then whatever the ACLs let them do. An example use case being: "a user that can ONLY talk to a specific container and NOTHING else in OpenStack or Swift" which is really useful if you want to use a single project for a lot of websites, or backups, or etc. Or in my MFA case, a role I can use when wanting a user to still be able to auth and setup their MFA, but not actually touch any resources until they have MFA setup at which point you give them back their real member role. It all relies on leaving no policy rules 'empty' unless those rules (and their API) really are safe for a noop role. And by empty I don't mean empty, really I mean "any role on a project". Because that's painful to then work with. With the default policies in Nova (and most other projects), you can't actually make proper use of Swift ACLs, because having any role on a project gives you access to all the resources. Like say: https://github.com/openstack/nova/blob/master/nova/policies/base.py#L31 ^ that rule implies, if you are scoped to the project, don't care about the role, you can do anything to the resources. That doesn't work for anything role specific. Such rules would need to be: "is_admin:True or (role:member and project_id:%(project_id)s)" If we stop with this assumption that "any role" on a project works, suddenly policy becomes more powerful and the roles are actually useful beyond admin vs not admin. System scope will help, but then we'll still only have system scope, admin on a project, and not admin on a project, which still makes the role mostly pointless. We as a community need to stop with this assumption (that "any role" on a project works), because it hurts us in regards to actually useful RBAC. Yes deployers can edit the policy to avoid the any role on a project issue (we have), but it's a huge amount of work to figure out that we could all work together and fix upstream. Part of that work is actually happening. With the default roles that Keystone is defining, and system scope. We can then start updating all the project default policies to actually require those roles explicitly, but that effort, needs us to get everyone on board... __________________________________________________________________________ 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