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

Hayes, Graham graham.hayes at hpe.com
Wed Apr 6 16:11:36 UTC 2016


On 06/04/2016 17:04, Daniel P. Berrange wrote:
> 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.
>

Sorry - I knew the actual HTTP server was else where, but I thought the
network traffic was taken out of the tenant space at the compute node,
and then moved to the underlying cloud infrastructure networking.

If that network is MITM'd there could be bigger issues.




More information about the OpenStack-dev mailing list