Ranger 与 Kerberos：大数据平台权限体系搭建

大数据平台安全体系里最容易被混淆的一句话是"Kerberos 和 Ranger 都是做权限的"。实际上两者的分工非常清晰：Kerberos 负责认证（authentication），回答"你是谁"；Ranger 负责授权（authorization），回答"你能干什么"。认证与授权分离是 Hadoop 安全模型的两层结构，理解这条边界，才能解释为什么很多集群"开了 Kerberos 还是漏数据"，也能解释为什么"装了 Ranger 但策略不生效"。本文按这两层展开：先讲认证层 Kerberos 的组成与配置要点，再讲授权层 Ranger 的插件联邦授权模型与集中审计，最后给出完整的搭建步骤与常见失败模式。

第一层认证：Kerberos 解决"你是谁"。Kerberos 是一个基于票据（ticket）的认证协议，核心组件是 KDC（Key Distribution Center），它持有所有主体的密钥，负责签发票据。与大数据平台相关的主体概念有三个。principal 是身份标识，格式类似 user/host@REALM，例如 hdfs/node01.example.com@EXAMPLE.COM，一个服务或一个用户对应一个 principal。keytab 是 principal 密钥的文件形式，服务进程用它代替人工输入密码完成认证，keytab 的保管是安全边界：泄漏 keytab 等于泄漏身份。ticket 是认证通过后拿到的票据，TGT（Ticket Granting Ticket）是会话开始的凭证，ST（Service Ticket）是访问具体服务时使用的票据。各组件（HDFS、YARN、Hive 等）启用 Kerberos 后，进程之间通过 ticket 互相验证身份，未认证的客户端无法访问服务。配置要点包括：KDC 与所有节点时间同步（默认允许的时钟偏差只有几分钟，JuiceFS 的 Kerberos 文档也提醒过时间漂移导致的认证失败）、为每个服务创建 principal 并生成 keytab、把 keytab 分发到对应节点且权限收紧为仅属主可读。注意 Kerberos 只证明"你是这个 principal"，它完全不回答"这个 principal 能不能读这张表"——后者是第二层的事。

第二层授权：Ranger 解决"你能干什么"。Apache Ranger 的模型围绕三个概念构建。policy 是授权策略，表达"谁（用户/组）对什么资源（库、表、列、路径）有什么权限（读、写、执行）"；plugin 是嵌入各组件进程的授权拦截器，在请求到达组件时按策略实时裁决；repository（在 Ranger 里也称作 service）是组件与 Ranger 的对接单元，每个组件对应一个 repository，例如 HDFS 一个、Hive 一个。Ranger Admin 是集中管理端，所有策略在这里编辑，插件周期性从 Admin 拉取策略并缓存在本地，本地裁决保证性能，即使 Admin 短暂不可用，已缓存策略仍能继续生效（Ranger 官方文档对这一机制有详细描述）。

插件联邦授权模型是 Ranger 架构的核心，值得单独讲透。所谓"联邦"，是指授权能力不是集中在一个网关，而是以插件形式分布在每个组件的进程里：HDFS 的 NameNode 里有 HDFS 插件，HiveServer2 里有 Hive 插件，HBase、Kafka、YARN 等各有各的插件。所有插件从同一个 Ranger Admin 拉取策略，于是"一处配置策略、全组件生效"，这就是联邦的含义：策略中心化，执行分布化。例如在 Ranger 里给用户 alice 配了 HDFS 路径 /data/orders 的读权限，NameNode 插件和 Hive 插件都会拿到这条策略，alice 无论直接读文件还是通过 Hive SQL 访问，裁决结果一致。Cloudera 的Ranger HDFS 授权最佳实践强调，这种模型最大的优势是策略变更在下一个刷新周期对新请求生效，且不引入额外的网络转发开销；代价是每个组件都要安装并维护插件，组件升级时插件版本要跟随验证。

