Re: [openstack-dev] [nova] Minimal secure identification of a new VM
On 04/06/2016 05:41 PM, Fox, Kevin M wrote: -1 for man in the middle susceptible solutions. This also doesn't solve all the issues listed in the spec, such as suspended nodes, snapshotted nodes, etc. Self signed MITM That is only an issue if you are not trusting the initial setup. I wan a real CA, we can't force everyone to do that. Secure the Message bus is essential anyway. Let's not piecemeal a solution here. Nova has several back channel mechanisms at its disposal. We should use one or more of them to solve the problem properly instead of opening a security hole in our solution to a security problem. Such as: * The nova console is one mechanism that could be utilized as a secure back channel. * The vm based instances could add a virutal serial port as a back channel. * Some bare metal bmc's support virtual cd's which could be loaded with fresh credentials upon request. * The metadata server is reliable in certain situations. I'm sure there are more options too. The instance user spec covers a lot of that stuff. I'm ok if we want to refactor the instance user spec to cover creating phase 1 credentials that are intended to be used for things other then getting a keystone token. It could be used to register/reregister with ipa, chef, puppet, etc. We just need to reword the spec to cover that use case too. I'm also not tied to the implementation listed. it just needs to meet the requirements. Thanks, Kevin From: Adam Young [ayo...@redhat.com] Sent: Wednesday, April 06, 2016 2:09 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] Minimal secure identification of a new VM On 04/06/2016 05:42 AM, Daniel P. Berrange 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. We need to secure the message queue from the compute node to conductor. This is very achievable: 1. Each compute node gets its own rabbit user 2. Messages from compute node to Conductor are validated as to what node sent them We should enable TLS on the network as well, or password can be sniffed. Self signed is crappy, but probably sufficient for a baseline deployment. Does not defend against MITM. Puppet based deployments can mitigate. X509 client cert is a better auth mechanism than password, but not essential. 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 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. 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 __ 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 ___
Re: [openstack-dev] [nova] Minimal secure identification of a new VM
-1 for man in the middle susceptible solutions. This also doesn't solve all the issues listed in the spec, such as suspended nodes, snapshotted nodes, etc. Nova has several back channel mechanisms at its disposal. We should use one or more of them to solve the problem properly instead of opening a security hole in our solution to a security problem. Such as: * The nova console is one mechanism that could be utilized as a secure back channel. * The vm based instances could add a virutal serial port as a back channel. * Some bare metal bmc's support virtual cd's which could be loaded with fresh credentials upon request. * The metadata server is reliable in certain situations. I'm sure there are more options too. The instance user spec covers a lot of that stuff. I'm ok if we want to refactor the instance user spec to cover creating phase 1 credentials that are intended to be used for things other then getting a keystone token. It could be used to register/reregister with ipa, chef, puppet, etc. We just need to reword the spec to cover that use case too. I'm also not tied to the implementation listed. it just needs to meet the requirements. Thanks, Kevin From: Adam Young [ayo...@redhat.com] Sent: Wednesday, April 06, 2016 2:09 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] Minimal secure identification of a new VM On 04/06/2016 05:42 AM, Daniel P. Berrange 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. We need to secure the message queue from the compute node to conductor. This is very achievable: 1. Each compute node gets its own rabbit user 2. Messages from compute node to Conductor are validated as to what node sent them We should enable TLS on the network as well, or password can be sniffed. Self signed is crappy, but probably sufficient for a baseline deployment. Does not defend against MITM. Puppet based deployments can mitigate. X509 client cert is a better auth mechanism than password, but not essential. > 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 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. > >> 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 __ 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
Re: [openstack-dev] [nova] Minimal secure identification of a new VM
On 04/06/2016 05:42 AM, Daniel P. Berrange 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. We need to secure the message queue from the compute node to conductor. This is very achievable: 1. Each compute node gets its own rabbit user 2. Messages from compute node to Conductor are validated as to what node sent them We should enable TLS on the network as well, or password can be sniffed. Self signed is crappy, but probably sufficient for a baseline deployment. Does not defend against MITM. Puppet based deployments can mitigate. X509 client cert is a better auth mechanism than password, but not essential. 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 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. 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 __ 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
Re: [openstack-dev] [nova] Minimal secure identification of a new VM
On 06/04/2016 17:38, Fox, Kevin M wrote: > A lot of the problems are documented here in the problem description section: > https://review.openstack.org/#/c/93/ > > Thanks, > Kevin I am very much ++ on instance users. > > From: Daniel P. Berrange [berra...@redhat.com] > Sent: Wednesday, April 06, 2016 9:04 AM > To: Hayes, Graham > Cc: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [nova] Minimal secure identification of a new VM > > On Wed, Apr 06, 2016 at 04:03:18PM +, Hayes, Graham wrote: >> On 06/04/2016 16:54, Gary Kotton wrote: >>> >>> >>> On 4/6/16, 12:42 PM, "Daniel P. Berrange" 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 :| > > __ > 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
Re: [openstack-dev] [nova] Minimal secure identification of a new VM
A lot of the problems are documented here in the problem description section: https://review.openstack.org/#/c/93/ Thanks, Kevin From: Daniel P. Berrange [berra...@redhat.com] Sent: Wednesday, April 06, 2016 9:04 AM To: Hayes, Graham Cc: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] Minimal secure identification of a new VM On Wed, Apr 06, 2016 at 04:03:18PM +, Hayes, Graham wrote: > On 06/04/2016 16:54, Gary Kotton wrote: > > > > > > On 4/6/16, 12:42 PM, "Daniel P. Berrange" 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 :| __ 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
Re: [openstack-dev] [nova] Minimal secure identification of a new VM
On 06/04/2016 17:04, Daniel P. Berrange wrote: > On Wed, Apr 06, 2016 at 04:03:18PM +, Hayes, Graham wrote: >> On 06/04/2016 16:54, Gary Kotton wrote: >>> >>> >>> On 4/6/16, 12:42 PM, "Daniel P. Berrange" 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. __ 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
Re: [openstack-dev] [nova] Minimal secure identification of a new VM
On Wed, Apr 06, 2016 at 04:03:18PM +, Hayes, Graham wrote: > On 06/04/2016 16:54, Gary Kotton wrote: > > > > > > On 4/6/16, 12:42 PM, "Daniel P. Berrange" 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 :| __ 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
Re: [openstack-dev] [nova] Minimal secure identification of a new VM
On 06/04/2016 16:54, Gary Kotton wrote: > > > On 4/6/16, 12:42 PM, "Daniel P. Berrange" 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= :| >> >> __ >>
Re: [openstack-dev] [nova] Minimal secure identification of a new VM
Nova Instance user spec. https://review.openstack.org/93 We really really need to solve this. it is affecting almost every project in one way or another. Can we please get a summit session dedicated to the topic? Last summit we had only 10 minutes. :/ Thanks, Kevin From: Adam Young [ayo...@redhat.com] Sent: Tuesday, April 05, 2016 3:00 PM To: OpenStack Development Mailing List Subject: [openstack-dev] [nova] Minimal secure identification of a new VM 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. 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? __ 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
Re: [openstack-dev] [nova] Minimal secure identification of a new VM
On 4/6/16, 12:42 PM, "Daniel P. Berrange" 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. > >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? > >> 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?s
Re: [openstack-dev] [nova] Minimal secure identification of a new VM
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. 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. > 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 -- |: 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 :| __ 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
Re: [openstack-dev] [nova] Minimal secure identification of a new VM
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. So this can be somewhat done already: https://cloudinit.readthedocs.org/en/latest/topics/examples.html#call-a-url-when-finished But unsure what endpoint u want that thing to call (and the data it sends might need to be tweaked); and said calling a URL might need https, which then begs the question of what certs and stuff is https using to ensure its calling a URL that is 'really nova'. 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? Seems like a useful idea, if we can figure out how to do it. -Josh __ 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-dev] [nova] Minimal secure identification of a new VM
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. 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? __ 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