← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1748970] [NEW] bootstrapping system administrator causes issues with tempest

 

Public bug reported:

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/

** Affects: keystone
     Importance: High
         Status: Triaged

** Affects: tempest
     Importance: Undecided
         Status: New


** Tags: queens-backport-potential

** Changed in: keystone
       Status: New => Triaged

** Changed in: keystone
   Importance: Undecided => High

** Also affects: tempest
   Importance: Undecided
       Status: New

** Tags added: queens-backport-potential

-- 
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:
  bootstrapping system administrator causes issues with tempest

Status in OpenStack Identity (keystone):
  Triaged
Status in tempest:
  New

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


Follow ups