Open Stack

Hi all,

When Barbican is involved, and services like Nova and Cinder create secrets
behind the scenes themselves,
this results in problems deleting or otherwise managing some resources by
cloud admins.

For example as described in https://bugs.launchpad.net/cinder/+bug/1775372,
admin can not delete an encrypted volume created by another user,
and needs to resort to adding herself to the project first with appropriate
roles.

This stems IMO from the difference in default resource access policies
between Barbican and other services that consume it.
For example, while in Nova or Cinder, cloud admin by default can delete
servers or volumes in other projects,
in Barbican by default only secret creator or admin "in the same project"
can delete a secret.

I came up with at least 3 solutions (already mentioned in the issue above)
but would like
to discuss their validity, pros and cons, and especially how they affect
the security model
and the use cases that this Nova-Cinder-Barbican integration aims to solve.

1. Just ignore failure to delete a secret and log appropriate warning that
a secret may be left orphaned.
Obviously not the best solution, but rather simple one, also will protect
from cases when for whatever reason
a secret will be deleted from Barbican directly (e.g. by mistake),
rendering volume undeletable for anyone.

2. Change default barbican policies to allow secret deletion for cloud
admin (system scope?).
Naturally has implications for the Barbican model for resources access, so
may be not that appropriate.

3. Store the secrets in the service project instead of user's.
Currently those secrets are generated by Nova or Cinder themselves, and
user quite probably is not even aware
that there was something created in Barbican on her behalf. The user also
has no option to pass her own secrets
to any of the involved API calls, so this is something happening completely
behind the scenes.
So do we really need to store these secrets in the user's project?
Wouldn't it be better to store them in the service project, have the same
service user defined in Nova and Cinder,
so it can operate and access those secrets regardless of who manages the
resource which depends on access to this secret?
This also may solve the problem of encrypted local instance images in Nova,
where upon host restart,
Nova is not able to bring those instances up because it lacks the context
capable of accessing those secrets.

I think the third option is the best one, but I may be missing the actual
use case meant behind this feature.
Is it "keep the data encrypted at rest and in transit" or more strictly
"encrypt data of different users with different keys
and limit access to those keys" (for the case of breach etc) ?
In the first case it seems storing all the auto-generated secrets in a
service project would suffice...

Please help me understand the best approach to take.

Best regards,
Pavlo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210831/dfbf1967/attachment.html>