Kubernetes 中 HostPath 的风险和防范

Kubernetes 的安全问题，被提及比较多的一般包括几个点：

• Docker & Kubernetes 参数加固
• RBAC
• Root 镜像
• 特权容器

众所周知，很多安全问题是爆发在内部的，因此有了零信任的说法。内网能够比较容易地接触在成功接触集群之后，仅仅通过对 HostPath 的使用，就有机会对集群和运行其上的工作负载进行窥探，甚至进行写入操作。

下面会分为三个部分，分别介绍可能接触集群的方法，入侵危害、以及建议的防范手段。

接触集群

要入侵一个集群，通常需要用某种方式和集群进行接触，通常方式有几种：

意外暴露无鉴权的明文端口

部分集群管理员为了方便访问，或者其他历史遗留原因，选择使用无鉴权的 API Server，或者暴露 Kubelet 的只读端口。

意外暴露 Dashboard 类服务

很多同学偏爱图形化的 Dashboard 服务，这类服务通常需要有较高的授权级别，可以运行较多的管理任务。

安装恶意应用

现在很多软件使用 curl | kubectl -f - 的形式进行快速安装，对于有外网访问能力的 Kubernetes 集群来说，不加验证的运行未知应用，随时处于引狼入室的威胁之中。

Kubeadm 安装后会缺省提供一个 admin.conf 文件，其中包含了集群管理员身份的客户端证书，能够完全控制集群。

公有云账号

GKE、AKS 等集群环境，其 Kubernetes 账号是来自公有云的，因此公有云对容器集群具有全权处置的能力，其中也包含生成集群管理员的能力。

建议严格管理公有云相关账号，根据使用责任对不同系统进行分离。

入侵危害

敏感文件

Pod 中加载了敏感文件之后，可能通过 cp 获取这些文件，甚至还可以尝试使用 exec 进行写入工作。随便举几个例子：

• /etc
• /root
• /var/lib

这些位置的文件包含了身份证书、信任链、各种配置文件，被读取，破坏、甚至被篡改会发生什么呢？

服务发现

以 Pod 为基础，能够访问集群内的各种服务，进一步扩散影响范围。

防范

1. 使用 PSP 或者 OPA/Kyverno 等策略工具，限制 hostPath 的加载，必须加载的，也应该控制在指定目录。
2. 控制镜像来源，杜绝不明来源的镜像进入集群。
3. 启用审计策略。
4. /etc/kubernetes/*、~/.kube 设置权限为 600。
5. 管理员身份的 kubeconfig 文件应该单独存放。 如有可能，应该使用 OIDC 等第三方进行登录。
6. 使用 RBAC 为特定职责的用户开放最小权限，严格控制 exec attach portforward 等权限。
7. Kubelet、APIServer 的明文端口必须关闭。
8. 使用网络策略，防止未经明确放行的服务访问。