企业官网建设流程全解析

• 后端
• 大数据

Apache Storm 默认以"信任内网"的方式运行，所有认证（Authentication）与授权（Authorization）默认关闭，可通过配置按需开启。本文以仓库根目录 SECURITY.md 为核心骨架，结合 storm.yaml.example、SimpleACLAuthorizer.java、ImpersonationAuthorizer.java 等源码与配置，系统讲解一条从防火墙/OS 层防护、UI/Logviewer 访问控制、UI/DRPC SSL、Kerberos 认证，到 SimpleACLAuthorizer 授权、多租户隔离、worker 用户隔离、Netty 认证、用户模拟与自动凭证续期的完整安全加固路线。读完本文，你将能够在生产集群上按需开启认证授权、配置端口与 HTTPS、部署 Kerberos 与 JAAS、定义拓扑级与集群级 ACL，并理解每条配置背后的源码实现。

安全模型总览

Storm 的安全体系分两层：

• 认证（Authentication）：通过 Thrift 与 SASL 提供可插拔的认证支持，仓库中典型实现是org.apache.storm.security.auth.kerberos.KerberosSaslTransportPlugin（GSSAPI/Kerberos 机制，见 KerberosSaslTransportPlugin.java）。它负责"验证你是谁"。
• 授权（Authorization）：由 Nimbus 的nimbus.authorizer插件决定"你能做什么"。首选插件是SimpleACLAuthorizer，负责"验证你能做什么"。

很多安全特性自 Storm 0.10 起才可用；本文所有配置以当前仓库（master 分支）实现为准。无论是否启用认证授权，官方文档都建议先做好防火墙等 OS 层防护。

防火墙与 OS 层安全

在开启形式化认证/授权之前，可以通过配置操作系统来限制可执行的操作——即使你计划启用认证，这一步也是好习惯。建议启用防火墙，只允许来自集群自身、受信主机与受信服务的入站连接。如果处理的数据敏感，建议用 IPsec 加密集群主机间的所有流量。

Storm 使用的端口清单

注意：Worker 进程端口只是默认值，实际端口以你部署时的supervisor.slots.ports配置为准。与端口相关的配置常量可对照 Config.java 中的DRPC_PORT、DRPC_INVOCATIONS_PORT、STORM_ZOOKEEPER_SUPERACL等定义核实。

以最小权限账号运行进程

从源码结构看，Storm 的 OS 层安全依赖"进程运行在仅具备所需权限的 OS 账号下"。默认情况下，Worker 与 Supervisor 守护进程运行在同一个 OS 账号下（这一行为可通过后文supervisor.run.worker.as.user改变）。因此应避免让 Storm 进程以 root 或特权账号运行。

UI / Logviewer 访问控制

UI 与 logviewer 进程不仅能查看集群状态，还能操作正在运行的拓扑，因此不应暴露给非集群用户。两种常见做法：

方式一：Java Servlet Filter

通过ui.filter/logviewer.filter指定 servlet filter 类进行认证：

ui.filter: "filter.class" ui.filter.params: "param1":"value1" logviewer.filter: "filter.class" logviewer.filter.params: "param1":"value1"

从文档对ui.filter的说明看，它是一个javax.servlet.Filter实例，负责过滤所有进入 UI 的请求并将其映射为"用户"：通常通过修改或包装HttpServletRequest，用getUserPrincipal()返回用户 principal，或用getRemoteUser()返回用户名。

推荐使用 servlet filter 的原因：它可以针对单个拓扑指定谁可以（谁不可以）访问与该拓扑关联的页面，实现拓扑级访问控制。

使用 hadoop-auth 的 AuthenticationFilter

Storm UI（或 logviewer）可以配置为使用 hadoop-auth 的AuthenticationFilter：

ui.filter: "org.apache.hadoop.security.authentication.server.AuthenticationFilter" ui.filter.params: "type": "kerberos" "kerberos.principal": "HTTP/nimbus.witzend.com" "kerberos.keytab": "/vagrant/keytabs/http.keytab" "kerberos.name.rules": "RULE:2:$1@$0s/.*/$MAPRED_USER/ RULE:2:$1@$0s/.*/$HDFS_USER/DEFAULT"

配置前需为 UI 守护进程所在主机创建HTTP/{hostname}形式的 principal（hostname是 UI daemon 运行的主机名）。配置完成后，访问 UI 前必须先执行kinit。

