4、Kubernetes集群攻击面：API Server暴露、etcd未授权访问、kubelet漏洞、RBAC配置错误

聊到5G核心网的云原生环境，Kubernetes集群本身就是一个巨大的攻击面。我经常跟团队说，K8s不是银弹，它是一把双刃剑。你用得好，它是自动化编排的神器；用得不好，它就是黑客的后花园。

今天咱们就聚焦四个最要命的攻击点：API Server暴露、etcd未授权访问、kubelet漏洞、RBAC配置错误。这几个点，我在实际项目中几乎都踩过坑，有的甚至差点酿成大祸。

4.1 API Server暴露——集群的"大门"没锁

API Server是K8s的大脑，所有操作都得经过它。说白了，谁控制了API Server，谁就控制了整个集群。

我记得有一次做渗透测试，客户说他们的集群很安全。结果我扫了一下公网IP，发现6443端口直接暴露在互联网上，连认证都没开。我当时就愣住了——这相当于把银行金库的大门敞开着，还在门口贴了张纸条"欢迎光临"。

攻击者拿到API Server的访问权限后，能干的事太多了：

• 创建恶意Pod：直接跑一个挖矿容器，或者挂载宿主机的根目录
• 窃取Secrets：5G核心网的NF配置、证书、密钥全在Secrets里
• 横向移动：通过Service Account token跳到其他命名空间

4.2 etcd未授权访问——数据在"裸奔"

etcd是K8s的"数据库"，所有集群状态都存里面。包括Pod定义、ConfigMap、Secrets，甚至整个集群的证书。

我曾经在项目中遇到过一件事：一个运维同事为了方便，把etcd的2379端口直接暴露在内部网络，而且没开认证。他说"内网很安全"。结果呢？一个被攻陷的跳板机直接扫到了etcd，整个集群的Secrets被拖走。嗯，那天的复盘会开得特别长。

# 攻击者直接通过etcdctl读取所有数据
etcdctl --endpoints=http://target:2379 get / --prefix --keys-only

# 或者直接获取所有Secrets
etcdctl --endpoints=http://target:2379 get /registry/secrets --prefix

为什么etcd这么危险？因为K8s把所有的敏感信息都明文或base64编码存在etcd里。你想想看，SMF的N4接口密钥、AMF的N2接口证书、UDM的鉴权向量...全都在里面。

4.3 kubelet漏洞——从节点突破到集群

kubelet是每个Node上的"代理"，负责管理Pod的生命周期。它暴露了两个端口：10250（认证端口）和10255（只读端口）。

我记得有一次做红蓝对抗，蓝队把API Server守得死死的。结果我从一个Node的kubelet入手，发现10255端口开着，而且没做IP限制。我直接调了kubelet的API，拿到了所有Pod的列表和状态。更可怕的是，我还能通过kubelet执行命令——虽然需要认证，但有些版本的kubelet存在认证绕过漏洞。

4.4 RBAC配置错误——权限的"潘多拉魔盒"

RBAC是K8s的权限控制机制，但配置起来特别容易出错。我见过太多"为了方便"而过度授权的案例。

举个例子：有个团队给一个CI/CD的Service Account绑定了cluster-admin角色。理由是"省得每次加权限麻烦"。结果这个CI/CD的token泄露了，攻击者直接拿到了集群的超级管理员权限。你说冤不冤？

为什么会这样？说白了，很多人对RBAC的理解停留在"能用就行"。但你要知道，在5G核心网环境里，一个错误的RBAC配置可能导致整个网络切片被攻陷。

# 最小权限原则示例：只允许读取特定命名空间的Pod
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: nf-smf
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: nf-smf
  name: read-pods
subjects:
- kind: ServiceAccount
  name: smf-monitor
  namespace: monitoring
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

好了，这四个攻击面讲完了。你想想看，API Server是入口，etcd是数据仓库，kubelet是节点代理，RBAC是权限管控。任何一个环节出问题，整个集群都可能沦陷。我在项目中见过太多"我以为没问题"的案例，结果都是血的教训。

记住一句话：在5G核心网的云原生环境里，安全不是功能，是底线。