On 8/31/21 4:17 PM, Sean Mooney 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.
On Tue, 2021-08-31 at 16:46 +0300, Pavlo Shchelokovskyy wrote: 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.
On Thu, 2021-09-02 at 13:25 +0200, Thomas Goirand wrote: live-migration should actully work i belive for ceph. i think its just if the volume is host mounted like we do with isci that it fails. cold migration will partly work you just wont be able to start the instance so you can cold migrate a shut off instance. same for evacuate.
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.
sure but if its not running you can cold migrate it.
So there's a big issue to tackle here.
not really you should not be starting the instance in this case. if its off you should just cold migrate. that work in more cases the live migrate and is more effcinet since we wont have to copy any guest memory.
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.
this is hte how point of secure comptueing and the sev/image incryption work that peopel have been tryign to add to nova. the ablity to upload encypted images and use them to create encypted volumes that the admin cant access which can be verifyed using vtpm and other methods is becoming more and more a requirement for many government customers. this is why SEV support was intoduced to prevent admin form doing that. its not about being annoying to admins its about ensureing we can actuly use openstack in secure enviroment so that we can continue to support our customer that need a miniuma or zero trust solution.
Cheers,
Thomas Goirand (zigo)