大数据集群安全加固：Kerberos+Ranger 端到端实践

大数据集群默认处于"裸奔"状态——任何能访问集群网络的用户都可以读写 HDFS 数据、提交 Spark 任务、查询 Hive 表。安全加固的核心目标是实现认证（确认你是谁）和授权（确认你能做什么）。OpenLDAP、Kerberos、Ranger 三层机制分别解决身份存储、网络认证、细粒度权限控制三个问题。本文提供从零开始的三阶段落地指南。

第一阶段：OpenLDAP 统一身份存储

OpenLDAP 作为统一的身份认证源，为集群所有组件提供用户和组信息。在引入 Kerberos 和 Ranger 之前，先建好 LDAP 是必要的基础工作。

部署要点：

使用独立的 2 到 3 台机器部署 OpenLDAP 主从集群。主节点处理写入请求，从节点处理读取请求，避免读写竞争。生产环境必须配置 TLS 加密，否则密码在网络中明文传输。

组织结构设计：

LDAP 的 DN（Distinguished Name）设计影响后续所有组件的集成。推荐的结构是 ou=users,dc=company,dc=com 存放用户，ou=groups,dc=company,dc=com 存放组。每个用户条目包含 uid、cn、mail、memberOf 等属性。组条目通过 member 属性关联用户。

一个关键的设计决策是：是否为服务账户创建 LDAP 条目。建议创建。HDFS、Hive、Spark 等服务之间的通信也需要通过 LDAP 识别身份，虽然 Kerberos 会接管网络认证，但 LDAP 中的服务账户条目可以用于 Ranger 的策略匹配。

与现有系统同步：

如果企业已有 Active Directory 或其他 LDAP 系统，可以配置 OpenLDAP 的 syncrepl 机制从上游同步用户数据，避免重复维护。同步频率建议设置为 15 分钟一次，平衡实时性和 LDAP 服务器负载。

第二阶段：Kerberos 网络认证

Kerberos 解决的是"在网络中如何安全地证明你是谁"的问题。它通过票据机制避免密码在网络中传输，实现双向认证。

KDC 部署：

KDC（Kerberos Distribution Center）是 Kerberos 的核心服务，包含 KDC 主节点和 KRB5 管理节点。建议部署 2 到 3 个 KDC 实例做高可用，使用 LDAP 作为 KDC 的后端数据库，实现与第一阶段的身份信息统一。

核心配置流程：

首先创建 realm（认证域），建议使用大写的公司域名，如 COMPANY.COM。然后为每个需要访问集群的服务和用户创建 principal。principal 的命名规则是 primary/instance@REALM，比如 hdfs/node1.company.com@COMPANY.COM。

为 HDFS 的 NameNode 和 DataNode 创建 principal 后，导出 keytab 文件并分发到各节点。keytab 文件相当于"免密登录凭证"，服务启动时通过 keytab 自动获取 Kerberos 票据。keytab 文件的权限必须严格控制在对应服务的运行用户下，建议权限设为 400。

各组件的 Kerberos 集成：

HDFS 是第一个需要开启 Kerberos 的组件。在 hdfs-site.xml 中配置 dfs.authentication = kerberos，在 core-site.xml 中配置 KDC 相关参数。开启后，所有对 HDFS 的访问都必须携带 Kerberos 票据。先在 NameNode 上测试 kinit 和 hdfs dfs -ls 是否正常，再逐步在 DataNode 上验证。

Hive Server2 的 Kerberos 集成需要额外配置 SPNEGO 认证，让浏览器和 JDBC 客户端能够通过 HTTP 协议访问 Hive。在 hive-site.xml 中配置 hive.server2.authentication.spnego.principal 和 hive.server2.authentication.spnego.keytab。

Spark 和 Flink 的 Kerberos 集成相对简单，在提交任务时指定 keytab 文件和 principal 即可。但要注意，长时间运行的 Flink 作业需要定期刷新 Kerberos 票据，否则票据过期后作业会失败。建议配置 kinit 定时任务，每 6 小时刷新一次。

常见排障经验：

