[openstack-dev] [keystone] noop role in openstack

Lance Bragstad lbragstad at gmail.com
Thu Sep 20 12:37:35 UTC 2018

On Thu, Sep 20, 2018 at 12:22 AM Adrian Turjak <adriant at catalyst.net.nz>

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

Kind of. System-scope is only half the equation for fixing RBAC because it
gives developers an RBAC target that isn't project-scoped that they can use
to protect APIs with. When you combine that with default roles (admin,
member, and reader) [0] then you can start building a matrix, per se.


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

As I'm sure you know, even rolling custom policy files might not be enough.
Despite an override, there are APIs that still check for 'admin' roles.

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

That's the idea. We're trying to build that out in keystone now so that
other projects have a template to follow.

> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180920/cf5b8ccb/attachment.html>

More information about the OpenStack-dev mailing list