各个组件未鉴权所能造成的风险,其实从它们在 Kubernetes 集群环境里所能起到的作用就能很明显的判断出来,如 APIServer 是所有功能的主入口,则控制 APIServer 基本上等同控制集群的所有功能;而 kubelet 是单个节点用于进行容器编排的 Agent,所以控制 kubelet 主要是对单个节点下的容器资源进行控制。

组件分工上较为完整的图例可参考:

图片

想必这样也相对晦涩难懂,我简化了一下,假如用户想在集群里面新建一个容器集合单元,那各个组件以此会相继做什么事情呢?

  1. 用户与 kubectl 或者 Kubernetes Dashboard 进行交互,提交需求。(例: kubectl create -f pod.yaml);

  2. kubectl 会读取 ~/.kube/config 配置,并与 apiserver 进行交互,协议:http/https;

  3. apiserver 会协同 ETCD 等组件准备下发新建容器的配置给到节点,协议:http/https(除 ETCD 外还有例如 kube-controller-manager, scheduler 等组件用于规划容器资源和容器编排方向,此处简化省略);

  4. apiserver 与 kubelet 进行交互,告知其容器创建的需求,协议:http/https;

  5. kubelet 与 Docker 等容器引擎进行交互,创建容器,协议:http/unix socket.

至此我们的容器已然在集群节点上创建成功,创建的流程涉及 ETCD、apiserver、kubelet、dashboard、docker remote api 等组件,可见每个组件被控制会造成的风险和危害,以及相应的利用方向;

对于这些组件的安全性,除了不同组件不一样的鉴权设计以外,网络隔离也是非常必要的,常规的 iptables 设置和规划也可以在容器网络中起到作用(容器网络的很多能力也是基于 iptables 实现的)。

另外比较有容器特色的方案就是 Network Policy 的规划和服务网格的使用,能从容器、POD、服务的维度更加优雅的管理和治理容器网络以及集群内流量。这些组件的资料和对应渗透手法,这里我们一一介绍一下:

最后编辑: kuteng  文档更新时间: 2022-06-01 16:21   作者:kuteng