访问 Storm API 的示例：

curl -i --negotiate -u:anyUser -b ~/cookiejar.txt -c ~/cookiejar.txt http://storm-ui-hostname:8080/api/v1/cluster/summary

浏览器端需要开启 SPNEGO 协商：

1. Firefox：进入about:config，搜索network.negotiate-auth.trusted-uris，双击添加值http://storm-ui-hostname:8080。
2. Google Chrome：从命令行启动：google-chrome --auth-server-whitelist="*storm-ui-hostname" --auth-negotiate-delegate-whitelist="*storm-ui-hostname"。
3. IE：将storm-ui-hostname加入受信任网站，并允许对该网站进行协商。

注意事项：在 AD MIT Kerberos 环境中，key 的大小大于默认 UI Jetty 服务器请求头大小，因此务必在storm.yaml中把ui.header.buffer.bytes设为65536。

方式二：代理前置（local 反向代理）

另一种做法是只让 UI/logviewer 端口接受来自 localhost 的连接，在前面用 Apache httpd 等 Web 服务器做认证/授权并反向代理到 Storm 进程。要让这种方式生效，UI 进程的storm.yaml中logviewer.port要设为代理的端口，而 logviewer 自身必须设为它们将要绑定的真实端口。

UI / DRPC SSL

UI 与 DRPC 都支持配置 SSL（生成 keystore 与证书是用户在此步骤之前自行完成的工作）。

UI 的 HTTPS 配置

在storm.yaml中设置：

1. ui.https.port
2. ui.https.keystore.type（例如"jks"）
3. ui.https.keystore.path（例如"/etc/ssl/storm_keystore.jks"）
4. ui.https.keystore.password（keystore 密码）
5. ui.https.key.password（私钥密码）

可选配置：

1. ui.https.truststore.path（例如"/etc/ssl/storm_truststore.jks"）
2. ui.https.truststore.password（truststore 密码）
3. ui.https.truststore.type（例如"jks"）

启用双向认证（2-way authentication）：

1. ui.https.want.client.auth（设为 true 时，服务端请求客户端证书认证，但即使客户端未提供认证也保持连接）
2. ui.https.need.client.auth（设为 true 时，服务端强制要求客户端提供认证）

DRPC 的 HTTPS 配置

与 UI 类似，配置 DRPC SSL：

1. drpc.https.port
2. drpc.https.keystore.type（例如"jks"）
3. drpc.https.keystore.path（例如"/etc/ssl/storm_keystore.jks"）
4. drpc.https.keystore.password（keystore 密码）
5. drpc.https.key.password（私钥密码）

可选配置：

1. drpc.https.truststore.path
2. drpc.https.truststore.password
3. drpc.https.truststore.type

双向认证：

1. drpc.https.want.client.auth
2. drpc.https.need.client.auth

本地测试 SSL 证书生成脚本

keyalg必须设置为RSA。按提示填入取值与密码：

#!/bin/bash DIR=/Users/user/certs/dir/ keytool -keystore $DIR/server.keystore.jks -alias localhost -validity 365 -keyalg RSA -genkey openssl req -new -x509 -keyout $DIR/ca-key -out $DIR/ca-cert -days 365 keytool -keystore $DIR/server.truststore.jks -alias CARoot -import -file $DIR/ca-cert keytool -keystore $DIR/client.truststore.jks -alias CARoot -import -file $DIR/ca-cert keytool -keystore $DIR/server.keystore.jks -alias localhost -certreq -file $DIR/cert-file openssl x509 -req -CA $DIR/ca-cert -CAkey $DIR/ca-key -in $DIR/cert-file -out $DIR/cert-signed -days 365 -CAcreateserial -passin pass:test12 keytool -keystore $DIR/server.keystore.jks -alias CARoot -import -file $DIR/ca-cert keytool -keystore $DIR/server.keystore.jks -alias localhost -import -file $DIR/cert-signed

Authentication（Kerberos）

Storm 通过 Thrift 与 SASL 提供可插拔的认证支持，本文以 Kerberos 为例（大数据项目中最常见的方案）。搭建 KDC 并在每个节点配置 Kerberos 不在本文范围内，默认读者已完成。

创建 headless Principal 与 keytab

每个 ZooKeeper Server、Nimbus 和 DRPC server 都需要一个 service principal，按惯例包含其运行主机的 FQDN。注意 ZooKeeper 用户必须是zookeeper。Supervisor 和 UI 也需要一个用于运行的 principal，但由于它们是出站连接，不需要 service principal。

