数据治理之安全管理：Apache Ranger

一、Apache Ranger 是什么

Apache Ranger 是一个为 Hadoop 生态提供集中式安全管理 的框架。它通过统一的控制台，实现对 HDFS、Hive、HBase、Kafka、YARN、Solr、Spark 等组件的细粒度访问控制 、统一审计 与数据脱敏。简单来说，它让大数据平台的管理员可以在一个地方为所有服务定义"谁、在什么资源上、能做什么"的策略，并实时查看所有访问记录，从而告别各个组件分散授权、审计缺失的问题。

Ranger 的核心价值：

• 集中策略管理：通过 Web UI 为 HDFS、Hive、HBase、Kafka、YARN、Solr、Spark 等配置精细化策略。

• 细粒度控制：支持库、表、列、字段级权限；支持动态行过滤与数据脱敏（redact、partial mask、hash 等）。

• 标签策略：结合 Apache Atlas 的标签（如 PII），实现"安全策略跟随数据分类"，无需逐一资源配置。

• 统一审计：所有访问决策记录到 Solr/HDFS，可通过 UI 检索。

• 安全区域：多租户场景下实现分级分权管理，区域管理员只能管理自己区域内的策略。

• 高可用架构：Admin 多实例，插件拉取策略并本地缓存，决策无单点，性能高。

二、主要功能

1. 基于资源的策略模型

策略围绕资源（Resource） 构建，例如：

