各个组件未鉴权所能造成的风险，其实从它们在 Kubernetes 集群环境里所能起到的作用就能很明显的判断出来，如 APIServer 是所有功能的主入口，则控制 APIServer 基本上等同控制集群的所有功能；而 kubelet 是单个节点用于进行容器编排的 Agent，所以控制 kubelet 主要是对单个节点下的容器资源进行控制。
组件分工上较为完整的图例可参考：
想必这样也相对晦涩难懂，我简化了一下，假如用户想在集群里面新建一个容器集合单元，那各个组件以此会相继做什么事情呢？
用户与 kubectl 或者 Kubernetes Dashboard 进行交互，提交需求。（例: kubectl create -f pod.yaml）;
kubectl 会读取 ~/.kube/config 配置，并与 apiserver 进行交互，协议：http/https;
apiserver 会协同 ETCD 等组件准备下发新建容器的配置给到节点，协议：http/https（除 ETCD 外还有例如 kube-controller-manager, scheduler 等组件用于规划容器资源和容器编排方向，此处简化省略）;
apiserver 与 kubelet 进行交互，告知其容器创建的需求，协议：http/https；
kubelet 与 Docker 等容器引擎进行交互，创建容器，协议：http/unix socket.
至此我们的容器已然在集群节点上创建成功，创建的流程涉及 ETCD、apiserver、kubelet、dashboard、docker remote api 等组件，可见每个组件被控制会造成的风险和危害，以及相应的利用方向；
对于这些组件的安全性，除了不同组件不一样的鉴权设计以外，网络隔离也是非常必要的，常规的 iptables 设置和规划也可以在容器网络中起到作用（容器网络的很多能力也是基于 iptables 实现的）。
另外比较有容器特色的方案就是 Network Policy 的规划和服务网格的使用，能从容器、POD、服务的维度更加优雅的管理和治理容器网络以及集群内流量。这些组件的资料和对应渗透手法，这里我们一一介绍一下:
