On 06/04/2016 16:54, Gary Kotton wrote: > > > On 4/6/16, 12:42 PM, "Daniel P. Berrange" <berra...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
