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!
Fix proposed to branch: master
Review: https:/