yahoo-eng-team team mailing list archive

[OpenStack Infra <1748970@xxxxxxxxxxxxxxxxxx>]

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

commit a226a3d8be5ba720f149606a84df0432ec4858c7
Author: Lance Bragstad <lbragstad@xxxxxxxxx>
Date:   Tue Feb 13 16:52:57 2018 +0000

    Expose bug in /role_assignments API with system-scope
    
    The role_assignment API supports a bunch of query parameters that
    gives users flexibility when querying for role assignments. This
    commit exposes an issue when querying keystone for a specific role
    using /role_assignments?role.id={role_id}. The expected result was
    that the returned list would only contain role assignments for that
    specific role ID. The actual result is a set of role assignments with
    that role ID and all system role assignments.
    
    This caused issues in tempest because tempest goes through and cleans
    up resources using `tearDownClass`, and it is common to remove
    specific roles used in the test class. The problem is that keystone
    queries the role assignment API for all role assignment with a
    specific role ID, which is the equivalent to
    `GET /v3/role_assignments?role.id={role_id}` when deleting a role. The
    list returned included false positives, which were system role
    assignments, resulting in revocation events getting persisted for
    users in those role assignments. This prevented the administrator in
    tempest from cleaning up the rest of the resources because the
    revocation event would make the token being used to do resource
    cleanup.
    
    This commit exposes the bug using tests.
    
    Change-Id: If93400be3c9d3fe8e266bb36c16accca93d77154
    Partial-Bug: 1748970


** Changed in: keystone
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1748970

Title:
  Role assignment API doesn't prune system roles when querying
  role.id={role_id}

Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Identity (keystone) queens series:
  In Progress
Status in tempest:
  Invalid

Bug description:
  During the Queens release, keystone added support for a new scope type
  called system. This extended the support for users and groups to not
  only have roles on projects and domains, but also on a different
  entity called the "system". This is an effort to make RBAC support
  more flexible and robust, in a way to isolate system administrative
  APIs from project or end-user APIs.

  During keystone's boostrapping process, it attempts to setup an
  administrator for the deployment. To be backwards compatible, the
  implementation for system scope included a patch to ensure the admin
  user not only had authorization on at least one project, but also the
  system [0]. This makes it so that new and old installations are
  guaranteed an administrative user for all APIs by running an
  idempotent operation. Otherwise it would be possible for an
  administrative user to lock themselves out of system-level APIs if
  they opt into enforcing scope without having at least one system
  administrator.

  The patch to add this functionality is currently failing tempest [0],
  even though tempest doesn't know anything about system role
  assignments or requesting system scoped tokens. Opening this bug so
  that we can investigate tempest and understand how adding a separate
  role assignment is resulting 401 Authorized responses during tempest
  tests.

  [0] https://review.openstack.org/#/c/530410/

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1748970/+subscriptions