← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 2121622] Re: Glance Service API policy rule does not check user 'service' role

 

Reviewed:  https://review.opendev.org/c/openstack/cinder/+/958716
Committed: https://opendev.org/openstack/cinder/commit/9dfb500d5bb4fb6523731d7053a0424280d11da2
Submitter: "Zuul (22348)"
Branch:    master

commit 9dfb500d5bb4fb6523731d7053a0424280d11da2
Author: Ghanshyam Maan <gmaan@xxxxxxxxxxxxxxxxx>
Date:   Thu Aug 28 03:53:10 2025 +0000

    Register glance user in keystoneauth plugin
    
    The OpenStack services communicate with each other by
    passing the user token and service token wrapped in
    keystoneauth's ServiceTokenAuthWrapper. The purpose
    of passing the service token is for long-running
    operations and in case the user token gets expired.
    
    For RBAC, services need to check if a user token has the
    'service'
    role or not. For that calling service needs to load the
    configured user auth plugin (where the user should have
    the 'service' role) from keystoneauth and pass that to
    the other services and called service (glance in this case)
    will use that user role to verify the policy permission.
    
    Cinder register and load user auth plugin from keystonauth
    for nova communication case
    - https://github.com/openstack/cinder/blob/644b6362a6b0debf6395d4bf15f963faf1a42ced/cinder/compute/nova.py#L100
    
    But it is missing for glance case which is fixed in this change.
    
    Closes-Bug: #2121622
    Needed-By: https://review.opendev.org/c/openstack/glance/+/958715
    
    Change-Id: Ia3fe15517cdbeb8295725b99b526dd70ce290562
    Signed-off-by: Ghanshyam Maan <gmaan@xxxxxxxxxxxxxxxxx>


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

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/2121622

Title:
  Glance Service API policy rule does not check user 'service' role

Status in Cinder:
  Fix Released
Status in Glance:
  In Progress

Bug description:
  Glance service APIs are default to 'service_roles: service'

  -
  https://github.com/openstack/glance/blob/6c33a667a9f5ddce07b6131f4a5cb7460a4bdf17/glance/policies/base.py#L116

  The issue here is the service token, which is sent from the service
  for the user token expiry case but glance uses that service token
  (keystonemiddleware sets the service token roles in Requestcontext in
  'service_roles' field) for RBAC, which is not correct.

  Use case of service token for user token expiry:
  ------------------------------------------------

  This is a case where services call other services to complete the user
  operation. The user operation can be a long-runnning one, andthe  user
  token may expire while the operation is still in progress. For that
  Service Token concept was introduced. Service calling another service
  needs to send the Service Token along with User Token.
  Keystonmiddleware will check if the Service Token is present and
  valid, then, it will not fail the request, even User Token is expired.

  Use case of service APIs access control in RBAC:
  ------------------------------------------------

  For RBAC, Service needs to send external user token to another service
  for non-service APIs call and inteernal user token for service only
  APIs. INternal user token needs to load the configured user auth
  plugin (where the user should have the 'service' role) from
  keystoneauth and send that to the another services. Services always
  need to check if user token has 'service' role so that they can make
  sure service only APIs are called by service.

  
  Problem of using Service Token for RBAC:
  ----------------------------------------
  Service Token will always have the 'service_roles: service' and if service APIs policy rule check Service Token's service_roles which will always be 'service' and will make service APIs policy rule noop and expose them to users who should not have access to them.

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



References