yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #96350
[Bug 2121622] [NEW] Glance Service API policy rule does not check user 'service' role
Public bug reported:
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.
** Affects: glance
Importance: Undecided
Status: New
--
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 Glance:
New
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/glance/+bug/2121622/+subscriptions
Follow ups