[openstack-dev] [nova] Minimal secure identification of a new VM
Daniel P. Berrange
berrange at redhat.com
Wed Apr 6 16:04:42 UTC 2016
On Wed, Apr 06, 2016 at 04:03:18PM +0000, Hayes, Graham wrote:
> On 06/04/2016 16:54, Gary Kotton wrote:
> >
> >
> > On 4/6/16, 12:42 PM, "Daniel P. Berrange" <berrange at redhat.com> wrote:
> >
> >> 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.
>
> I thought the metadata API traffic was taken off the network by the
> compute node? Or is that just under the old nova-network?
Nope, there's no guarantee that the metadata server will be on the
local compute node - it might be co-located, but it equally might
be anywhere else.
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