示例（细节依 KDC 与 OS 而异）：

# ZooKeeper（ZK ensemble 中每台机器都需要一个） sudo kadmin.local -q 'addprinc zookeeper/zk1.example.com@STORM.EXAMPLE.COM' sudo kadmin.local -q "ktadd -k /tmp/zk.keytab zookeeper/zk1.example.com@STORM.EXAMPLE.COM" # Nimbus 和 DRPC sudo kadmin.local -q 'addprinc storm/storm.example.com@STORM.EXAMPLE.COM' sudo kadmin.local -q "ktadd -k /tmp/storm.keytab storm/storm.example.com@STORM.EXAMPLE.COM" # 所有 UI、logviewer 和 Supervisor sudo kadmin.local -q 'addprinc storm@STORM.EXAMPLE.COM' sudo kadmin.local -q "ktadd -k /tmp/storm.keytab storm@STORM.EXAMPLE.COM"

将 keytab 分发到相应主机，并设置 FS 权限，只允许运行 ZK 或 storm 的 headless 用户访问。

Storm Kerberos 配置

Storm 与 ZooKeeper 都通过 jaas 配置文件登录，每个 jaas 文件可有多个 section，对应不同的接口。要启用 Kerberos 认证，在storm.yaml中设置：

storm.thrift.transport: "org.apache.storm.security.auth.kerberos.KerberosSaslTransportPlugin" java.security.auth.login.config: "/path/to/jaas.conf"

Nimbus 和 supervisor 进程还会连接 ZooKeeper（ZK），如需让它们用 Kerberos 与 ZK 认证，需在 nimbus、ui、supervisor 的 childopts 中追加：

-Djava.security.auth.login.config=/path/to/jaas.conf

基于默认 childopts 的示例：

nimbus.childopts: "-Xmx1024m -Djava.security.auth.login.config=/path/to/jaas.conf" ui.childopts: "-Xmx768m -Djava.security.auth.login.config=/path/to/jaas.conf" supervisor.childopts: "-Xmx256m -Djava.security.auth.login.config=/path/to/jaas.conf"

jaas.conf 的四个 Section

各 section 的用途如下：

• StormServer：供 nimbus 与 DRPC 节点使用，supervisor 节点可省略；
• StormClient：供所有想与 nimbus 通信的 Storm 客户端使用（包括 ui、logviewer、supervisor）；网关（gateway）上也会使用，但结构略有不同；
• Client：供想与 ZooKeeper 通信的进程使用，通常只需在 nimbus 与 supervisor 上配置；
• Server：供 ZooKeeper server 使用。

jaas 中存在未使用的 section 没有关系。模板：

StormServer { com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true keyTab="$keytab" storeKey=true useTicketCache=false principal="$principal"; }; StormClient { com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true keyTab="$keytab" storeKey=true useTicketCache=false serviceName="$nimbus_user" principal="$principal"; }; Client { com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true keyTab="$keytab" storeKey=true useTicketCache=false serviceName="zookeeper" principal="$principal"; }; Server { com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true keyTab="$keytab" storeKey=true useTicketCache=false principal="$principal"; };

基于前面生成的 keytab 的具体示例：

StormServer { com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true keyTab="/keytabs/storm.keytab" storeKey=true useTicketCache=false principal="storm/storm.example.com@STORM.EXAMPLE.COM"; }; StormClient { com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true keyTab="/keytabs/storm.keytab" storeKey=true useTicketCache=false serviceName="storm" principal="storm@STORM.EXAMPLE.COM"; }; Client { com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true keyTab="/keytabs/storm.keytab" storeKey=true useTicketCache=false serviceName="zookeeper" principal="storm@STORM.EXAMPLE.COM"; }; Server { com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true keyTab="/keytabs/zk.keytab" storeKey=true useTicketCache=false serviceName="zookeeper" principal="zookeeper/zk1.example.com@STORM.EXAMPLE.COM"; };

仓库中可参考的 JAAS 示例：storm_jaas.conf、zookeeper_jaas.conf、jaas_digest.conf（其中 DIGEST-MD5 机制在KerberosSaslTransportPlugin中作为非 Kerberos 备选）。

Principal 到本地用户名的转换

Nimbus 会把 principal 转换为本地用户名，供其他服务使用。Kerberos 认证下配置：

storm.principal.tolocal: "org.apache.storm.security.auth.KerberosPrincipalToLocal"

此配置只需在 nimbus 上设置，但放在其他节点也无害。对应实现类为 KerberosPrincipalToLocal.java。

还需要从 ZooKeeper 视角告知拓扑 supervisor daemon 与 nimbus daemon 以哪个用户运行：

storm.zookeeper.superACL: "sasl:${nimbus-user}"

其中nimbus-user是 nimbus 用于向 ZooKeeper 认证的 Kerberos 用户。如果 ZooKeeper 剥离了 host 和 realm，这里也要相应地剥离。

ZooKeeper Ensemble（安全 ZK）

安全 ZK 的完整配置超出本文范围，但一般做法是在每个 server 上启用 SASL 认证，并可选地剥离 host 与 realm：

authProvider.1 = org.apache.zookeeper.server.auth.SASLAuthenticationProvider kerberos.removeHostFromPrincipal = true kerberos.removeRealmFromPrincipal = true

启动 ZK server 时在命令行带上 jaas.conf，以便其找到 keytab：

-Djava.security.auth.login.config=/jaas/zk_jaas.conf

网关（Gateways）

理想情况下，终端用户与 Storm 交互前只需执行一次kinit。为此，网关上的默认 jaas.conf 应类似：

StormClient { com.sun.security.auth.module.Krb5LoginModule required doNotPrompt=false useTicketCache=true serviceName="$nimbus_user"; };

终端用户如果有带 keytab 的 headless 账号，可以覆盖此配置。

Authorization：SimpleACLAuthorizer 授权设置

认证解决"你是谁"，授权解决"你能做什么"。Nimbus 的首选授权插件是SimpleACLAuthorizer，配置：

nimbus.authorizer: "org.apache.storm.security.auth.authorizer.SimpleACLAuthorizer"

DRPC 有独立的 authorizer 配置，不要对 DRPC 使用 SimpleACLAuthorizer（详见后文 DRPC 小节）。

源码层面的授权规则

从 SimpleACLAuthorizer.java 的实现看，每个进入的 Thrift 请求都会调用permit()，按以下顺序判定：

1. 管理员：nimbus.admins（admins）与nimbus.admins.groups（adminsGroups）命中的用户/组可执行任意操作，直接放行；
2. Supervisor 用户：nimbus.supervisor.users命中的用户只能执行 supervisor 命令集合（fileDownload、processWorkerMetrics、getSupervisorAssignments、sendSupervisorWorkerHeartbeats）；
3. 普通用户命令：submitTopology、fileUpload、getNimbusConf、getClusterInfo、getLeader、isTopologyNameAllowed、getTopologySummaries、getTopologySummaryByName、getTopologySummary、getSupervisorPageInfo、getOwnerResourceSummaries——当nimbus.users非空时，仅列表内用户（或其所属组在nimbus.groups中）可执行；
4. 拓扑级命令：killTopology、rebalance、activate、deactivate、uploadNewCredentials、setLogConfig、setWorkerProfiler、startProfiling、stopProfiling、dumpProfile、dumpJstack、dumpHeap、debug、sendSupervisorWorkerHeartbeat等，以及只读命令（getTopologyConf、getTopology、getUserTopology、getTopologyInfo、getTopologyPageInfo、getComponentPageInfo等）——通过拓扑自身的topology.users/topology.groups（只读命令还可用topology.readonly.users/topology.readonly.groups）授权。

集群级配置

SimpleACLAuthorizer需要知道 supervisor 用户与所有管理员用户（包括运行 ui daemon 的用户）：

• nimbus.supervisor.users：supervisor 用户；
• nimbus.admins：管理员用户。

两者都可以是完整 Kerberos principal 名，也可以是剥离 host 与 realm 后的用户名。

Log server 有独立的授权配置：

• logs.users
• logs.groups

它们应设置为集群所有节点的管理员用户或组。提交拓扑时，提交者也可以在此列表中加入用户；这些用户/组（加上集群级设置中的用户）将被授予在 logviewer 中访问该拓扑 worker 日志的权限。

对应配置常量在 Config.java 中可查：NIMBUS_ADMINS、NIMBUS_ADMINS_GROUPS、NIMBUS_SUPERVISOR_USERS、NIMBUS_USERS、NIMBUS_GROUPS、TOPOLOGY_USERS、TOPOLOGY_GROUPS、TOPOLOGY_READONLY_USERS、TOPOLOGY_READONLY_GROUPS。

