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