Comment 10 for bug 1775372

we are hitting that as well

IMO it all boils down to default API access policies in Barbican are generally more strict than policies in other services using Barbican in respect for (global) admin actions.

I see at least 3 possible solutions, but we need to discuss consequences of each of them for the security model and use cases this functionality is intended to solve:

1) (as already mentioned) just ignore key deletion errors and orphan them with appropriate WARNING in the logs
2) change (default) api policies in Barbican to match its consumers and allow the same global admin to delete whatever secret it has to delete
3) store these auto-generated secrets under service user, at least make this choice available to operators via config option for new deployments. These secrets are basically transparent to the user, who may be oblivious to them being created and used in the first place, and user has no option to pass her own secret to the volume create / attach call, so why store them in the user's project at all? This of course highly depends on what use cases this encryption is actually trying to solve, and while it seems to me the best option, I may be missing something here...