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

Gary Kotton gkotton at vmware.com
Wed Apr 6 15:49:43 UTC 2016

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
>> 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
>> 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
>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.

What about having metadata support HTTPS?

>> 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
>> key and the server, and build a work flow based on some signed document
>> the VM?
>orFrSzQyAW8b93HqsY5XVNomIMKWyfg1bos&e=       -o-
>HDQ3tqvwo&s=_gK2KOkWFfLW-FbojWkpCgftjVLN_QZDGkjh8pMnls0&e=  :|
>fw5GFNoKeCd5_x2TQdaMSYWCRtjLOBMBnU&e=               -o-
>oB0qqGMKwvX2dYl1m-qYeJRYIU_XnKP4o2bR8pLQ4&e=  :|
>SpSW3eL2vujxnGA8kwXnfy7cqGKvNIztgils&e=        -o-
>qvwo&s=uigHG_KOapyOIfMYts-LD2fB5Tbvk-7C3fTHl8KntLU&e=  :|
>S8SF6URSAV0y9k6m_v9KqNluZ_ocrHkp9_U5lYxDzfU&e=        -o-
>o&s=TMVQTuB-w7M5dWCDE3CRseA9l-xWWfqP-tlPW34Lqg4&e=  :|
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe

More information about the OpenStack-dev mailing list