cc @craigmcl

Can the "the local SSH daemon" be taught the pod's IP address, such that you would not need to use the hostPort feature at all?

I am just using a vanilla container vm ... do any of the pod concept apply? That said, I don't know enough about pods, and so I don't know.

See also #222

This sounds like a use case that external IPs could / should also solve. I'm not sure having pods punch their own holes in the infrastructure is a resilient system to rescheduling (pod goes away, a new copy is bound to a new host, any new connections fail).

As mentioned above, I am using a single container vm for its vm capabilities + ability to run a docker container, so I don't know how/if any of the pod functionality applies here.

As for the point about external IPs, the reason this bug was logged is because firewall settings were insufficient. Inadvertent opening of a port would lead to too big of a surface area exposed, because of the nature of the process running on that port.

At the most fundamental level, the docker command offers the ability to restrict the port to the local interface. The docker command is derived from the container vm manifest, and not directly specifiable. So the bug here is about getting the ability to specify that bit of the docker command via the container manifest.

When running with containerVM, kublet makes a pod out of the stuff you put in the container manifest. Pods get their own IP address (we make a docker container for the network namespace).

Setting a hostPort causes the port to be exposed on both the pod's IP, and the node's external IP. So to solve this problem, you just need to stop using hostPort. If you do that, then there's multiple ways you could figure out what your pod's IP ended up being. 1. talk to kubelet, hit /podInfo, parse the json blob-- I think you can find the IP in that. 2. is docker ps and figure out our naming system to find the network contain we made for you; I do not recommend that, it's likely to be brittle.

Finally, since we're talking security: you need to make sure your kubelet is either not listening on the public interface or behind a firewall; IIRC kubelet allows starting arbitrary containers over an http endpoint, and even if we took that out, it will allow remote log viewing and all the stuff in /podInfo...

We would prefer to avoid that level of indirection if possible. We want Docker to wire 127.0.0.1:9999 (e.g.) to the container, then we can use that static port for SSH port forwarding.

Is there any way to configure on which interfaces, if any, the Kubelet is listening through the containerVM manifest?

Responding to the original bug, I might be OK to simply add a flag to Port
such as HostPortLocalOnly, but it's pretty obscure.

On Thu, Nov 6, 2014 at 3:41 PM, mmdriley notifications@github.com wrote:

We would prefer to avoid that level of indirection if possible. We want
Docker to wire 127.0.0.1:9999 (e.g.) to the container, then we can use
that static port for SSH port forwarding.

Is there any way to configure on which interfaces, if any, the Kubelet is
listening through the containerVM manifest?

Reply to this email directly or view it on GitHub
#2139 (comment)
.

+1 I just ran into this problem. It would make things easier if we can specify the interface.

Can you explain why? The same arguments apply - specifying an interface is
an even deeper level of coupling that we should not enable without serious
use-cases.
On Dec 5, 2015 8:22 AM, "wikiwi" notifications@github.com wrote:

+1 I just ran into this problem. It would make things easier if we can
specify the interface.

—
Reply to this email directly or view it on GitHub
#2139 (comment)
.

This is not exactly the published issue, but we are definitely getting folks with standard multi network setups who want to have pods listen on distinct interfaces (which correspond to existing network infrastructure choices, like control plane vs storage plane vs public plane). I had been leaning towards allowing a network plugin to solve this use case, but it would have to involve some level of setup in the cluster. Then the network plugin can look at annotations or labels.

For bridging to physical networks, I think we can consider some first class
support for Networks. I think that is a real use case.

I am less sure aboyt host ports, or at least it shouldn't be per-pod but a
config of the kubelet. But I think we need some real explorations before
we jump on this.
On Dec 5, 2015 10:16 AM, "Clayton Coleman" notifications@github.com wrote:

This is not exactly the published issue, but we are definitely getting
folks with standard multi network setups who want to have pods listen on
distinct interfaces (which correspond to existing network infrastructure
choices, like control plane vs storage plane vs public plane). I had been
leaning towards allowing a network plugin to solve this use case, but it
would have to involve some level of setup in the cluster. Then the network
plugin can look at annotations or labels.

—
Reply to this email directly or view it on GitHub
#2139 (comment)
.

As per the discussion in the issue, this can be a use case of multiple-networks.

@nikhilk Would you please join the mailing list and post your use case there?
see: https://groups.google.com/forum/#!topic/kubernetes-sig-network/8nDSQ2hF40w

Given the age of the conversation here I think we should close this and re-open / create a new issue if there are more recent requests for this. Will close in a few days if there are no objections.

/assign

/close