限定可访问集群的用户/组

在SimpleACLAuthorizer下，任何拥有有效 Kerberos ticket 的用户都能部署拓扑或执行 activate、deactivate、访问集群信息等操作。可以通过nimbus.users或nimbus.groups限制：

nimbus.users: - "testuser"

或

nimbus.groups: - "storm"

配置nimbus.users后，只有列表内的用户可以部署拓扑或访问集群；nimbus.groups则把集群访问权限限制在属于这些组的用户。

Supervisors headless 用户与组

为在多租户下保证用户隔离，supervisors 必须在 headless 用户与唯一组下运行：

1. 在所有 supervisor 主机上添加选定的 headless 用户；
2. 创建唯一组，并将其设为 supervisor 节点上 headless 用户的主组；
3. 然后在 storm 中为这些 supervisor 节点设置相应属性。

多租户调度器（Multitenant Scheduler）

为更好地支持多租户，Storm 提供了独立调度器，启用配置：

storm.scheduler: "org.apache.storm.scheduler.multitenant.MultitenantScheduler"

注意：该调度器的许多特性依赖 Storm 认证。没有认证，调度器就不知道用户是谁，无法正确隔离拓扑。对应实现为 MultitenantScheduler.java。

多租户调度器的目标有两个：隔离拓扑之间、限制单个用户在整个集群可占用的总资源。配置可通过storm.yaml或独立配置文件multitenant-scheduler.yaml（放在与storm.yaml相同的目录）设置。推荐使用后者，因为更新它无需重启 nimbus。

目前只有一个配置项：

• multitenant.scheduler.user.pools：从用户名到该用户拓扑可保证使用的最大节点数的映射。

示例：

multitenant.scheduler.user.pools: "evans": 10 "derek": 10

如果集群使用资源感知调度器（ResourceAwareScheduler），用户资源池的配置形态可参考 user-resource-pools-example.yaml（按 cpu/memory 维度划分用户池）。

以提交拓扑的用户身份运行 Worker

默认情况下，Storm 以运行 supervisor 的用户身份运行 worker，这对安全不理想。要让 Storm 以启动拓扑的用户身份运行：

supervisor.run.worker.as.user: true

要使 Storm 真正安全，还需正确配置以下文件：

• worker-launcher可执行程序：允许 supervisor 以不同用户身份启动 worker。它必须由root 拥有，组设置为只有 supervisor headless 用户所在的组，权限为八进制6550。
• worker-launcher.cfg（通常位于/etc/storm）：

storm.worker-launcher.group=$(worker_launcher_group) min.user.id=$(min_user_id)

其中worker_launcher_group是 supervisor 用户所在的同一个组，min.user.id设为系统上第一个真实用户 id。该配置文件也必须由 root 拥有，且不允许 group/world 写权限。Worker-launcher 的 C 实现位于 storm-core/src/native/worker-launcher/impl，SUPERVISOR_RUN_WORKER_AS_USER与 worker-launcher 路径常量同样定义在 Config.java。

Storm-Netty 认证

Worker 之间 Netty 连接的认证默认关闭，可在集群级或按拓扑设置。开启后任何未授权消息都无法被处理：

storm.messaging.netty.authentication: true

用户模拟（Impersonating a User）

Storm 客户端可以代表另一个用户提交请求。例如userX提交了一个 Oozie 工作流，工作流执行过程中oozie用户想代表userX提交拓扑，可以借助模拟特性：

• 使用StormSubmitter.submitTopologyAsAPI 以其他用户身份提交拓扑；
• 或者使用NimbusClient.getConfiguredClientAs获取其他用户身份的 nimbus client，执行 kill/rebalance/activate/deactivate 等任何 nimbus 操作。

为确保只有授权用户可以模拟他人，nimbus 需启动nimbus.impersonation.authorizer为org.apache.storm.security.auth.authorizer.ImpersonationAuthorizer：

nimbus.impersonation.authorizer: org.apache.storm.security.auth.authorizer.ImpersonationAuthorizer nimbus.impersonation.acl: impersonating_user1: hosts: [comma separated list of hosts from which impersonating_user1 is allowed to impersonate other users] groups: [comma separated list of groups whose users impersonating_user1 is allowed to impersonate] impersonating_user2: hosts: [comma separated list of hosts from which impersonating_user2 is allowed to impersonate other users] groups: [comma separated list of groups whose users impersonating_user2 is allowed to impersonate]

