HBase 安全不是一个开关。Kerberos 解决身份认证，RPC protection 解决传输层保护，ACL 解决 HBase 资源授权，HDFS 和 ZooKeeper 还要各自按安全模式配置。任何一层缺失，生产集群都会留下绕过路径。

本篇只抓一个核心问题：客户端身份、服务认证、传输保护和表权限如何衔接。

安全路径图

flowchart TD
  Client[Client principal] --> KDC[Kerberos KDC]
  RS[RegionServer principal] --> KDC
  Master[HMaster principal] --> KDC
  Client --> RPC[HBase RPC/SASL]
  RPC --> AuthN[authentication]
  AuthN --> Protection[hbase.rpc.protection]
  Protection --> ACL[AccessController ACL]
  ACL --> Region[Region data]
  Region --> HDFS[HDFS secure mode]
  Master --> ZK[ZooKeeper SASL/ACL]

这张图有四个边界。Client、RegionServer、HMaster 先通过 Kerberos 拥有可验证身份；HBase RPC 再用 SASL 建立认证和可选加密；AccessController 在 HBase 资源层做授权；底层 HDFS 和 ZooKeeper 也必须配置自己的认证与 ACL。

官方安全文档明确要求：如果 HBase RPC 使用 Kerberos，底层 Hadoop 的 hadoop.security.authentication 也应设为 kerberos。否则 HBase 层认证并不能保护 HDFS 层访问。

关键对象和状态

层级 对象 负责的问题
身份 Kerberos principal、keytab、KDC 请求者是谁
传输 SASL、hbase.rpc.protection、TLS RPC 内容是否被保护
HBase 授权 AccessController、ACL、superuser 谁能读写哪些资源
HDFS HDFS secure mode、目录权限、encryption zone StoreFile、WAL 是否受保护
ZooKeeper SASL、znode ACL 集群协调状态谁能修改

Kerberos 只解决“身份可认证”。它不自动授予表权限，也不自动加密 RPC 内容。认证成功后，HBase 仍要根据 ACL 判断该用户能否读表、写表、建表、执行 Endpoint 或做集群管理。

hbase.rpc.protection 控制 RPC 保护级别。常见取值是 authentication、integrity、privacy。authentication 只认证身份；integrity 增加完整性保护；privacy 增加加密保护。生产环境应按威胁模型选择，不能把 Kerberos 登录成功等同于 RPC 内容加密。

AccessController 是 HBase 的授权核心。官方数据访问安全文档说明，HBase ACL 基于用户和组授予权限，范围可以是全局、namespace、table、cell 或 endpoint。权限字母包括 Read、Write、Execute、Create、Admin。

HBase ACL 的边界

ACL 常见权限如下：

权限 含义 典型对象
R 读数据 Get、Scan
W 写数据 Put、Delete、Increment
X 执行 Endpoint Coprocessor Endpoint
C 创建或删除资源 table、namespace
A 管理集群或资源 balance、assign、schema 管理

ACL 不等于关系数据库权限模型。HBase 不区分 insert 和 update，它们都落成 Put；因此授权设计要围绕 row、family、qualifier 和表级操作，而不是围绕 SQL 动词。

ACL 也不补齐跨行事务。权限检查通过后，请求仍按 HBase 的行级语义执行。一个用户有多张表的写权限，不代表一次跨表写入具备原子提交。

Cell 级权限和 visibility labels 可以进一步细化可见性，但它们会把授权状态放进数据读写路径。生产开启前要评估 Scan 性能、管理复杂度和审计路径。

HDFS 和 ZooKeeper 不能省

HBase 把 HFile 和 WAL 放在 HDFS 上。HBase 表 ACL 保护的是 HBase 服务语义，不是裸 HDFS 路径。如果 HDFS 未进入 secure mode，或 HBase 根目录权限过宽，用户可能绕过 HBase API 直接访问底层文件。

ZooKeeper 保存服务发现和协调状态。官方文档说明，HBase daemon 通过 SASL/Kerberos 访问 ZooKeeper，并给 znode 设置 ACL；某些用于服务发现的 znode 允许客户端读取，但只有 HBase 用户能修改。这里要分清“可读服务发现信息”和“可修改协调状态”。

这个边界和第 02 篇的架构边界一致：ZooKeeper 不是 HBase 所有持久元数据的存储地，hbase:meta 也不是安全系统。hbase:meta 是路由元数据表，HDFS 保存文件，ZooKeeper 协调在线状态；安全配置要覆盖每一层。

最小配置骨架

以下配置骨架来自官方安全文档语义，实际 principal、realm、路径按集群替换。当前本地没有 KDC 和 HBase 集群，标记为 UNVERIFIED_RUNTIME。

core-site.xml：

1
2
3
4
<property>
  <name>hadoop.security.authentication</name>
  <value>kerberos</value>
</property>

hbase-site.xml：

1
2
3
4
5
6
7
8
9
10
11
12
<property>
  <name>hbase.security.authentication</name>
  <value>kerberos</value>
</property>
<property>
  <name>hbase.security.authorization</name>
  <value>true</value>
</property>
<property>
  <name>hbase.rpc.protection</name>
  <value>privacy</value>
</property>

