Dear Mohammed, with SecuStack we've been integrating end-to-end (E2E) transfer of secrets into the OpenStack code. From your problem description, it sounds like our implementation would address some of your points. For below explanation, I will refer to those secrets as "keys".
Our solution works as follows: - when the user creates an encrypted resource, they may specify to use E2E key transfer instead of Barbican - the resource will be allocated and enter a state where it is waiting for the transmission of the key - the user establishes an E2E relationship with the compute/volume host where the resource has been scheduled - the key is encrypted (asymmetrically) on the user side specifically for this host (using its public key) and transferred through the API to this host - the key reaches the compute/volume host, is decrypted by the host's private key and is then used temporarily for the duration of the resource creation and discarded afterwards Whenever such resource is to be used (instance booted or volume attached), a similar workflow is triggered on-demand that requires the key to be transferred via the E2E channel again. Our solution is complemented by an extension of the Barbican workflow which also allows users to specify secret IDs and manage them manually for encrypted resources instead of having OpenStack handle all of that automatically. This represents a solution that is kind of in-between the current OpenStack and our E2E approach. We have not looked into external Barbican integration yet, though. We do plan to contribute our E2E key transfer and user-centric key control to OpenStack, if we can obtain support for this idea. However, we are currently in the middle of trying to contribute image encryption to OpenStack, which is already proving to be a lengthy process as it involves a lot of different teams. The E2E stuff would be an even bigger change across the components. Unfortunately, we currently don't have the resources to tackle two huge contributions at the same time as it requires a lot of effort getting multiple teams to agree on a single solution. Best regards, Markus Hentsch Mohammed Naser wrote: > Hi everyone: > > I've been digging around the documentation of Nova, Cinder and the > encrypted disks feature and I've been a bit stumped on something which > I think is a very relevant use case that might not be possible (or it > is and I have totally missed it!) > > It seems that both Cinder and Nova assume that secrets are always > stored within the Barbican deployment in the same cloud. This makes a > lot of sense however in scenarios where the consumer of an OpenStack > cloud wants to operate it without trusting the cloud, they won't be > able to have encrypted volumes that make sense, an example: > > - Create encrypted volume, keys are stored in Barbican > - Boot VM using said encrypted volume, Nova pulls keys from Barbican, > starts VM.. > > However, this means that the deployer can at anytime pull down the > keys and decrypt things locally to do $bad_things. However, if we had > something like any of the following two ideas: > > - Allow for "run-time" providing secret on boot (maybe something added > to the start/boot VM API?) > - Allow for pointing towards an external instance of Barbican > > By using those 2, we allow OpenStack users to operate their VMs > securely and allowing them to have control over their keys. If they > want to revoke all access, they can shutdown all the VMs and cut > access to their key storage management and not worry about someone > just pulling them down from the internal Barbican. > > Hopefully I did a good job explaining this use case and I'm just > wondering if this is a thing that's possible at the moment or if we > perhaps need to look into it. > > Thanks, > Mohammed > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
