6.4 Spark安全：认证、加密与访问控制

6.4 Spark安全：认证、加密与访问控制

本节摘要：Spark 安全由三道门组成——Kerberos 认证确认"你是谁"、SASL/TLS 加密保护传输中的数据、ACL 与敏感信息脱敏控制"能看什么"。本节按数据在集群里的旅程逐段布防，并给出最小可用的安全配置集。

前三节把引擎跑快跑稳，本节回答另一个问题：跑得快的同时，谁能碰它。安全配置的思路和排障一样要分层——认证层、传输层、控制层，每层护的东西不同，缺一层就是一个口子。

认证：先确认你是谁

# 与 Hadoop 生态共存的 Kerberos 认证：提交前获取票据
kinit user@BIGDATA.CORP

spark-submit --principal user@BIGDATA.CORP \
             --keytab user.keytab \
             --master yarn app.jar
​

Kerberos 的角色是让集群内每个组件互验身份：Driver 连 ResourceManager、Executor 反向注册、访问 HDFS，每次握手都凭票据说话。Standalone 模式则简单得多，共享密钥即可。

--conf spark.authenticate=true \
--conf spark.authenticate.secret=集群共享密钥
​

巡检视角的理解：第 1 章讲过 Executor 反向注册回 Driver——若注册通道无认证，任何一个能路由到 Driver 端口的进程都可能伪装成 Executor 领任务，而任务里装着你的代码与数据分片。认证护的是这条通道。

传输加密：数据在路上的保险

--conf spark.network.crypto.enabled=true \
--conf spark.ssl.enabled=true \
--conf spark.ssl.keyStore=/path/keystore.jks \
--conf spark.ssl.keyStorePassword=***
​

要分清三段路：Executor 之间的 Shuffle 数据（network.crypto 或 SSL）、Driver 与 Executor 的 RPC、对外的 UI（SSL）。默认全明文——Shuffle 中间结果在机房间穿梭，敏感字段等于裸奔。事件日志与动态分配用的外置 Shuffle 服务也各自有对应开关，漏配哪段哪段就是短板。

访问控制与脱敏：能看什么的闸门

# UI 鉴权与视图权限
--conf spark.acls.enable=true \
--conf spark.admin.acls=ops1,ops2 \
--conf spark.modify.acls.enable=true \
--conf spark.modify.acls=team-a

# 日志里的敏感配置自动打码
--conf spark.redaction.regex="(?i)secret|password|token"
​

三个高频控制点。其一 UI 权限：4040 端口默认同网段人人可看，作业详情里常有表名与数据样本，ACL 是第一道闸。其二配置脱敏：含 password、token 字样的配置项在 UI 与日志里自动变成 ********，redaction.regex 让规则可扩。其三数据权限：Spark 本身不管行级权限，列与行的边界要靠存储层（如 Ranger 管控的 Hive 表）执行，Spark 只是入口——把权限寄望于引擎是常见误解。

巡检案例：一次渗透测试暴露的三道口子

背景：安全团队对一套 YARN 上的 Spark 平台做授权测试。操作：分别尝试直连 Driver 端口、抓包 Shuffle 流量、匿名访问 UI。结果：三个都成功——注册通道无认证，Shuffle 明文可读，UI 无 ACL 且详情页暴露了一张含手机号的样本表。解读：三道门各漏一道，攻击路径就完整：伪装 Executor 领任务、或直接从 UI 摸清表结构再从 Shuffle 抓数据。变式：仅修 UI ACL 不够，测试员换走 Shuffle 抓包路径仍然得手，说明分层布防缺一不可。

⚠️ 常见坑：Kerberos 票据会过期，长跑的流作业要用 keytab 配置自动续期，否则半夜票据一过、作业整夜空转报错。另一个坑：开了 SSL 却忘了 UI 端口，等于前门上锁后门敞开。

💡 关键直觉：安全的检查粒度要和数据流向一致——数据从存储进来、经 Driver 编排、在 Executor 间 Shuffle、最后落到结果端，逐段问一句"这段谁都能碰吗"，比背配置清单有效。

一份最小可用的安全配置集

把本章收拢成一份可落地的基线，按"先认证、再加密、后控权"的顺序启用，每步验证再进下一步：

--conf spark.authenticate=true \
--conf spark.authenticate.secret=从密钥管理下发 \
--conf spark.network.crypto.enabled=true \
--conf spark.ssl.enabled=true \
--conf spark.acls.enable=true \
--conf spark.admin.acls=值班组 \
--conf spark.redaction.regex="(?i)secret|password|token|key"
​

启用顺序有讲究的原因：认证没开就上加密，等于给匿名访客的流量加了保护；ACL 没配就改脱敏正则，日志是干净了但任何人都还能看作业详情。逐层启用、逐层验证，每层的验证手段也不同——认证看握手日志、加密靠抓包确认、ACL 用两个账号对拍权限。这份基线不能覆盖所有场景，但它能把最低级的三个口子全部关死。

本节要点回顾

• 三道门各护一段：认证管身份、加密管传输、ACL 与脱敏管可见性
• Executor 注册通道必须认证：无认证的 Driver 端口是伪装执行器的入口
• 三段传输分开配：Shuffle、RPC、UI 各有开关，漏一段短一段
• 权限的根在存储层：Spark 是查询入口，行级权限不归引擎管
• 长跑作业续票据：keytab 自动续期是流作业保命的细节

到这里，单集群的看护闭环完成。第 7 章把镜头拉远：Spark 与 Hadoop、NoSQL、消息队列如何互相供数，以及 Spark Connect 如何重新切分客户端与集群的边界。