Kerberos 报错信息通常不够直观。最常见的问题是 GSSException: No valid credentials provided，原因往往是 keytab 文件路径错误、principal 名称不匹配或 keytab 文件权限不对。排障的第一步是手动执行 kinit -kt <keytab_file> <principal> 测试认证是否成功。第二步是检查 keytab 文件内容，使用 klist -kt <keytab_file> 确认 principal 列表。第三步是检查系统时间是否同步——Kerberos 对时间偏差非常敏感，默认允许 5 分钟偏差，确保所有节点配置了 NTP 同步。

第三阶段：Ranger 细粒度权限控制

Ranger 在 Kerberos 的认证基础上提供授权能力，实现"你能访问什么资源、能做什么操作"的细粒度控制。

Ranger 部署：

Ranger 包含 Ranger Admin（策略管理 Web UI）和 Ranger UserSync（用户同步服务）两个核心组件。UserSync 负责从 LDAP 同步用户和组信息到 Ranger，确保 Ranger 中的用户与 LDAP 保持一致。Ranger Admin 需要连接 MySQL 或 PostgreSQL 存储策略数据。

核心配置流程：

首先在 Ranger Admin 的 Web UI 中配置 LDAP 用户源。填入第一阶段部署的 LDAP 服务器地址、绑定 DN 和搜索基点。配置完成后，Ranger 会自动同步 LDAP 中的用户和组。

然后配置各组件的 Ranger 插件。HDFS Ranger 插件负责文件和目录级别的权限控制，Hive Ranger 插件负责表、列、行级别的权限控制，Kafka Ranger 插件负责 Topic 级别的权限控制。每个插件在 Ranger Admin 中有独立的策略管理界面。

权限策略设计：

推荐按团队维度设计策略组。每个团队在 Ranger 中创建一个组（与 LDAP 组对应），然后为该组配置对应的资源权限。比如数据团队对 Hive 的 analytics 数据库有 SELECT 权限，算法团队对 ml_features 表有 SELECT 和 INSERT 权限。

行级别权限控制是 Ranger 的高级功能。通过在 Hive 策略中配置行过滤条件，可以实现"每个用户只能看到自己部门的数据"这类需求。但行级过滤对查询性能有一定影响，建议只在必要场景使用。

审计日志：

Ranger 默认开启审计日志，记录所有通过 Ranger 策略控制的访问操作。审计日志存储在 Ranger Admin 的数据库中，也可以配置推送到 Solr 或 Elasticsearch 便于检索和分析。建议保留至少 90 天的审计日志，满足安全合规审查的需求。

端到端验证

三阶段部署完成后，需要进行端到端的验证测试。

认证验证：从客户端机器执行 kinit <user> 获取 Kerberos 票据，然后分别测试 HDFS 读写、Hive 查询、Spark 任务提交。验证通过后，再测试不带票据时是否被正确拒绝。

授权验证：创建不同团队的测试用户，验证只能访问被授权的资源。测试场景包括：能查询被授权的 Hive 表、不能查询未授权的 Hive 表、不能读取未授权的 HDFS 目录、跨团队的数据访问被正确拦截。

高可用验证：模拟 KDC 主节点宕机，验证备用 KDC 能否正常提供认证服务。模拟 Ranger Admin 宕机，验证已加载策略的插件是否仍能正常执行权限检查（Ranger 插件会缓存策略，Admin 短暂不可用不影响在线权限检查）。

对于希望快速落地安全加固的团队，EasyMR 内置了 LDAP、Kerberos、Ranger 的多级权限体系，提供开箱即用的配置向导和自动化部署脚本，可以将三阶段的部署周期从数周缩短到数天。

运维注意事项

Kerberos 和 Ranger 引入后，运维复杂度显著增加。需要建立以下运维机制：Kerberos 票据过期监控——对所有服务账户配置 kinit 定时刷新和过期告警。Ranger 策略变更审计——所有策略变更必须通过工单审批，变更记录可追溯。keytab 文件轮换——定期（建议每 90 天）轮换 keytab 文件，旧 keytab 废弃后删除。LDAP 密码策略——配置密码复杂度要求、账户锁定策略和密码过期机制。

安全加固不是一次性工程，而是持续运营的过程。建立定期的安全审计流程，每季度审查一次权限策略的合理性，清理离职人员的账户和权限，确保安全策略与组织结构同步演进。