• HDFS：路径 /user/*

• Hive：数据库 sales、表 orders、列 credit_card

• Kafka：Topic transactions

每条策略可以设置：

• 允许条件：赋予的用户、组或角色，以及具体的访问类型（如 Read、Write、Select、Create 等）。

• 拒绝条件（Exclude/Deny）：显式排除某些用户或组，其优先级高于允许。

• 递归：是否将策略应用到资源的子级（如 HDFS 路径下的所有子目录）。

• IP 范围、时间窗口等额外约束（部分组件支持）。

2. 标签策略（Tag-based Policy）

与传统的"为每个资源手写策略"不同，Ranger 可以与 Apache Atlas 集成，通过标签实现动态授权。

• 在 Atlas 中给资源（如表、列、文件）打上分类标签（如 PII、SENSITIVE、PUBLIC）。

• 在 Ranger 中创建一个基于标签的策略，如："对所有打上 PII 标签的列，analyst 组只能看到掩码后的数据"。

• 资源一旦被贴上标签，就会自动继承该标签对应的策略，无需一一配置，极大降低管理成本。

3. 数据脱敏与行级过滤

这是 Ranger 在 Hive 等查询引擎上非常强大的安全能力：

• 数据脱敏（Data Masking）：对敏感列的输出实时变形。常用方式：

  • Redact：全部替换为 x。

  • Partial mask: show last 4：仅显示后4位，其余为 x。

  • Hash：替换为哈希值。

  • Date: show only year：仅显示年份。

• 行级过滤（Row-level Filter） ：在策略中为用户或组附加一个类似 WHERE 子句的过滤表达式。例如：dept = current_user() 或 region = 'US'。用户查询时，Ranger 自动将条件注入 SQL，实现"同一张表不同用户看到不同行"。

4. 统一审计（Audit）

• 插件将每一次访问决策（包括允许和拒绝）异步发送到 Solr 或 HDFS。

• Audit 信息包括：用户、请求资源、访问类型、时间、客户端 IP、结果等。

• 在 Ranger Admin UI 中可按服务、用户、日期、结果等维度检索，满足 GDPR、SOC2 等合规审计要求。

5. 安全区域（Security Zones）

• 用于多租户环境，可将一组资源（如某个 Hive 数据库及其关联的 HDFS 目录）划入一个安全区域。

• 区域可以委派专门的管理员，该管理员只能管理该区域内的策略，无法查看或修改其他区域。

• 超级管理员仍拥有全局权限。这实现了"分级分权"的管理模式。

6. 插件策略缓存与决策流程

• 插件本地存有完整的策略、用户组信息。

• 决策时，会合并所有相关策略（资源策略、标签策略），按优先级（拒绝 > 排除 > 允许）判断。

• 大部分组件还会提供 "Ranger 策略通过后，是否再结合原生权限做二次检查" 的配置项，默认通常为 Ranger 权限即最终权限。

7. 与 Kerberos 的集成

• Ranger Admin 本身可通过 Kerberos/LDAP 进行管理员的身份认证。

• 插件不直接认证用户，它依赖底层组件（如 HDFS、HiveServer2）已完成 Kerberos 认证，从请求上下文中提取用户主体和组信息进行授权。

三、核心架构

Ranger 主要由以下部分构成：

1. Ranger Admin Server（管理服务）

2. Ranger Usersync（用户同步服务）

3. Ranger Plugin（内嵌在各组件中的策略执行插件）

4. 存储层：

   • 策略库：关系数据库（MySQL / PostgreSQL / Oracle）

   • 审计库：Solr / HDFS（兼用作审计日志存储与检索）

这三大组件协同工作，形成"策略管理 → 策略分发 → 本地实时决策 → 集中审计"的闭环。

---

1. 管理平面：Ranger Admin Server

Admin Server 是整个系统的核心控制台，对外提供 Web UI 和 REST API。

核心职责：

• 服务定义管理：定义受管组件类型（如 Hive、HDFS、Kafka）及其资源模型（库、表、列、路径等）。

• 策略管理：创建、更新、删除基于资源或基于标签的访问策略、脱敏规则、行过滤条件。

• 安全区域管理：划分 Zone 并委派区域管理员，实现分权管理。

• 审计日志检索：从 Solr 中查询各类访问审计记录，提供可视化界面。

• 用户/组信息存储：接收并存储由 Usersync 同步过来的用户和组关系。

存储细节：

• 所有策略、服务定义、安全区域、用户组等元数据持久化在关系型数据库中。

• Admin 本身不直接参与实时访问决策，因此压力较小，天然支持多实例部署实现高可用（前端通过负载均衡器分发）。

高可用架构：

• 多个 Admin 节点共享同一策略数据库，均为无状态服务。

• 任一 Admin 故障，其余节点可继续提供管理与策略下载服务，不影响组件侧的鉴权。

---

2. 用户同步：Ranger Usersync

Usersync 是一个独立服务，负责将企业目录（LDAP/AD 或 Unix 系统）中的用户和组信息定时同步到 Admin 的数据库中。

架构要点：

• 支持增量或全量同步，可配置拉取间隔（如每小时一次）。

• 从 LDAP/AD 中获取用户属性（uid、groupMembership）并映射到 Ranger 的 x_user、x_group 表。

• 这些用户、组信息会被打包进插件下载的策略缓存中，使得各个组件的插件在决策时能够直接从本地获取用户所属组列表，无需实时查询 LDAP。

---

3. 策略执行平面：Ranger Plugin

Plugin 是整个架构中实现高性能、高可用实时授权的关键，以轻量级 Java 库的形式嵌入到每个受管组件进程中（如 HDFS NameNode、HiveServer2、Kafka Broker 等）。

1. 插件启动与策略拉取（Pull 模型）

• 插件启动时，通过 Admin REST API 一次性下载全量策略和用户/组信息 ，以 JSON 文件形式存储在本地磁盘（默认路径 /etc/ranger/<service>/policycache/）。

• 后台PolicyRefresher线程定期（默认 30 秒）向 Admin 拉取策略变更（基于版本号或最后修改时间），增量更新本地缓存。

• 这种拉取模型 的好处是：Admin 压力小，网络抖动影响小；即使 Admin 全部宕机，插件仍可基于本地缓存独立决策，不会导致组件不可用。

2. 决策引擎（Policy Engine）

当用户请求到达组件时，插件拦截组件原本的授权检查点，进行策略评估。

拦截点举例：

• HDFS ：NameNode 在执行文件操作前，FSPermissionChecker 被替换为 Ranger 的鉴权实现。

• Hive：HiveServer2 编译 SQL 时，Ranger 通过 Hook 注入，在解析库表列时进行权限检查。

• Kafka ：Broker 处理 Produce/Consume 请求时，通过 KafkaPrincipal 接口调用 Ranger 插件。

决策流程（优先级由高到低）：

1. 提取请求上下文：用户、用户组（从本地缓存或组件会话获取）、资源路径（如表、列、HDFS路径）、访问类型（select、write等）。

2. 拒绝策略（Deny）：一旦匹配任何显式拒绝策略，直接拒绝，不再继续。

3. 排除策略（Exclude）：排除条件中的用户/组将被排除出允许列表。

4. 允许策略（Allow）：在未命中拒绝与排除的情况下，匹配允许策略。

5. 若同时存在基于标签的策略，这些策略也会合并评估（同样遵循 Deny > Exclude > Allow 的优先级）。

6. 所有策略均未匹配时，默认为拒绝（可配置为回退到原生权限）。

整个过程全内存计算、无远程调用、无数据库查询，延迟在微秒级，对组件性能几乎无影响。

3. 标签策略的架构支持

标签策略使安全模型从"为每个资源配置"变成"安全策略跟随数据分类"。其架构需要 Atlas 与 Ranger 联动：

• Apache Atlas 负责为数据资产（Hive表/列、HDFS路径等）打上分类标签（如 PII、SENSITIVE）。

• Ranger TagSync（可内嵌于 Admin 或作为独立进程）定期从 Atlas 拉取"资源→标签"的映射关系，并下发给各插件。

• 插件在本地缓存中同时拥有标签策略 和资源-标签映射。决策时，首先找出请求资源对应的所有标签，再用这些标签去匹配标签策略中的 Deny / Allow 规则，并结合脱敏和行过滤执行。

• 例如：某列被打上 PII 标签，而 Ranger 中有"PII 列仅显示后4位"的标签掩码策略，则该列自动被掩码，无需单独配置列策略。

4. 数据脱敏与行过滤的实现

• 脱敏 ：Hive 插件会在 SQL 编译阶段，将被策略标记为需脱敏的列，改写查询计划 （如将 select ssn from ... 替换为 select mask_show_last4(ssn) from ...），用户最终获得的是被处理后的数据。

• 行过滤 ：策略中定义的行过滤表达式（如 dept = 'sales'）会被自动注入 SQL 的 WHERE 子句 ，形成 select * from t where (original_where) AND dept = 'sales'。这一切对查询方透明。

---

4. 审计平面

每次插件做出访问决策（允许/拒绝），都会生成一个审计事件，包含用户、资源、操作类型、时间、客户端 IP、决策结果等。审计事件异步发送到审计存储，不影响业务路径。

审计存储与流转：

• Solr 模式：事件直接发送到 SolrCloud，供 Ranger Admin UI 近乎实时地搜索和分析。

• HDFS 模式：事件落地到 HDFS 文件，供后续离线抽取至企业 SIEM 或数仓，满足合规留存需求。

• 可同时开启双写，并在插件端配置故障转移策略（如 Solr 不可用时暂存本地文件）。

四、实践：Ranger管理Hive安全

参考：数据治理（十五）：Ranger管理Hive安全

五、其他组件介绍

1. Apache Sentry（已退役的授权模块）

Sentry 曾是 Cloudera 主推的授权框架，从 CDH 6.x 起已被 Ranger 取代，最后一次 Apache 发布停留于 2018 年。功能概述：

• 基于角色的授权 ：将权限授予角色，再将角色赋给用户/组，支持 SELECT、INSERT、ALL 等操作。

• 资源模型 ：仅支持层次化资源，如 server → database → table → column。

• 支持组件：Hive、Impala、Solr（不支持 HDFS、Kafka、YARN 等）。

• 策略管理 ：没有 Web UI，策略通过配置文件（sentry-site.xml）或 SQL 命令（CREATE ROLE、GRANT）管理，不够直观。

• 无脱敏/行过滤：不提供数据遮蔽和行级过滤能力。

• 审计 ：Sentry 自身只记录策略变更日志，访问审计需依赖 Hive/Impala 等组件的审计日志，无统一审计 UI。

2. Apache Knox（边界安全网关）

Knox 是一个反向代理网关，为 Hadoop 集群提供 REST API 层的安全增强：

• 统一入口：将所有组件的 REST 端点（如 WebHDFS、Hive JDBC over HTTP、YARN UI）隐藏在一个 Knox 地址后面，隐藏集群拓扑。

• 认证与 SSO：支持基于 LDAP、Active Directory、SAML/OIDC 的身份验证，提供单点登录，简化客户端认证。

• 简单服务级 ACL ：可以按 URL 路径和 HTTP 方法，允许/拒绝特定用户、组或 IP 访问具体服务（如允许 analyst 组访问 Hive JDBC，拒绝访问 YARN UI），这是粗粒度的服务访问控制，而非数据级授权。

• 联合安全：Knox 可与 Ranger 集成，将身份信息传播给后端服务，由 Ranger 做细粒度鉴权；也可利用 Ranger 提供的 Audit 能力记录网关访问事件。

3. Apache Atlas（数据治理与分类引擎）

Atlas 本质上不是授权框架，但通过与 Ranger 深度集成，成为基于标签的安全管理关键一环：

• 数据分类与标签 ：允许为 Hadoop 数据资产（Hive 表/列、HDFS 路径、Kafka Topic 等）打上业务或合规标签（如 SENSITIVE、GDPR、PUBLIC）。

• 标签传播与血缘：自动通过血缘关系传递标签。

• 与 Ranger 联动 ：Ranger 可以针对这些标签设置标签策略，实现"一类数据一种策略"的动态授权。脱离 Ranger，Atlas 本身不执行访问控制。

4. Kerberos（强身份认证）

Kerberos 是 Hadoop 默认的强认证机制，不提供授权功能，但它是所有安全框架的基础：

• 确保每个用户和服务都有唯一、可验证的身份（Principal）。

• 防止身份伪装，所有组件在请求时会携带 Kerberos 票证。

• Ranger、Sentry 等授权框架均依赖 Kerberos 或 LDAP 提供的可信用户身份来做后续策略判断，Knox 也常与 Kerberos 联动代理认证。

---

🚧 Ranger vs Knox：授权与网关，互补关系

• 定位：

  • Ranger 解决"用户通过认证后，能对数据做什么" ------ 细粒度数据授权。

  • Knox 解决"用户怎么安全地接触到集群，以及能访问哪些服务" ------ 边界安全与粗粒度服务访问控制。

• 粒度 ：Ranger 可控制到列、行、数据掩码；Knox 仅控制到服务 URL 级别（如能否访问 /gateway/hive）。

• 实际组合：Knox 常作为集群的单一入口，完成认证和 SSO，将用户身份注入请求，然后交给各组件内的 Ranger 插件进行细粒度鉴权。两者分层配合。

🏷️ Ranger vs Atlas：策略引擎与数据分类，互补

• Atlas 本身不做授权，而是通过标签为数据打上"属性"。

• Ranger 作为策略执行引擎，可以识别这些标签，并应用动态安全策略（如"所有 PII 列的查询都要脱敏"）。

• 这种"分类+策略"的模式实现了安全与数据的解耦，是大规模平台的最佳实践。

🔑 共同的基石：Kerberos

所有上述框架（Ranger, Sentry, Knox）都假设用户身份已通过 Kerberos/LDAP 认证，它们只解决授权和审计问题，不替代认证体系。

六、端到端数据流示例（一次 Hive 查询）

综合以上组件，一个典型的请求处理流程如下：

1. 身份认证：用户通过 Kerberos / Knox 完成认证，HiveServer2 获取到用户 principal。

2. SQL 解析拦截：Hive 编译 SQL，触发 Ranger Hive 插件。

3. 本地决策 ：插件从缓存中获取用户组、相关 Hive 资源策略及标签策略（资源可能关联 Atlas 标签），执行 deny/exclude/allow 评估，并可能改写查询计划 （掩码）及注入行过滤条件。

4. 审计记录：无论决策结果如何，异步发送审计事件到 Solr/HDFS。

5. 策略刷新：后台线程每 30 秒检查 Admin 策略更新，并热加载到本地缓存，不中断服务。

6. 管理变更 ：安全管理员通过 Admin UI 修改策略后，插件在下次拉取周期内自动获取新策略，无需重启任何服务。