Open Stack

On 8/31/21 4:17 PM, Sean Mooney wrote:
> 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.

access the secret != delete a secret ...

>> 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.

It's perfectly legitimate for an admin to delete *ANY* resource if he
feels he needs to. For example on a public cloud: after the grace period
expired. Example for an internal cloud: when an employee leaves.

>> 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.

It is a bug that we can't live-migrate LUKS volumes. Please do recognize
this as an OpenStack defect, because if you don't, you wont recognize we
need to fix the situation, which is kind of super bad.

>> 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.

We you can't start the VM, it means you can't live-migrate. So there's a
big issue to tackle here. I don't agree that it's a big issue that an
admin can access secrets, because it's already the case (ie: by adding
the creator role in that project). If you don't trust your admin: go
away, it's game over anyways. As for LUKS devices, it'd be trivial for
an admin to dump the VM's memory and access the decryption key
anyways... So you're only being annoying to the admins, and not
protecting anyone here.

Cheers,

Thomas Goirand (zigo)