Implied role API doesn't support default roles

Bug #1805371 reported by Lance Bragstad on 2018-11-27
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Medium
Colleen Murphy

Bug Description

In Rocky, keystone implemented support to ensure at least three default roles were available [0]. The implied roles API doesn't incorporate these defaults into its default policies [1], but it should.

[0] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/define-default-roles.html
[1] http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/policies/implied_role.py?id=fb73912d87b61c419a86c0a9415ebdcf1e186927

tags: added: default-roles policy
Changed in keystone:
status: New → Triaged
importance: Undecided → Medium
Adam Young (ayoung) wrote :

Note that implied roles are used for domain specific roles. Thus, a domain admin should be able to create an rule where the explicit role is a domain specific role and the implied role is a global role or another domain specific role.

Given the following sample data, and assume role names and IDs are identical:

Domain Specific ROles:
Dom1R1
Dom2R2
Dom1R2
Dom2R2

Global Roles:
GlobalR1
Admin

Assignments:
User0 Admin Scoped to System
User1 Admin on Dom1
User2 Admin on Dom2

The following should be legal:
User1 can create a role Dom1R1 implies Admin
User1 can create a role Dom1R1 implies Dom1R2
User2 can create a role Dom2R1 implies Admin
User2 can create a role Dom2R2 implies Dom1R1
User0 can create a role Admin implies GlobalR1

The following should be enforced:
User1 cannot create a role Dom2R1 implies Admin
User1 cannot create a role Dom2R2 implies Dom1R1
User2 cannot create a role Dom1R1 implies Admin
User2 cannot create a role Dom1R1 implies Dom1R2
User1 or User2 cannnot create a role Admin implies GlobalR1

Colleen Murphy (krinkle) on 2019-03-12
Changed in keystone:
milestone: none → stein-rc1
Colleen Murphy (krinkle) on 2019-03-20
Changed in keystone:
milestone: stein-rc1 → none
Lance Bragstad (lbragstad) wrote :

Adam,

In comment #1, is "User2 can create a role Dom2R2 implies Dom1R1" a typo? That assertion seems to contradict the second line of the what should be enforced right below it.

Adam Young (ayoung) wrote :

This is not a correct statement:
"User2 can create a role Dom2R2 implies Dom1R1"

Since Dom2R2 and Dom1R1 are both domain specific roles, and specific to different domains, one should not be able to imply the other.

I am fairly certain I mean that line to read:
"User2 can create a role Dom2R2 implies Dom2R1"

Fix proposed to branch: master
Review: https://review.opendev.org/680795

Changed in keystone:
assignee: nobody → Colleen Murphy (krinkle)
status: Triaged → In Progress

Fix proposed to branch: master
Review: https://review.opendev.org/680796

Fix proposed to branch: master
Review: https://review.opendev.org/680797

Reviewed: https://review.opendev.org/680795
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=00c2ecdf333c4026990fd04a44ce3692345ff4cc
Submitter: Zuul
Branch: master

commit 00c2ecdf333c4026990fd04a44ce3692345ff4cc
Author: Colleen Murphy <email address hidden>
Date: Fri Sep 6 20:25:07 2019 -0700

    Implement system reader for implied roles

    This change updates the implied roles policies to understand the system
    reader role, and includes tests for system reader and system member. A
    follow-on change will add support for system admin. For the time being,
    we're deferring adding support for domain users to create implied roles
    but may add it in the future.

    Change-Id: I71f80eed5cd689505c7fd07f133e74f0e8edf66a
    Partial-bug: #1805371

Reviewed: https://review.opendev.org/680796
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=ee60db6f33554ccf613471d21832113ea9acdde1
Submitter: Zuul
Branch: master

commit ee60db6f33554ccf613471d21832113ea9acdde1
Author: Colleen Murphy <email address hidden>
Date: Fri Sep 6 20:45:27 2019 -0700

    Implement system admin for implied roles

    This change updates the create and delete actions for the implied roles
    policies to support the system-specific admin check string. For the time
    being, we're deferring adding support for the domain scope type and
    domain-specific check strings, but may add it in the future.

    Change-Id: I649f8f919fffc751aea750a5228f71cec8c6e184
    Partial-bug: #1805371

Reviewed: https://review.opendev.org/680797
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=afb312529ba1e1eb5acb9598d792f39f5a2500d7
Submitter: Zuul
Branch: master

commit afb312529ba1e1eb5acb9598d792f39f5a2500d7
Author: Colleen Murphy <email address hidden>
Date: Fri Sep 6 21:02:44 2019 -0700

    Remove implied roles policies from v3cloudsample

    By incorporating system scope and default roles into keystone's default
    policies for implied roles, we've effectively made these policies
    obsolete.

    Change-Id: I75515d3491517ea6e6fa17473a7890ce4653b481
    Partial-bug: #1806762
    Closes-bug: #1805371

Changed in keystone:
status: In Progress → Fix Released

This issue was fixed in the openstack/keystone 16.0.0.0rc1 release candidate.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers