Open Stack

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...