Open Stack

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

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

[0]
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/define-default-roles.html


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