这里的 hbase.rpc.protection=privacy 属于 SASL/RPC protection，用于在 HBase RPC 认证链路上增加隐私保护。HBase 2.6.0+ 还提供独立的 RPC TLS 传输层加密，基于 Netty RPC 实现，和 Kerberos、simple access 等认证方式解耦。按官方 TLS 文档，服务端和客户端配置形状如下；当前本地没有 TLS HBase 集群，标记为 UNVERIFIED_RUNTIME。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<property>
  <name>hbase.server.netty.tls.enabled</name>
  <value>true</value>
</property>
<property>
  <name>hbase.client.netty.tls.enabled</name>
  <value>true</value>
</property>
<property>
  <name>hbase.rpc.tls.keystore.location</name>
  <value>/path/to/keystore.jks</value>
</property>
<property>
  <name>hbase.rpc.tls.truststore.location</name>
  <value>/path/to/truststore.jks</value>
</property>

AccessController 相关 coprocessor 也要启用。HBase 2.x 的配置示例包含 master、region、regionserver 层的 AccessController，以及 TokenProvider、VisibilityController 等组件。生产配置应以目标版本官方文档为准，不能从旧版本博客复制类名。

客户端登录通常通过 kinit 完成：

1
kinit user@EXAMPLE.COM

HBase shell 连接后授予表级读写权限：

1
grant 'app_user', 'RW', 'lab:secure_table'

这些命令只说明操作形状，不提供虚构返回。验证应查看 user_permission、实际 Get/Put 行为、RegionServer 审计日志和 HDFS 路径权限。

最小实验

实验目标是证明四层边界分别生效，均为 UNVERIFIED_RUNTIME。先用未登录 Kerberos 的客户端访问 HBase，预期应被认证层拒绝。

1
hbase shell

再登录没有表权限的 principal。这个用户可以通过身份认证，但读写目标表应被 ACL 拒绝。

1
kinit no_table_perm@EXAMPLE.COM

随后授予 R 权限，验证读成功、写失败。

1
grant 'no_table_perm', 'R', 'lab:secure_table'

HBase 层验证完成后，还要检查 HDFS 上 HBase 根目录权限，确认普通用户不能直接读 StoreFile。

1
hdfs dfs -ls /hbase

第五步，检查 ZooKeeper znode ACL，确认服务发现可读项和修改权限分离。

1
hbase zkcli

观察点包括认证失败类型、ACL 拒绝类型、RPC protection 配置、HDFS permission、ZooKeeper ACL。任何一项通过不了，都不能声称生产安全完成。

失败恢复

Kerberos 故障通常表现为客户端无法连接或服务端无法启动。优先检查 principal、keytab 权限、时钟同步、KDC 可达性和 realm 配置。时钟漂移会直接导致票据无效。

ACL 配错通常表现为连接成功但读写失败。恢复策略应该使用 superuser 或受控管理员账号修改权限，不应关闭全局授权来“临时恢复”。关闭授权会改变整个集群安全边界。

RPC protection 配错可能导致客户端和服务端协商失败。升级或灰度时应确认所有客户端支持相同保护级别。

HDFS 或 ZooKeeper 安全配置缺失时，修复范围超出 HBase 本身。必须把 Hadoop secure mode、目录 owner、ZooKeeper SASL 和 znode ACL 一起纳入变更计划。

工程迁移

问题 HBase 层答案 可迁移模式
谁在访问 Kerberos principal 先认证身份
通道是否安全 SASL/RPC protection/TLS 再保护链路
能做什么 ACL 后授权动作
底层文件是否裸露 HDFS secure mode 存储层也要关门
协调状态谁能改 ZooKeeper ACL 控制面权限单独收紧

模式提炼：认证、传输、授权、底层存储不能互相替代。Kafka、HDFS、Elasticsearch、Kubernetes 都有同类分层；一层看起来“已经安全”，不代表旁路也安全。

常见误解

误解一：开启 Kerberos 后 HBase 就安全。Kerberos 只是认证身份，授权、RPC 保护、HDFS 和 ZooKeeper 仍要配置。

误解二：HBase ACL 能保护裸 HDFS 文件。HBase ACL 只在 HBase 服务路径内生效，HDFS 权限必须独立正确。

误解三：ZooKeeper 保存 HBase 数据，所以保护 ZooKeeper 就够。ZooKeeper 保存协调和发现状态，表数据在 HDFS，路由元数据在 hbase:meta。

误解四：REST 或 Thrift 网关天然继承安全。官方安全模型说明这些网关是可选服务，默认配置不等于生产安全配置，必须单独开启认证或限制网络访问。

练习

  1. 为一个只读报表用户设计最小权限，列出 Kerberos principal、HBase ACL、HDFS 权限和 ZooKeeper 访问要求。
  2. 把 hbase.rpc.protection 的三个级别放进同一张表，说明各自保护身份、完整性和隐私的差异。
  3. 检查一个生产上线清单是否同时包含 HBase、HDFS、ZooKeeper 和网关安全项。

系列导航

参考资料

证据等级：安全模型和配置边界为 VERIFIED_SOURCE；本地没有 KDC 和安全 HBase 集群，实验为 UNVERIFIED_RUNTIME。