集中审计是授权层的第二块拼图。Ranger 插件在执行裁决时会把访问事件（谁、何时、访问了什么、允许还是拒绝）写入审计日志，插件把日志推送到 Ranger Admin 侧的统一审计存储（通常基于 Solr 或数据库），管理员在 Ranger 界面里按用户、资源、时间范围检索审计记录。集中审计的价值在于：安全团队不需要到每个组件的日志文件里翻，就能回答"上个月谁访问过这张敏感表""某个拒绝事件是否有人反复尝试"。要保证审计不丢，需要关注审计日志的队列缓冲与异步写入配置，避免审计通道阻塞影响正常访问。AWS 的 EMR Ranger 集成文档也把审计汇聚列为生产部署的必备项。

搭建步骤按顺序推进。第一步启用 Kerberos：部署 KDC，规划 realm 与 principal 命名，为每个组件创建 principal 并分发 keytab，在集群各组件配置中开启安全认证开关，用 kinit 手工验证服务 ticket 能正常签发。第二步验证认证层：用未认证客户端访问应被拒绝，用正确 principal 应能访问，这一步通过后再进入授权层，避免两层问题混在一起排查。第三步安装 Ranger Admin：准备后端数据库，部署 Admin 服务并完成初始化。第四步为各组件安装插件：每接入一个组件，在 Ranger Admin 创建对应 repository，把插件安装到组件节点并重启组件（或热加载），确认插件状态显示已连接、策略能正常拉取。第五步创建策略：从最小权限开始，先建几个测试策略验证插件裁决是否符合预期，允许、拒绝、审计三类行为都要验证。第六步开启集中审计：确认审计事件能写入统一存储，并配置审计保留周期。

常见失败模式集中在四个地方。一是时间同步：Kerberos 对时钟偏差极度敏感，节点时间漂移超过阈值会导致票据校验失败，表现为偶发认证报错，排查时先看 NTP 状态。二是 principal 配置错误：principal 中的主机名大小写、_HOST 占位符替换、realm 大小写不一致，是配置阶段最高频的错误，建议在配置文件中统一用小写并显式校验。三是插件策略缓存：插件按轮询间隔刷新策略，刚改的策略在下一个刷新周期前不生效，属正常现象；若长时间不生效，检查插件与 Admin 的连接状态与日志。四是策略叠加歧义：Ranger 策略与组件原生权限（如 HDFS ACL、Hive 的 SQL 授权）并存时，实际生效的是交集还是并集取决于组件配置，务必在测试环境验证清楚，否则会出现"策略允许了但请求仍被拒"的诡异现象。

策略模型还有几个细节值得提前掌握。第一是 deny 的优先级：Ranger 策略体系中 deny 策略的优先级高于 allow，即使用户被某个 allow 策略授权，只要存在匹配的 deny 策略，访问仍会被拒绝，这是实现"黑名单例外"的常用手段。第二是通配符与资源层级：HDFS 策略可以用路径通配，Hive 策略按库、表、列分层，通配符写得太宽会把权限放大到意想不到的范围，建议先精确后放宽。第三是标签策略：Ranger 支持给资源打标签并按标签批量授权，适合敏感数据分级场景，例如把所有标记为"高敏感"的表统一授权给特定团队；标签策略与资源策略并存时同样存在优先级问题，要在测试环境验证。第四是行级与列级控制：Ranger 支持列掩码与行过滤，能实现细粒度脱敏，但对查询性能有影响，启用前要做基准测试，避免为了一条脱敏规则拖慢整条分析链路。

落地时给一个实用下一步：先别急着把所有组件都接入 Ranger，把 HDFS 或 Hive 其中一个组件完整跑通"Kerberos 认证 + Ranger 授权 + 集中审计"三条链路，沉淀一套组件接入清单（principal、keytab、repository、插件安装、策略样例、验证用例），再横向复制到其余组件。这套清单会成为后续每个组件接入的标准动作，也是排查问题的索引。