Kubernetes安全审计六大核心攻击面解析，从Pod到etcd的实战风险路径

在云原生架构快速普及的背景下，Kubernetes 已成为主流容器编排平台，但其复杂性也带来了显著的安全挑战。尽管企业普遍部署了网络策略、RBAC 和镜像扫描等防护措施，大量集群仍因配置疏漏或权限误设而暴露于可被利用的攻击路径中。安全团队若仅依赖外围防御，忽视对集群内部组件交互逻辑的深度审计，往往难以识别真正高危的攻击链。

上图展示了典型的 Kubernetes 攻击面传导路径：攻击者通常从低权限入口（如存在漏洞的 Pod）切入，逐步提权至 ServiceAccount，进而操控 API Server，最终触及 etcd 存储层——这一过程在多个真实事件中已被复现。

一、Pod 层：配置不当引发的初始突破口

Pod 是 Kubernetes 中最小调度单元，也是攻击者最常利用的起点。常见风险包括：以 root 用户运行容器、挂载宿主机敏感目录（如 /proc、/sys）、启用特权模式（privileged: true），以及未限制能力集（capabilities）。例如，某电商企业曾因一个测试 Pod 启用了 --privileged 参数并挂载了宿主机 /var/run/docker.sock，导致攻击者通过该容器直接控制整个节点上的 Docker 守护进程，继而横向渗透至其他命名空间。

此外，环境变量中硬编码密钥、Secret 挂载为明文文件、以及使用默认 service account 而未显式绑定最小权限角色，均构成“低垂果实”式风险。这些配置问题在 CI/CD 流水线中若缺乏自动化检查，极易随镜像发布进入生产环境。

二、ServiceAccount 与 RBAC：权限泛化导致的横向移动

Kubernetes 默认为每个命名空间创建 default ServiceAccount，若未显式配置 RoleBinding 或 ClusterRoleBinding，该账户将继承 cluster-admin 权限（在某些旧版集群中尤为常见）。更隐蔽的问题是“过度授权”：开发人员为方便调试，常赋予 SA 对 deployments、secrets 甚至 nodes 的 full access，一旦该 SA 的 token 被窃取（例如通过日志泄露、侧信道攻击或恶意 Pod 读取 /var/run/secrets/kubernetes.io/serviceaccount/token），攻击者即可在集群内自由操作。

2022 年披露的 CVE-2022-2880（Kubelet 未授权访问漏洞）即利用了此类权限链：攻击者先通过弱凭证获取 Kubelet API 访问权，再读取任意 Pod 的 SA token，最终实现集群级接管。这凸显了 SA token 管理与 RBAC 策略精细化的必要性。

三、API Server：面向外部的“唯一入口”风险

API Server 是集群的中枢神经，所有控制指令均经由此处处理。其安全配置直接影响整体防线强度。典型隐患包括：

未启用 TLS 双向认证（mutual TLS），允许未经验证的客户端连接；
错误地将 --insecure-port=8080 开放至公网（尽管官方已弃用该参数，部分遗留集群仍在使用）；
使用静态 bearer token 或长期有效的 client certificate，缺乏轮换机制；
未限制 admission control 插件，导致恶意 YAML 可绕过校验直接创建资源。

2021 年某金融云平台曾因 API Server 的 insecure port 暴露，被扫描器发现后触发批量 Pod 注入攻击，造成数十个租户环境数据外泄。该事件促使 CNCF 在后续版本中强化了默认安全基线。

四、etcd：集群状态数据库的终极防线

etcd 存储着集群的所有元数据：Pod 定义、Secret 内容、网络策略、证书信息等。一旦 etcd 被突破，整个集群即彻底失守。攻击途径主要有两类：一是通过 API Server 提权后调用 etcd 备份接口（如 /apis/storage.k8s.io/v1/etcdbackups）；二是直接攻击 etcd 节点本身，例如利用未打补丁的 etcd 版本漏洞（如 CVE-2020-15114，影响 v3.4.9 及之前版本），或通过 SSH 弱密码登录 etcd 主机。

值得注意的是，许多企业将 etcd 部署在与 master 节点同一物理机上，且未启用加密传输（--cipher-suite 未配置），使得网络嗅探即可截获明文数据。2020 年 Shopify 曾公开其 etcd 安全加固实践：启用 TLS 1.3 加密通信、定期轮换 client cert、限制 etcd peer IP 白名单，并将数据盘设置为全盘加密。

五、网络策略缺失：微隔离失效下的自由漫游

Kubernetes 原生支持 NetworkPolicy，但默认不启用。大量集群仍处于“扁平网络”状态，Pod 间可任意通信。攻击者一旦侵入任一 Pod，即可无阻碍扫描并攻击数据库、中间件或其他业务服务。

例如，某 SaaS 公司的前端 Pod 被 XSS 攻击植入 WebShell 后，因未配置 NetworkPolicy，攻击者迅速横向移动至后端订单服务，读取用户支付令牌。事后审计发现，其集群中 90% 的命名空间未定义任何网络策略规则。

正确做法是按“默认拒绝”原则设计策略：首先禁止所有入站/出站流量，再按业务需求逐条开放。同时需注意 Calico、Cilium 等 CNI 插件对 NetworkPolicy 的实现差异，避免策略未生效的“假防护”。

六、Dashboard 与第三方组件：被忽视的管理界面

Kubernetes Dashboard 作为可视化管理工具，常被配置为 ClusterAdmin 权限且暴露于内网。若未启用认证或使用弱密码（如 admin/admin），将成为高危入口。2019 年多起事件显示，攻击者通过扫描 9090 端口发现未授权 Dashboard，直接创建恶意 DaemonSet 实现持久化。

此外，Prometheus、Grafana、Argo CD 等周边组件若未做访问控制，同样构成风险延伸点。例如 Argo CD 默认启用本地认证，若管理员未修改 admin 密码或未绑定 OIDC，外部攻击者可通过暴力破解获取 GitOps 控制权。

上述六大攻击面并非孤立存在，而是层层递进、相互耦合。一次成功的入侵往往始于 Pod 配置疏漏，经由 SA 权限提升，借力 API Server 接口，最终落脚于 etcd 数据窃取。安全团队需建立“纵深防御+持续审计”机制：在部署阶段嵌入 Policy-as-Code（如 OPA/Gatekeeper），运行时监控异常行为（如非预期的 Secret 访问），并定期执行红蓝对抗演练，模拟真实攻击路径。

随着 Kubernetes 发布节奏加快（平均每季度一次大版本更新），新特性引入的同时也可能带来新风险点。例如 Kubernetes 1.24 移除 Dockershim 后，部分用户转向 containerd 但未同步更新安全配置；1.26 引入的 Pod Security Admission 虽替代了已弃用的 PSP，但默认策略宽松，需手动启用严格模式。这意味着安全治理必须与版本演进同步迭代，而非一次性工程。

当前，CNCF 正推动 SBOM（软件物料清单）与 SLSA（Supply Chain Levels for Software Artifacts）标准在 K8s 生态落地，未来集群安全将更侧重于供应链可信度与自动化合规验证。但在那之前，对这六大核心攻击面的清醒认知与实操级防护，仍是保障生产集群稳定运行的基石。