别再裸奔了Kubernetes 数据平台访问控制的“防猥琐指南”大家好我是Echo_Wish。说句实话这几年我见过太多“看起来很高级”的数据平台——Kubernetes 上跑着 Spark、Flink、ClickHouse搞得云原生味儿十足。但你稍微扒一扒权限设计基本是这样的 所有人共用一个 kubeconfig 数据库 root 账号写在 YAML 里 RBAC不存在的直接 cluster-admin 起飞说难听点这不是云原生这是云上裸奔。今天咱就聊点实在的——Kubernetes 数据平台访问控制到底该怎么落地一、先把问题说透你到底在保护什么很多人一上来就搞 RBAC、搞 IAM其实根本没想清楚一件事你保护的不是 Kubernetes而是“数据 操作能力”拆开来看有三层集群层K8s API计算层Spark / Flink / Airflow数据层Hive / Iceberg / ClickHouse / MySQL绝大多数安全事故都是因为 权限“横向打通”而不是单点突破比如一个开发者有 pod 创建权限然后他挂载了生产数据库密钥再直接 dump 数据完事。二、第一道防线Kubernetes RBAC 不只是“会写 YAML”很多人觉得 RBAC 就是写几个 RoleBinding。但关键点在这RBAC 的核心是“最小权限 边界隔离”我们先来一个典型错误示范apiVersion:rbac.authorization.k8s.io/v1kind:ClusterRoleBindingmetadata:name:dev-adminsubjects:-kind:Username:dev-userroleRef:kind:ClusterRolename:cluster-adminapiGroup:rbac.authorization.k8s.io这玩意儿的意思就是 “来吧兄弟整个集群都是你的”正确做法命名空间级隔离apiVersion:rbac.authorization.k8s.io/v1kind:Rolemetadata:namespace:devname:dev-readerrules:-apiGroups:[]resources:[pods]verbs:[get,list]再绑定apiVersion:rbac.authorization.k8s.io/v1kind:RoleBindingmetadata:name:dev-reader-bindingnamespace:devsubjects:-kind:Username:dev-userroleRef:kind:Rolename:dev-readerapiGroup:rbac.authorization.k8s.io 核心思想不给跨 namespace 权限不给写权限默认只读不给 secret 访问三、第二道防线ServiceAccount 才是真正的“幕后黑手”很多人忽略一个点真正操作数据的不是人是 Pod而 Pod 用的是 ServiceAccount如果你不管它就会出现spec:serviceAccountName:default默认账号 默认权限 灾难套餐正确姿势为不同任务绑定独立身份apiVersion:v1kind:ServiceAccountmetadata:name:spark-job-sanamespace:data再绑定权限kind:RoleapiVersion:rbac.authorization.k8s.io/v1metadata:namespace:dataname:spark-job-rolerules:-apiGroups:[]resources:[pods]verbs:[create,get] 核心点每种任务一个 SA不共享不滥用 default四、第三道防线别把数据库密码写进 YAML真的别我见过最离谱的一个配置env:-name:DB_PASSWORDvalue:root123兄弟这不叫配置这叫自爆程序。正确做法使用 Secret 外部密钥管理apiVersion:v1kind:Secretmetadata:name:db-secrettype:Opaquedata:password:cm9vdDEyMw# base64Pod 引用env:-name:DB_PASSWORDvalueFrom:secretKeyRef:name:db-secretkey:password更进一步接入 Vault推荐annotations:vault.hashicorp.com/agent-inject:truevault.hashicorp.com/role:data-platform 好处密钥动态生成自动过期不落地五、第四道防线数据平台的“最后一公里权限”很多人以为 Kubernetes 控制住了就完事了。其实 数据权限才是最终裁判比如 HiveGRANTSELECTONTABLEsales_dataTOUSERdev_user;REVOKEINSERTONTABLEsales_dataFROMUSERdev_user;比如 ClickHouseCREATEUSERdev_user IDENTIFIEDBYpassword;GRANTSELECTONdb.*TOdev_user; 原则K8s 控“谁能跑任务”数据系统控“任务能看啥”这俩必须“双保险”。六、一个真实事故复盘血的教训某公司数据平台Kubernetes RBAC 做了 ✔Namespace 隔离 ✔Secret 也用了 ✔但他们犯了一个致命错误 所有 Spark Job 用同一个 ServiceAccount结果A 业务有权限读用户数据B 业务没有但 B 的 Job 直接复用了 A 的 SA 数据直接泄露七、我的一套“接地气安全原则”说一堆技术不如总结几条人话1️⃣ 权限一定要“碎片化”不要搞“一个账号走天下”。2️⃣ 永远不要相信 defaultdefault namespace、default SA都是坑。3️⃣ 数据权限 Kubernetes 权限别搞反了重点。4️⃣ 能不用长期密钥就别用动态密钥才是未来。5️⃣ 安全不是功能是“约束设计”不是加一个组件就解决的。八、最后说点真心话很多人觉得安全是“成本”不是“价值”。但我这几年看下来 真正毁掉系统的不是性能瓶颈而是权限失控你可以慢一点但不能“全员 root”。云原生这套东西本质上给了你更细粒度的控制能力但如果你不用那它只会让你的风险指数级放大。如果你现在在做数据平台我给你一句建议 先把权限模型设计好再写第一行代码否则你后面补安全就像在高速公路上换轮胎。——能换但很容易翻车。
别再裸奔了：Kubernetes + 数据平台访问控制的“防猥琐指南”
别再裸奔了Kubernetes 数据平台访问控制的“防猥琐指南”大家好我是Echo_Wish。说句实话这几年我见过太多“看起来很高级”的数据平台——Kubernetes 上跑着 Spark、Flink、ClickHouse搞得云原生味儿十足。但你稍微扒一扒权限设计基本是这样的 所有人共用一个 kubeconfig 数据库 root 账号写在 YAML 里 RBAC不存在的直接 cluster-admin 起飞说难听点这不是云原生这是云上裸奔。今天咱就聊点实在的——Kubernetes 数据平台访问控制到底该怎么落地一、先把问题说透你到底在保护什么很多人一上来就搞 RBAC、搞 IAM其实根本没想清楚一件事你保护的不是 Kubernetes而是“数据 操作能力”拆开来看有三层集群层K8s API计算层Spark / Flink / Airflow数据层Hive / Iceberg / ClickHouse / MySQL绝大多数安全事故都是因为 权限“横向打通”而不是单点突破比如一个开发者有 pod 创建权限然后他挂载了生产数据库密钥再直接 dump 数据完事。二、第一道防线Kubernetes RBAC 不只是“会写 YAML”很多人觉得 RBAC 就是写几个 RoleBinding。但关键点在这RBAC 的核心是“最小权限 边界隔离”我们先来一个典型错误示范apiVersion:rbac.authorization.k8s.io/v1kind:ClusterRoleBindingmetadata:name:dev-adminsubjects:-kind:Username:dev-userroleRef:kind:ClusterRolename:cluster-adminapiGroup:rbac.authorization.k8s.io这玩意儿的意思就是 “来吧兄弟整个集群都是你的”正确做法命名空间级隔离apiVersion:rbac.authorization.k8s.io/v1kind:Rolemetadata:namespace:devname:dev-readerrules:-apiGroups:[]resources:[pods]verbs:[get,list]再绑定apiVersion:rbac.authorization.k8s.io/v1kind:RoleBindingmetadata:name:dev-reader-bindingnamespace:devsubjects:-kind:Username:dev-userroleRef:kind:Rolename:dev-readerapiGroup:rbac.authorization.k8s.io 核心思想不给跨 namespace 权限不给写权限默认只读不给 secret 访问三、第二道防线ServiceAccount 才是真正的“幕后黑手”很多人忽略一个点真正操作数据的不是人是 Pod而 Pod 用的是 ServiceAccount如果你不管它就会出现spec:serviceAccountName:default默认账号 默认权限 灾难套餐正确姿势为不同任务绑定独立身份apiVersion:v1kind:ServiceAccountmetadata:name:spark-job-sanamespace:data再绑定权限kind:RoleapiVersion:rbac.authorization.k8s.io/v1metadata:namespace:dataname:spark-job-rolerules:-apiGroups:[]resources:[pods]verbs:[create,get] 核心点每种任务一个 SA不共享不滥用 default四、第三道防线别把数据库密码写进 YAML真的别我见过最离谱的一个配置env:-name:DB_PASSWORDvalue:root123兄弟这不叫配置这叫自爆程序。正确做法使用 Secret 外部密钥管理apiVersion:v1kind:Secretmetadata:name:db-secrettype:Opaquedata:password:cm9vdDEyMw# base64Pod 引用env:-name:DB_PASSWORDvalueFrom:secretKeyRef:name:db-secretkey:password更进一步接入 Vault推荐annotations:vault.hashicorp.com/agent-inject:truevault.hashicorp.com/role:data-platform 好处密钥动态生成自动过期不落地五、第四道防线数据平台的“最后一公里权限”很多人以为 Kubernetes 控制住了就完事了。其实 数据权限才是最终裁判比如 HiveGRANTSELECTONTABLEsales_dataTOUSERdev_user;REVOKEINSERTONTABLEsales_dataFROMUSERdev_user;比如 ClickHouseCREATEUSERdev_user IDENTIFIEDBYpassword;GRANTSELECTONdb.*TOdev_user; 原则K8s 控“谁能跑任务”数据系统控“任务能看啥”这俩必须“双保险”。六、一个真实事故复盘血的教训某公司数据平台Kubernetes RBAC 做了 ✔Namespace 隔离 ✔Secret 也用了 ✔但他们犯了一个致命错误 所有 Spark Job 用同一个 ServiceAccount结果A 业务有权限读用户数据B 业务没有但 B 的 Job 直接复用了 A 的 SA 数据直接泄露七、我的一套“接地气安全原则”说一堆技术不如总结几条人话1️⃣ 权限一定要“碎片化”不要搞“一个账号走天下”。2️⃣ 永远不要相信 defaultdefault namespace、default SA都是坑。3️⃣ 数据权限 Kubernetes 权限别搞反了重点。4️⃣ 能不用长期密钥就别用动态密钥才是未来。5️⃣ 安全不是功能是“约束设计”不是加一个组件就解决的。八、最后说点真心话很多人觉得安全是“成本”不是“价值”。但我这几年看下来 真正毁掉系统的不是性能瓶颈而是权限失控你可以慢一点但不能“全员 root”。云原生这套东西本质上给了你更细粒度的控制能力但如果你不用那它只会让你的风险指数级放大。如果你现在在做数据平台我给你一句建议 先把权限模型设计好再写第一行代码否则你后面补安全就像在高速公路上换轮胎。——能换但很容易翻车。
