@erictune @lavalamp Have we done anything about this or are we planning to do this soon?

Kubelets talk insecure TLS to apiserver on GCE, so that they can generate events.
Bugs are open to make that work on other cloud providers.
The minion self registration thing we talked about this afternoon would add secure TLS.

This depends on #3168 to get the certs in place.

I think this will be entirely? done once #3168 is in place -- kubelets only talk to api server and will be secure. Ditto kubeproxy. Nodes won't use clustered-salt for setup, but rather per-node salt (for all providers?). I propose if there are remaining work items, we fork those to specific issues tracking them.

I created a new cluster on GCE using default settings to do an audit of our current state of intra-cluster communication security.

I started by looking through the open ports (using netstat -an).

The master is listening on a variety of TCP ports, but many of these (7001, 10250, 10251, 10252, 2380, 8080) are only bound to the loopback address and thus wouldn't result in any communication traversing the network. Two ports (7080 and 6443) were open to the internal GCE network (10.240.x.x). And a handful of ports (22, 443, 4001, 4194) were open on all interfaces. As far as securing communications goes, ssh (22), https (443) and the read/write server on the master (6443) are all ok. There is no need for etcd (4001) or cAdvisor (4194) on the master to be reachable from elsewhere in the cluster and once we have secured master/node communication (#3168) we should be able to upgrade the read-only server on the master (7080) from http to https.

Each node is listening for tcp connections on ports 22 (ssh), 4194 (cAdvisor), 10250 (kubelet), and 10249 (kube-proxy healthz port) and all of these endpoints are open on all interfaces. The kubelet is currently contacted over http but will be upgraded to https as part of #3168. cAdvisor and kube-proxy are both serving http and should either be upgraded to https or only bind to localhost (if they don't need to be contacted remotely).

In addition to the open ports, I looked at the active network connections on the various VMs.

The nodes had established connections to the master on port 6443 (read-write) and 7080 (read-only) -- these communications should both be secured. All machines had connections to 169.254.169.254 on port 80 which is the local metadata server and doesn't leave the local machine (and is thus secure) -- this also isn't applicable for non-GCE deployments. The master had established connections to each node VM on port 10250 (kubelet) but I didn't see any connections to cAdvisor or the kube-proxy.

I also saw connections to two container IP addresses -- 10.244.2.2:8086 (influx grafana controller) and 10.244.3.3:9200 (elastic search logging controller) -- both of which are serving http connections. We are also sending udp packets to the cluster DNS service on port 53.

1. Fixing port 7080 and kubernetes-ro
   1. Fix kube-proxy to use 6443 instead of 7080: Move kube-proxy to use authed-port instead of readonly-port. #5917
   2. Fix things that use kubernetes-ro service and KUBERNETES_RO env vars, including kube2sky, elasticsearch, and several examples. Securing kubernetes-ro use cases #5921

I've split the remaining work out into smaller issues:

• etcd on the master should only be accessible from localhost: etcd on the master should only be accessible from localhost #5962
• kube-proxy healthz port should only be accessible from localhost: kube-proxy healthz port should only be accessible from localhost #5963
• influx grafana controller should be reachable securely: influx grafana controller should be reachable securely #5964
• elastic search logging controller should be reachable securely: elastic search logging controller should be reachable securely #5965
• cAdvisor should only be accessible from localhost: cAdvisor should only be accessible from localhost #5967
• cluster dns should be reachable securely: cluster dns should be reachable securely #5968

so I'm going to close this overarching issue.