<div dir="ltr"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 20, 2018 at 12:22 AM Adrian Turjak <<a href="mailto:adriant@catalyst.net.nz">adriant@catalyst.net.nz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">For Adam's benefit continuing this a bit in email:<br>
<br>
regarding the noop role:<br>
<br>
<a href="http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-09-20.log.html#t2018-09-20T04:13:43" rel="noreferrer" target="_blank">http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-09-20.log.html#t2018-09-20T04:13:43</a><br>
<br>
The first benefit of such a role (in the given policy scenario) is that<br>
you can now give a user explicit scope on a project (but they can't do<br>
anything) and then use that role for Swift ACLs with full knowledge they<br>
can't do anything other than auth, scope to the project, and then<br>
whatever the ACLs let them do. An example use case being: "a user that<br>
can ONLY talk to a specific container and NOTHING else in OpenStack or<br>
Swift" which is really useful if you want to use a single project for a<br>
lot of websites, or backups, or etc.<br>
<br>
Or in my MFA case, a role I can use when wanting a user to still be able<br>
to auth and setup their MFA, but not actually touch any resources until<br>
they have MFA setup at which point you give them back their real member<br>
role.<br>
<br>
It all relies on leaving no policy rules 'empty' unless those rules (and<br>
their API) really are safe for a noop role. And by empty I don't mean<br>
empty, really I mean "any role on a project". Because that's painful to<br>
then work with.<br>
<br>
With the default policies in Nova (and most other projects), you can't<br>
actually make proper use of Swift ACLs, because having any role on a<br>
project gives you access to all the resources. Like say:<br>
<a href="https://github.com/openstack/nova/blob/master/nova/policies/base.py#L31" rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/master/nova/policies/base.py#L31</a><br>
<br>
^ that rule implies, if you are scoped to the project, don't care about<br>
the role, you can do anything to the resources. That doesn't work for<br>
anything role specific. Such rules would need to be:<br>
"is_admin:True or (role:member and project_id:%(project_id)s)"<br>
<br>
If we stop with this assumption that "any role" on a project works,<br>
suddenly policy becomes more powerful and the roles are actually useful<br>
beyond admin vs not admin. System scope will help, but then we'll still<br>
only have system scope, admin on a project, and not admin on a project,<br>
which still makes the role mostly pointless.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>[0] <a href="http://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/define-default-roles.html">http://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/define-default-roles.html</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
We as a community need to stop with this assumption (that "any role" on<br>
a project works), because it hurts us in regards to actually useful<br>
RBAC. Yes deployers can edit the policy to avoid the any role on a<br>
project issue (we have), but it's a huge amount of work to figure out<br>
that we could all work together and fix upstream.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Part of that work is actually happening. With the default roles that<br>
Keystone is defining, and system scope. We can then start updating all<br>
the project default policies to actually require those roles explicitly,<br>
but that effort, needs us to get everyone on board...<br></blockquote><div><br></div><div>That's the idea. We're trying to build that out in keystone now so that other projects have a template to follow.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div></div>