别再裸奔了：Kubernetes + 数据平台访问控制的“防猥琐指南”

大家好，我是Echo_Wish。

说句实话，这几年我见过太多“看起来很高级”的数据平台——
Kubernetes 上跑着 Spark、Flink、ClickHouse，搞得云原生味儿十足。

但你稍微扒一扒权限设计，基本是这样的：

👉 所有人共用一个 kubeconfig
👉 数据库 root 账号写在 YAML 里
👉 RBAC？不存在的，直接 cluster-admin 起飞

说难听点：这不是云原生，这是云上裸奔。

今天咱就聊点实在的——
Kubernetes + 数据平台，访问控制到底该怎么落地？

一、先把问题说透：你到底在保护什么？

很多人一上来就搞 RBAC、搞 IAM，其实根本没想清楚一件事：

👉 你保护的不是 Kubernetes，而是“数据 + 操作能力”

拆开来看有三层：

1. 集群层（K8s API）
2. 计算层（Spark / Flink / Airflow）
3. 数据层（Hive / Iceberg / ClickHouse / MySQL）

绝大多数安全事故，都是因为：

👉 权限“横向打通”，而不是单点突破

比如：

• 一个开发者有 pod 创建权限
• 然后他挂载了生产数据库密钥
• 再直接 dump 数据

完事。

二、第一道防线：Kubernetes RBAC 不只是“会写 YAML”

很多人觉得 RBAC 就是写几个 RoleBinding。

但关键点在这：

👉 RBAC 的核心是“最小权限 + 边界隔离”

我们先来一个典型错误示范：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: dev-admin
subjects:
- kind: User
  name: dev-user
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

这玩意儿的意思就是：

👉 “来吧兄弟，整个集群都是你的”

正确做法：命名空间级隔离

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: dev-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]

再绑定：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-reader-binding
  namespace: dev
subjects:
- kind: User
  name: dev-user
roleRef:
  kind: Role
  name: dev-reader
  apiGroup: rbac.authorization.k8s.io

👉 核心思想：

• 不给跨 namespace 权限
• 不给写权限，默认只读
• 不给 secret 访问

三、第二道防线：ServiceAccount 才是真正的“幕后黑手”

很多人忽略一个点：

👉 真正操作数据的，不是人，是 Pod

而 Pod 用的是：

👉 ServiceAccount

如果你不管它，就会出现：

spec:
  serviceAccountName: default

默认账号 + 默认权限 = 灾难套餐

正确姿势：为不同任务绑定独立身份

apiVersion: v1
kind: ServiceAccount
metadata:
  name: spark-job-sa
  namespace: data

再绑定权限：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: data
  name: spark-job-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["create", "get"]

👉 核心点：

• 每种任务一个 SA
• 不共享
• 不滥用 default

四、第三道防线：别把数据库密码写进 YAML（真的别）

我见过最离谱的一个配置：

env:
- name: DB_PASSWORD
  value: root123

兄弟，这不叫配置，这叫自爆程序。

正确做法：使用 Secret + 外部密钥管理

apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
data:
  password: cm9vdDEyMw==  # base64

Pod 引用：

env:
- name: DB_PASSWORD
  valueFrom:
    secretKeyRef:
      name: db-secret
      key: password

更进一步：接入 Vault（推荐）

annotations:
  vault.hashicorp.com/agent-inject: "true"
  vault.hashicorp.com/role: "data-platform"

👉 好处：

• 密钥动态生成
• 自动过期
• 不落地

五、第四道防线：数据平台的“最后一公里权限”

很多人以为 Kubernetes 控制住了就完事了。

其实：

👉 数据权限，才是最终裁判

比如 Hive：

GRANT SELECT ON TABLE sales_data TO USER dev_user;
REVOKE INSERT ON TABLE sales_data FROM USER dev_user;

比如 ClickHouse：

CREATE USER dev_user IDENTIFIED BY 'password';
GRANT SELECT ON db.* TO dev_user;

👉 原则：

• K8s 控“谁能跑任务”
• 数据系统控“任务能看啥”

这俩必须“双保险”。

六、一个真实事故复盘（血的教训）

某公司数据平台：

• Kubernetes RBAC 做了 ✔
• Namespace 隔离 ✔
• Secret 也用了 ✔

但他们犯了一个致命错误：

👉 所有 Spark Job 用同一个 ServiceAccount

结果：

• A 业务有权限读用户数据
• B 业务没有

但 B 的 Job 直接复用了 A 的 SA

👉 数据直接泄露

七、我的一套“接地气安全原则”

说一堆技术不如总结几条人话：

1️⃣ 权限一定要“碎片化”

不要搞“一个账号走天下”。

2️⃣ 永远不要相信 default

default namespace、default SA，都是坑。

3️⃣ 数据权限 > Kubernetes 权限

别搞反了重点。

4️⃣ 能不用长期密钥，就别用

动态密钥才是未来。

5️⃣ 安全不是功能，是“约束设计”

不是加一个组件就解决的。

八、最后说点真心话

很多人觉得安全是“成本”，不是“价值”。

但我这几年看下来：

👉 真正毁掉系统的，不是性能瓶颈，而是权限失控

你可以慢一点，但不能“全员 root”。

云原生这套东西，本质上给了你更细粒度的控制能力，
但如果你不用，那它只会让你的风险指数级放大。

如果你现在在做数据平台，我给你一句建议：

👉 先把权限模型设计好，再写第一行代码

否则你后面补安全，就像在高速公路上换轮胎。

——能换，但很容易翻车。