Open Stack

On Tue, 31 Aug 2021 at 14:50, Pavlo Shchelokovskyy
<pshchelokovskyy at mirantis.com> wrote:
>
> 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.

Some loosely-related context:

There are certainly some operational issues when using encrypted
volumes. In a recent project we used custom policy to meet the
requirements to avoid some issues. We configured nova & cinder to send
a service token to barbican, and configured the barbican policy to
only allow secret decryption for certain combinations of user roles
and service roles. This allows an operator with a particular role to
migrate another user's instance, but prevents them from reading the
secret directly since they wouldn't have the service role.

Unfortunately it was not possible to do the same for barbican secrets
since there is a hard coded project check in the barbican DB layer
which bypasses policy.

Some related patches:

* https://review.opendev.org/c/openstack/castellan/+/769560
* https://review.opendev.org/c/openstack/nova/+/781079

Other patches are yet to make it out of the environment.

>
> Best regards,
> Pavlo.