API get requests should list secret owner's project_id

Bug #1629511 reported by Stephen Balukoff on 2016-10-01
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Barbican
In Progress
Wishlist
cheng

Bug Description

For 3rd party services like neutron-lbaas and octavia, the user grants permission via an ACL to the service to access barbican secrets and secret containers in order to deploy 3rd party service resources that use the barbican assets. (For example, to deploy a load balancer that makes use of a certificate container stored in barbican, user A grants access to neutron-lbaas to a secret container she has uploaded to barbican.)

This means that for large clouds, there may be many users and projects that have granted the service access to their barbican secrets.

A problem arises in this case, that user A may upload a secret and accidentally make the href to access the secret known publicly. Barbican ACLs prevent user B on the same cloud from directly accessing user A secret; However, nothing is preventing user B from directing the 3rd party service (eg. neutron-lbaas) to deploy a resource using user A's secret, since the 3rd party service has no way of knowing which user/project owns the barbican secret at any given URL.

If barbican listed the secret owner's project_id when the secret's meta-data is accessed (eg. through a "openstack secret get <URL>" command), then 3rd party services could enforce the constraint that users may only access secrets they own.

In other words: Please add the owner's project_id as a field returned by the API whenever a secret or secret container is accessed, so we developers of 3rd party services can prevent the security problem described above!

Changed in barbican:
status: New → Triaged
status: Triaged → Confirmed
importance: Undecided → Wishlist
cheng (tangch318) on 2017-05-07
Changed in barbican:
assignee: nobody → cheng (tangch318)

Fix proposed to branch: master
Review: https://review.openstack.org/463269

Changed in barbican:
status: Confirmed → In Progress

Change abandoned by Douglas Mendizábal (<email address hidden>) on branch: master
Review: https://review.openstack.org/463269
Reason: Abandoning patch due to lack of activity for months. Feel free to re-submit if needed.

Change abandoned by Ade Lee (<email address hidden>) on branch: master
Review: https://review.openstack.org/477733
Reason: It looks like the server side patch was abandoned for lack of activity. Is there any point to the client side patch without server support?

Feel free to resurrect when we can get both sides of the feature in.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers