<div dir="ltr">Hi all,<br><br>When Barbican is involved, and services like Nova and Cinder create secrets behind the scenes themselves,<br>this results in problems deleting or otherwise managing some resources by cloud admins.<br><br>For example as described in <a href="https://bugs.launchpad.net/cinder/+bug/1775372">https://bugs.launchpad.net/cinder/+bug/1775372</a>,<br>admin can not delete an encrypted volume created by another user,<br>and needs to resort to adding herself to the project first with appropriate roles.<br><br>This stems IMO from the difference in default resource access policies between Barbican and other services that consume it.<br>For example, while in Nova or Cinder, cloud admin by default can delete servers or volumes in other projects,<br>in Barbican by default only secret creator or admin "in the same project" can delete a secret.<br><br>I came up with at least 3 solutions (already mentioned in the issue above) but would like<br>to discuss their validity, pros and cons, and especially how they affect the security model<br>and the use cases that this Nova-Cinder-Barbican integration aims to solve.<br><br>1. Just ignore failure to delete a secret and log appropriate warning that a secret may be left orphaned.<br>Obviously not the best solution, but rather simple one, also will protect from cases when for whatever reason<br>a secret will be deleted from Barbican directly (e.g. by mistake), rendering volume undeletable for anyone.<br>   <br>2. Change default barbican policies to allow secret deletion for cloud admin (system scope?).<br>Naturally has implications for the Barbican model for resources access, so may be not that appropriate.<br>   <br>3. Store the secrets in the service project instead of user's.<br>Currently those secrets are generated by Nova or Cinder themselves, and user quite probably is not even aware<br>that there was something created in Barbican on her behalf. The user also has no option to pass her own secrets<br>to any of the involved API calls, so this is something happening completely behind the scenes.<br>So do we really need to store these secrets in the user's project?<br>Wouldn't it be better to store them in the service project, have the same service user defined in Nova and Cinder,<br>so it can operate and access those secrets regardless of who manages the resource which depends on access to this secret?<br>This also may solve the problem of encrypted local instance images in Nova, where upon host restart,<br>Nova is not able to bring those instances up because it lacks the context capable of accessing those secrets.<br>   <br>I think the third option is the best one, but I may be missing the actual use case meant behind this feature.<br>Is it "keep the data encrypted at rest and in transit" or more strictly "encrypt data of different users with different keys<br>and limit access to those keys" (for the case of breach etc) ?<br>In the first case it seems storing all the auto-generated secrets in a service project would suffice...<br><br>Please help me understand the best approach to take.<br><br>Best regards,<br>Pavlo.</div>