本文将kubernetes master node与整个集群的通信路径分类，目的是使用户能够通过自定义安装强化网络配置，从而使集群运行在不受信任的网络之上，比如云供应商的全开放IP环境。通信路径分成两条：由master到集群、由集群到master。
cluster->master
所有从集群到master的通信路径终点都是apiserver，由kubernetes的安装部署可知道，其它控制面（master）全部都没有开放供其它组件访问的接口。一个典型的部署，apiserver被配置在安全的HTTPS端口（443）监听远程连接，同时可以使用多种被允许的认证方案对客户端进行身份认证。应该支持多种认证方案，特别是允许匿名请与service account token。
重要的一点，node要想通过安全连接访问apiserver，那么应该被提供根证书与可用的客户端证书。例如，在一个采用默认部署的GCE中，默认的客户端证书会提供给node上的kubelete。参考kubelet TLS bootstrapping实现kubelet客户端证书自动设置。
在pod内部想要安全的访问apiserver，需要给它提供一个service account，那么kubernetes在实例化pod时会自动的将根证书与可用的bearer token注入到实例化的pod中，kubernetes会为每个服务分配虚拟IP，最终通过kube-proxy的重定向指向apiserver的HTTPS endpoint。
同样所有的master上的组件都采用相同的方式与apiserver通信。
结果，apiserver是集群内部消息总线，所有其它组件与它的通信都是经过安全加密的，保证了在公网或者是不受信网络上的安全。
master->cluster
从master(apiserver)到集群的通信路径主要有两种：一条是从apiserver到集群每个node都运行的kubelet程序，这一条起的主要是控制流量。另一条是则是apiserver充当代理服务器时访问集群中任意node、pod、service的路径，这一条走的就是代理流量。
apiserver->kubelet
这一条路径主要用来：
- 从pod获取日志
- 启动pod
- 提供kubelet的端口转发功能
这种路径的终点是kubelet的HTTPS endpoint。默认情况下，apiserver不确认kubelet的身份，这使得apiserver在不安全的网络环境下容易受到中间人攻击。
如果想要认证kubelet身份的话，则需要为apiserver指定--kubelet-certificate-authority标志并提供根证书，这样的话apiserver就可以对kubelet的证书进行验证。
如果以上方案因某种原因不可行的话，也可以在kubelet与apiserver之间搭建SSH tunneling，实现在不安全的网络环境下建立安全通信的功能。
最后， Kubelet authentication and/or authorization 也应该被打开，以增强kubelet api的安全性。
apiserver -> nodes, pods, and services
首先，此时的apiserver充当的是外部访问集群内node、pod、service的代理。默认情况下apiserver访问这些资源时，使用的是HTTP，不认证身份也不加密通信通道。如果在通过apiserver代理访问内部资源时，如果在构造URL时，在node、pod、service等资源的名称前加上"https:"，那么apiserver访问这些资源时就会使用https协议。但是此时要注意，通信链路会加密，但是双方都不会验证证书的有效性，所以在不安全的网络环境中，这个路径是不安全的。