disable kubelet readonly access from outside cluster

[sym3tri]

Port 10255 should only be accessible from other cluster master/worker nodes.

[philips]

Agree we should do this but:

@aaronlevy said that this should be bound to localhost
@Quentin-M said this should likely just be removed, the reason we used it is no longer in use

[aaronlevy]

heapster / prometheus might still want access to this -- which would mean wherever they run would need access. At minimum this needs to be available on localhost because the pod-checkpointer uses this.

[philips]

@aaronlevy Can you link to the docs/resources on how we secure this port and get the certs to heapster, etc?

[philips]

This is the doc line from kubelet docs https://kubernetes.io/docs/admin/kubelet/

--read-only-port int32                                    The read-only port for the Kubelet to serve on with no authentication/authorization (set to 0 to disable) (default 10255)

[fabxc]

We have a new release pending for tectonic-prometheus-operator and the question is whether we switch to the secure port + certs or not.
What's the current status of this? #223 indicates its kinda stuck due to checkpointing requiring the insecure port. If this gets deferred for a while, we'd move forward while keeping the read-only port.

[fabxc]

So I talked to @s-urbaniak about this as well.

When it seemed an easy target we did implement this: https://github.com/coreos-inc/tectonic-prometheus-operator/pull/34
But it depends on changes in the installer and a decision considering points in #223.

As the discussion stalled there, by now it seems unlikely that this is feasible for the next release, which is already pretty packed with heavy changes. @s-urbaniak, @alexsomesan, and I would suggest to defer this change to the next release to have more confidence in making the required changes.

(Discussion is not always clearly distinguishing between completely disabling the read-only port vs just blocking it from outside of the cluster. I'm referring to the former above – the latter is no problem for us an what @s-urbaniak is working on AFAIK.)