[openstack-dev] [nova] Minimal secure identification of a new VM

Daniel P. Berrange berrange at redhat.com
Wed Apr 6 09:42:25 UTC 2016


On Tue, Apr 05, 2016 at 06:00:55PM -0400, Adam Young wrote:
> We have a use case where we want to register a newly spawned Virtual machine
> with an identity provider.
> 
> Heat also has a need to provide some form of Identity for a new VM.
> 
> 
> Looking at the set of utilities right now, there does not seem to be a
> secure way to do this.  Injecting files does not provide a path that cannot
> be seen by other VMs or machines in the system.
> 
> For our use case, a short lived One-Time-Password is sufficient, but for
> others, I think asymmetric key generation makes more sense.
> 
> Is the following possible:
> 
> 1.  In cloud-init, the VM generates a Keypair, then notifies the No0va
> infrastructure (somehow) that it has done so.

There's no currently secure channel for the guest to push information
to Nova. The best we have is the metadata service, but we'd need to
secure that with https, because the metadata server cannot be assumed
to be running on the same host as the VM & so the channel is not protected
against MITM attacks.

Also currently the metadata server is readonly with the guest pulling
information from it - it doesn't currently allow guests to push information
into it. This is nice because the metadata servers could theoretically be
locked down to prevent may interactions with the rest of nova - it should
only need read-only access to info about the guests it is serving. If we
turn the metadata server into a bi-directional service which can update
information about guests, then it opens it up as a more attractive avenue
of attack for guest OS trying breach the host infra. This is a fairly
general concern with any approach where the guest has to have the ability
to push information back into Nova.

> 2.  Nova Compute reads the public Key off the device and sends it to
> conductor, which would then associate the public key with the server?
> 
> 3.  A third party system could then validate the association of the public
> key and the server, and build a work flow based on some signed document from
> the VM?

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|



More information about the OpenStack-dev mailing list