Open Stack

On Tue, 2021-08-31 at 16:46 +0300, Pavlo Shchelokovskyy 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.
this is mostly by design.
cloud admin shoudl not be able to access tenat secret or teants cannot trust the
cloud.
> 
> 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.
yep although i woudl argue that unless that is an abuse of admin privialges.
there are some case where the admin woudl have to intervient like this but
its generally agaisnt the self service model for admin to be doing this.
> 
> 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.
i am not sure i agree.

we intentionally do not allow admin to start instance that have encypted storage
as the admin should not be able to access the decrypted data.
yes they could always hack around this but to me this is intentioaly not supported
and not a bug.
> 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...
its both the intent is to keep the data encyprted at rest and in transit and ensur that admin
cannot decypt it. deletetion of hte resouce is perhaps somethign that could be allowable with a sytem admin token
retrivial of the secreate e.g. to start the vm or do a snapthot for exmaple i think would be a regression in security
and not something we shoudl do.

and yes im aware that admin can already change default plicy in barbican to allow them to retirve the securet or add themsevles
to the project to circumvent some of the protections. i dont think its in scope of nova ot manage any user secreate or user data in general.
moving this into the proejct like nova and cinder changes the security model and risk assment for operators and devleopers of thoes services.
we woudl be adding user data that need to be managed in a way that is complient with strict standard where as by using barbican we can cerntrailse
that to a singel service which has one role, manage secrets.
> 
> Please help me understand the best approach to take.
> 
> Best regards,
> Pavlo.