On Thu, Sep 20, 2018 at 12:22 AM Adrian Turjak <adri...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ 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