源码层面的判定逻辑

ImpersonationAuthorizer.java 的permit()逻辑显示：

• 非模拟请求（context.isImpersonating()为假）直接放行；
• 模拟请求要求nimbus.impersonation.acl中存在模拟者（principal 或本地用户）的条目，否则拒绝；
• 模拟者必须从授权主机发起（匹配hosts列表，支持通配符*，同时匹配 canonical hostname、hostname 与 IP）；
• 被模拟用户必须属于授权组之一（groups列表同样支持*通配）。

Oozie 场景示例

nimbus.impersonation.acl: oozie: hosts: [oozie-host1, oozie-host2, 127.0.0.1] groups: [some-group-that-userX-is-part-of]

自动凭证推送与续期（Automatic Credentials Push and Renewal）

单个拓扑可以向 worker 推送凭证（tickets 与 tokens）以访问安全服务，但对所有用户暴露这一机制很痛苦。常见做法是用插件填充凭证、在另一端把凭证解包进 java Subject，并让 Nimbus 在需要时续期。相关配置：

• topology.auto-credentials：一组 java 插件（必须实现IAutoCredentials接口），在网关填充凭证、在 worker 端解包。在 Kerberos 安全集群上默认应指向org.apache.storm.security.auth.kerberos.AutoTGT。nimbus.credential.renewers.classes也应设为该值，以便 Nimbus 定期代表用户续期 TGT；
• nimbus.credential.renewers.freq.secs：控制续期器多久轮询一次是否需要续期，默认值一般够用。

此外，Nimbus 本身可以在拓扑提交时替用户获取凭证：

• nimbus.autocredential.plugins.classes：一组全限定类名，必须实现INimbusCredentialPlugin。拓扑提交时 Nimbus 会调用所有已配置实现的populateCredentials方法。应配合topology.auto-credentials与nimbus.credential.renewers.classes使用，这样凭证能在 worker 端填充、Nimbus 能自动续期。目前有 AutoHDFS 与 AutoHBase 两个示例：为拓扑提交者自动填充 hdfs/hbase delegation token，避免在所有可能的 worker 主机上分发 keytab。

拓扑大小限制

默认情况下 Storm 允许提交任意大小的拓扑，但 ZooKeeper 等组件对拓扑大小有限制。以下配置可限制拓扑的最大规模：

日志清理（Log Cleanup）

Logviewer daemon 现在也负责清理已死拓扑的旧日志文件：

DRPC 授权

DRPC 有独立的授权机制，不要使用 SimpleACLAuthorizer。仓库提供可参考的示例配置 drpc-auth-acl.yaml.example，其形态如下（按需替换函数名与用户名）：

drpc.authorizer.acl: "functionName1": "client.users": - "alice" - "bob" "invocation.user": "bob" "functionName2": "client.users": - "alice"

即对每个 DRPC 函数，通过client.users限定可发起客户端操作的用户，通过invocation.user限定可执行 invocation 操作的用户。相关配置常量包括DRPC_AUTHORIZER_ACL、DRPC_AUTHORIZER_ACL_FILENAME、DRPC_AUTHORIZER_ACL_STRICT（见 Config.java）。实现类为org.apache.storm.security.auth.authorizer.DRPCSimpleACLAuthorizer（DRPCSimpleACLAuthorizer.java，并有配套单测 DRPCSimpleACLAuthorizerTest.java），DRPC 的 SSL 与 Kerberos 配置则与前述 UI/Nimbus 方案一致。

测试与验证

仓库中包含与安全相关的集成测试与单元测试，可作配置正确性的参照：

• AuthTest.java：认证/授权插件的服务端测试；
• SimpleACLAuthorizerTest.java：验证 SimpleACLAuthorizer 的 permit 判定；
• DRPCSimpleACLAuthorizerTest.java：DRPC ACL 授权测试；
• StormCluster.java：集成测试中对安全配置的封装。

开启认证授权后，建议按"防火墙端口最小化 → UI 访问控制 → HTTPS → Kerberos 认证 → 授权 ACL → 多租户隔离 → 用户模拟 → 自动凭证"的顺序逐步验证，每步通过后再进入下一步，避免多因素叠加导致排障困难。

• 后端
• 大数据