[openstack-dev] [nova] Minimal secure identification of a new VM
Hayes, Graham
graham.hayes at hpe.com
Wed Apr 6 16:03:18 UTC 2016
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?
>> 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.
>
> What about having metadata support HTTPS?
How do you get the CA cert on to the VM then?
It is more difficult than it seems.
>>
>>> 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
>> --
>> |:
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__berrange.com&d=BQICAg&
>> c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YT
>> eq9N3-diTlNj4GyNc&m=lt2m-p7I77Tg88WS4WvodfNMyitjWmfDMMHDQ3tqvwo&s=SYfUKobB
>> orFrSzQyAW8b93HqsY5XVNomIMKWyfg1bos&e= -o-
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.flickr.com_photos_
>> dberrange_&d=BQICAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHp
>> ZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=lt2m-p7I77Tg88WS4WvodfNMyitjWmfDMM
>> HDQ3tqvwo&s=_gK2KOkWFfLW-FbojWkpCgftjVLN_QZDGkjh8pMnls0&e= :|
>> |:
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__libvirt.org&d=BQICAg&c
>> =Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTe
>> q9N3-diTlNj4GyNc&m=lt2m-p7I77Tg88WS4WvodfNMyitjWmfDMMHDQ3tqvwo&s=Yguim8-Kw
>> fw5GFNoKeCd5_x2TQdaMSYWCRtjLOBMBnU&e= -o-
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__virt-2Dmanager.org&d=B
>> QICAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9J
>> YBk8YTeq9N3-diTlNj4GyNc&m=lt2m-p7I77Tg88WS4WvodfNMyitjWmfDMMHDQ3tqvwo&s=tw
>> oB0qqGMKwvX2dYl1m-qYeJRYIU_XnKP4o2bR8pLQ4&e= :|
>> |:
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.org&d=BQICAg
>> &c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8Y
>> Teq9N3-diTlNj4GyNc&m=lt2m-p7I77Tg88WS4WvodfNMyitjWmfDMMHDQ3tqvwo&s=iSsOzMl
>> SpSW3eL2vujxnGA8kwXnfy7cqGKvNIztgils&e= -o-
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__search.cpan.org_-7Edan
>> berr_&d=BQICAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzz
>> kWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=lt2m-p7I77Tg88WS4WvodfNMyitjWmfDMMHDQ3t
>> qvwo&s=uigHG_KOapyOIfMYts-LD2fB5Tbvk-7C3fTHl8KntLU&e= :|
>> |:
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__entangle-2Dphoto.org&d
>> =BQICAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz
>> 9JYBk8YTeq9N3-diTlNj4GyNc&m=lt2m-p7I77Tg88WS4WvodfNMyitjWmfDMMHDQ3tqvwo&s=
>> S8SF6URSAV0y9k6m_v9KqNluZ_ocrHkp9_U5lYxDzfU&e= -o-
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__live.gnome.org_gtk-2Dv
>> nc&d=BQICAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT
>> 5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=lt2m-p7I77Tg88WS4WvodfNMyitjWmfDMMHDQ3tqvw
>> 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
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
More information about the OpenStack-dev
mailing list