1. 从一次权限失控的排查说起为什么大数据平台绕不开Kerberos、Sentry和Ranger刚接手一个离线数仓集群那会儿我遇到过一次挺典型的事故某个业务方的分析师在跑一段临时SQL时误把一张核心明细表的全量数据导到了自己的临时目录而这张表按规范只应该对风控团队开放。事后复盘发现问题不在SQL本身而在于集群当时只做了简单的账号密码登录谁登录进来、能碰哪些库、能读哪些列几乎全靠自觉。这件事之后我们花了大概两周时间把认证、授权、审计这三块重新梳理了一遍核心就是三个组件Kerberos、Sentry、Ranger。这三个词经常被放在一起提但很多人对它们的边界其实是模糊的。简单说Kerberos解决的是你是谁的问题也就是身份认证Sentry和Ranger解决的是你能干什么的问题也就是授权。前者是入场券后者是场内通行规则。三者配合才构成一套完整的大数据平台安全策略。这篇文章我会从实际落地的角度把这三个组件的定位、配置要点、踩过的坑以及它们之间怎么协同尽量讲透。适合正在搭建或维护Hadoop生态集群、被权限问题折腾过的运维和开发同学参考也适合刚接触大数据安全、想搞清楚这几个名词到底差在哪的入门者。需要先说明一点Sentry和Ranger在功能上有重叠很多团队只会选其中一个。它们不是必须同时上选型取决于你的集群组件构成和团队习惯。下面我会分别拆开讲再讲它们怎么和Kerberos串起来。2. Kerberos在大数据集群里到底扮演什么角色2.1 没有Kerberos的集群等于门没锁在没启用Kerberos的Hadoop集群里默认情况下任何能连上NameNode或HiveServer2的人都可以伪装成任意用户提交任务。因为早期的Hadoop假设集群运行在一个可信网络内用户身份靠客户端自己声明。你只要在提交任务时写-Duser.namehdfs服务端就真把你当成hdfs。这在内部测试环境无所谓但一旦集群承载了多业务方数据这就是个巨大的口子。Kerberos的作用就是把这个自报家门的模式换成出示证件。它基于对称密钥和票据Ticket机制用户先向KDCKey Distribution Center密钥分发中心证明自己的身份拿到一张TGTTicket Granting Ticket再用TGT去换取访问具体服务比如HDFS、Hive的Service Ticket。整个过程用户不需要在每次访问时输入密码票据有有效期过期自动失效。这里有个关键概念叫Principal可以理解成身份标识格式通常是用户名/实例REALM比如hive/host1EXAMPLE.COM。服务端也有自己的Principal客户端访问服务时双方通过KDC完成一次双向验证。这套机制的好处是密码不在网络上传输票据有生命周期且可以做到服务端和客户端互相确认身份防止中间人冒充。2.2 落地Kerberos时最容易卡住的几个点理论听着顺但真配起来Kerberos是这三个组件里最容易让人抓狂的。我整理了几个高频卡点。第一时间同步。Kerberos对时间极其敏感默认允许的时钟偏差是5分钟。如果KDC和集群节点时间不同步票据会被判定为无效报错通常是Clock skew too great。所以部署前务必确保所有节点都指向同一个NTP源。这个坑我踩过当时一台新加的节点忘了配NTP结果它上面的任务全部认证失败排查了半天才发现是时间差了两分多钟。第二Principal和Keytab的对应关系。服务端每个需要认证的服务都要有自己的Principal和对应的Keytab文件存着密钥的文件。Keytab相当于服务的长期密码服务启动时用它向KDC证明自己。常见错误是Keytab里存的Principal和服务配置里写的不一致或者Keytab权限没设好被其他用户读走。Keytab文件权限一般要设成400或440属主是运行该服务的用户。第三客户端配置。用户机器上要有krb5.conf指向KDC和krb5.keytab如果需要免密。很多认证失败其实不是服务端问题而是客户端krb5.conf里的realm大小写、KDC地址写错了。建议先用kinit命令手动测试kinit -kt user.keytab userREALM再用klist看票据是否拿到。这一步能快速定位是客户端还是服务端的问题。第四Hadoop各组件对Kerberos的支持程度不一。HDFS、YARN、Hive这些核心组件支持很成熟但一些周边工具比如某些调度器、监控agent可能对Kerberos支持不完善需要额外配置或者用代理用户proxy user的方式绕过。代理用户是个双刃剑配不好等于开了后门后面讲授权时会再提。提示Kerberos只负责认证不负责授权。也就是说用户通过Kerberos证明了我是张三但张三能不能读某张表Kerberos不管。这就是为什么还需要Sentry或Ranger。3. Sentry为Hive和Impala量身定做的授权方案3.1 Sentry的设计思路基于角色的细粒度控制Sentry是早期Cloudera系产品里主推的授权组件主要服务于Hive、Impala这些SQL引擎。它的核心模型是Role角色权限不直接授予用户而是授予角色再把角色授予用户或用户组。这样做的好处是权限管理可以批量化和结构化比如数据分析师这个角色统一拥有某几个库的SELECT权限新来的人只要加入这个角色就行。Sentry的权限粒度可以细到库、表、列甚至视图。比如你可以规定某用户只能看orders表的order_id和amount两列其他列比如用户手机号不可见。这种列级权限在合规要求高的场景里非常有用。它通过Hive的hook机制拦截SQL在编译阶段就判断权限没权限直接拒绝不会等到执行时才报错。Sentry的权限模型大致分几层Server服务级比如HiveServer2、Database、Table、Column还有URI针对HDFS路径。授权语句类似SQL比如-- 创建角色 CREATE ROLE analyst; -- 授予角色对某库的SELECT权限 GRANT SELECT ON DATABASE sales TO ROLE analyst; -- 把角色授予用户组 GRANT ROLE analyst TO GROUP data_team;这套语法对熟悉SQL的人来说上手很快。但要注意Sentry的权限是叠加的用户最终权限是它所有角色权限的并集没有拒绝优先的概念。也就是说你没法显式地拒绝某个权限只能通过不授予来实现。这点和某些系统的deny优先逻辑不同设计权限时要留意。3.2 Sentry实际使用中的几个坑坑一Sentry和HDFS权限的联动。Sentry管的是SQL层权限但底层数据还是存在HDFS上。如果一个用户通过Sentry拿到了某张表的SELECT权限但HDFS上那个文件目录的权限不允许他读任务照样会失败。反过来如果HDFS权限过松用户可能绕过Sentry直接用hdfs dfs -cat读文件。所以Sentry通常要配合HDFS ACL和Kerberos一起用确保底层文件权限和上层SQL权限一致。实践中很多团队会让Hive的仓库目录属主是hive其他用户通过HiveServer2访问不直接碰HDFS。坑二Sentry对非SQL组件支持有限。Sentry主要覆盖Hive和Impala对HBase、Kafka、YARN队列等的授权支持较弱或没有。如果你的集群组件很杂Sentry可能不够用这也是后来Ranger流行起来的原因之一。坑三角色继承和权限膨胀。角色可以嵌套角色授予角色用久了容易出现这个角色到底有哪些权限说不清的情况。建议定期用SHOW ROLE GRANT之类的命令导出权限清单做审计避免权限越滚越大。坑四和Kerberos配合时的代理用户问题。HiveServer2在Kerberos环境下通常以hive这个Principal运行但实际执行SQL的用户是登录的用户。这中间靠**代理用户proxy user**机制传递身份。如果hive-site.xml里的代理用户配置不对会出现所有操作都以hive身份执行的情况Sentry的权限判断就失效了。配置项主要是hadoop.proxyuser.hive.hosts和hadoop.proxyuser.hive.groups要明确允许哪些主机和组的用户被代理。4. Ranger覆盖面更广的统一授权中心4.1 Ranger凭什么成为很多团队的首选Ranger最早由Hortonworks推动后来随着社区融合逐渐成为Apache顶级项目。它和Sentry最大的区别在于覆盖面Ranger通过插件plugin的方式支持HDFS、Hive、HBase、Kafka、YARN、Storm、Solr等一大堆组件基本上主流的大数据组件都能纳管。对于组件多、希望统一权限入口的团队Ranger的吸引力很大。Ranger的架构分两部分Ranger Admin管理端提供Web UI和REST API存策略和Ranger Plugin嵌入在各个组件进程里负责实际鉴权。策略在Admin上配置插件定期拉取策略缓存到本地鉴权时直接查本地缓存性能损耗小。这种设计让Ranger既能集中管理又不至于每次鉴权都远程调用实用性很强。Ranger的策略模型比Sentry更灵活支持允许Allow和拒绝Deny两种规则且Deny优先。这意味着你可以先给一个大范围允许再针对特定用户或IP做精确拒绝。它还支持基于**标签Tag**的授权比如给某些列打上敏感标签然后规定所有带敏感标签的列只有合规角色能访问这种基于标签的方式在数据分类分级场景里特别好用。4.2 Ranger策略配置的实操要点Ranger的Web UI里每个组件有独立的策略页面。以Hive为例一条策略通常包含资源库、表、列、URL、用户/组、权限select、update、create等、条件IP范围、时间等、允许/拒绝。配置时几个经验点资源匹配支持通配符比如sales_*匹配所有以sales开头的库。但通配符用多了会让策略难以审计建议核心库用精确匹配。策略优先级Ranger按策略的拒绝优先、具体优先原则匹配。一条针对具体表的Deny会覆盖针对整个库的Allow。配置时要理清顺序否则容易出现明明给了权限却访问不了的情况。审计日志Ranger自带审计功能能记录每次访问的请求、结果、策略命中情况。这个在排查权限问题和做合规审计时非常有用建议开启并定期归档。Ranger的另一个优势是集中式管理。所有组件的权限都在一个界面配不用像Sentry那样只盯着Hive。对于有几十个组件、上百个用户的集群这种统一入口能省大量沟通成本。4.3 Ranger和Kerberos的协同细节Ranger本身不负责认证它依赖Kerberos或其他认证机制提供用户身份。在Kerberos环境下Ranger插件从当前请求的**UGIUser Group Information**里拿用户名和组信息再和策略比对。这里有个细节组信息从哪来。Hadoop默认从操作系统或LDAP拿组如果组映射不准Ranger的策略可能匹配错。建议统一用LDAP或系统组并确保各节点组信息一致。另外Ranger Admin本身也需要认证保护通常配Kerberos或LDAP登录避免任何人打开Web UI就能改策略。生产环境一定要改默认密码并限制Admin的访问来源IP。5. 三者如何串成一条完整的安全链路5.1 认证到授权的完整流程拆解把三个组件串起来看一次典型的Hive查询请求安全链路大致是这样的用户认证用户用kinit拿到TGT再向KDC申请HiveServer2的Service Ticket。建立连接客户端用Service Ticket和HiveServer2建立安全连接HiveServer2验证票据确认用户身份。代理传递HiveServer2以hive身份运行通过代理用户机制把实际用户身份传递给底层HDFS和YARN。授权判断Hive在编译SQL时调用Sentry或Ranger插件检查该用户对目标库表的权限。底层访问如果上层授权通过Hive再去HDFS读数据此时HDFS层可能还有Ranger的HDFS插件或HDFS ACL做二次校验。审计记录Ranger或Sentry记录这次访问的审计日志。这条链路里任何一环配错都会导致失败。比如Kerberos认证过了但代理用户没配好底层HDFS会以hive身份访问可能读到不该读的数据或者Sentry给了权限但HDFS ACL没放开任务报Permission denied。5.2 选型建议Sentry还是Ranger很多团队纠结到底用哪个。我的经验是维度SentryRanger覆盖组件主要Hive、ImpalaHDFS、Hive、HBase、Kafka、YARN等权限模型角色为主无DenyAllow/DenyDeny优先支持标签管理界面较弱偏命令行完善的Web UI审计基础完善可集中查看社区活跃度逐渐下降活跃Apache顶级项目适用场景纯Hive/Impala、Cloudera老集群组件多、需统一管理的集群如果你的集群组件单一、历史包袱是Cloudera系Sentry够用如果是新建集群、组件多样直接上Ranger更省心。两者不建议同时启用容易冲突。5.3 一个容易忽略的环节HDFS透明加密与列级脱敏认证和授权解决了谁能访问但数据本身如果没加密拿到文件的人还是能直接看。所以完整的安全策略里通常还会加上HDFS透明加密TDE和动态脱敏。TDE让HDFS上的数据以密文存储只有持有密钥的进程能解密动态脱敏则是在查询结果返回时对敏感列做掩码比如把手机号中间四位变成星号。Ranger支持基于标签的脱敏策略Sentry在这方面能力较弱。这两块内容展开又是一大篇这里先点一下知道它们是授权之后的补充手段即可。6. 上线前必须做的几项验证和长期维护经验6.1 权限变更后的回归测试清单安全策略配好后最怕的是改一处、崩一片。每次调整权限建议按这个清单回归认证层用kinit测试各业务账号能否正常拿票检查Keytab是否过期Keytab里的密钥有版本KDC轮换密钥后要重新导出。授权层用不同角色的账号分别测试该能访问的和不该能访问的操作确认Allow和Deny都生效。底层一致性抽查几个关键表确认HDFS文件权限和上层SQL权限一致没有上层禁、底层开的漏洞。审计确认审计日志正常记录且能查到刚才的测试操作。这个清单看着简单但真出事时能帮你快速定位是哪一层的问题。6.2 长期维护权限治理比配置更难配置是一次性的治理是长期的。我见过太多集群上线时权限配得漂漂亮亮半年后角色嵌套了七八层谁也说不清某个用户到底有哪些权限。几个实用做法定期导出权限清单Ranger有REST API可以定期拉取所有策略存档做diff对比发现异常变更。最小权限原则新用户默认不给权限按需申请而不是先给个大权限再慢慢收。角色命名规范比如role_业务域_权限级别避免出现role1、test_role这种含义不明的名字。离职和转岗清理把权限回收纳入人事流程别等人走了半年权限还挂着。6.3 我踩过的一个典型坑Kerberos票据缓存导致的幽灵权限最后分享一个挺隐蔽的坑。有次测试发现某个已经被移除角色的用户居然还能访问某张表。排查后发现是因为他的Kerberos票据缓存/tmp/krb5cc_uid还没过期而某些组件的授权判断依赖票据里的组信息票据里的组是旧的。清理票据缓存kdestroy后重新登录就正常了。这提醒我们权限变更后要让相关用户重新认证否则旧票据可能带着旧身份继续用一段时间。票据有效期一般设8到24小时敏感环境可以设短一些。另外Kerberos的票据续期renew也要注意长时间运行的任务如果票据过期会中途失败。可以用kinit -r指定可续期时长或者用keytab自动续期。这套安全策略搭起来确实费劲但一旦跑顺后面基本就是维护和微调。真正难的不是技术配置而是让所有业务方理解并配合这套规则。我的体会是前期多花时间做权限梳理和文档后期能省下大量救火的时间。