← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1818850] Re: The v3 trust API should account for different scopes

 

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

commit 9be1caff97355099d25170fe390dd15d6f592d56
Author: Colleen Murphy <colleen.murphy@xxxxxxx>
Date:   Fri Aug 16 11:14:16 2019 -0700

    Implement system admin for trusts API
    
    This change enables a system admin to delete trusts. Previously, only
    the trustor or the is_admin admin could delete a trust. This changes
    makes the trusts API more useful to system administrators who need to
    clean up trusts and makes the API consistent with others.
    
    This does not enable system admins to create trusts. A trust can only be
    scoped to a project, so creating one is inherently a project-scoped
    action. If trusts later gain the ability to be scoped to the system or
    domains, we can add those scopes to the create_trust scope_types.
    
    Change-Id: Idf13b862f345388bb2372609787947eb43d7ba75
    Closes-bug: #1818846
    Closes-bug: #1818850
    Related-Bug: #968696


** 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/1818850

Title:
  The v3 trust API should account for different scopes

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  Keystone implemented scope_types for oslo.policy RuleDefault objects
  in the Queens release. In order to take full advantage of scope_types,
  keystone is going to have to evolve policy enforcement checks in the
  user API.

  The trust API and trust entities require projects in order to be
  useful, but allowing system users to list or manage trusts would be
  useful for support personnel.

  GET /v3/OS-TRUST/trusts or GET /v3/OS-TRUST/trusts/{trust_id}

  For example, a system user should be able to list all trusts in the
  deployment, while project users should only be able to access that API
  for trusts they own.

  POST /v3/OS-TRUST/trusts

  Only project users should be able to call this API since trusts
  require a project in order to be useful

  DELETE /v3/OS-TRUST/trusts/{trust_id}

  This API should be accessible to system administrators and users
  attempting to delete their own trust. This work might also present us
  with an opportunity to remove some of the logic in the trust API
  layer, in favor of something that's more commonly used across keystone
  APIs [0].

  [0]
  http://git.openstack.org/cgit/openstack/keystone/tree/keystone/api/trusts.py?id=6e3f1f6e46787ed4542609c935c13cb85e91d7fc#n45

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


References