Open Stack

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
>