尧图网站建设 
大数据流处理后端【免费下载链接】stormApache Storm项目地址https://gitcode.com/gh_mirrors/storm6/storm点击查看免费下载本文基于 Apache Storm 官方安全文档仓库根目录 SECURITY.md并结合 conf/defaults.yaml 默认配置与 storm-client 安全插件源码编写。默认情况下Storm 的认证与授权全部关闭集群安全需要按本文档逐层开启读完本文你将掌握 Storm 的端口清单与网络层隔离、UI/Logviewer 的过滤器与 SSL、基于 Kerberos 的 Thrift/SASL 认证链路、SimpleACLAuthorizer 授权模型、多租户调度与 worker 进程用户隔离以及凭证自动推送与拓扑规模限制等完整加固方案。1. 安全模型概述Apache Storm 提供一整套可插拔的安全配置能力用于加固集群。默认状态下所有认证Authentication与授权Authorization都是关闭的storm.thrift.transport的默认值是org.apache.storm.security.auth.SimpleTransportPlugin见 conf/defaults.yaml即不做任何身份校验。你可以在需要时逐层开启防火墙 / OS 层安全不开启认证授权时靠系统级网络限制保证集群安全UI / Logviewer 访问控制通过 servlet 过滤器或反向代理做 Web 层认证Kerberos 认证通过 Thrift SASL 实现 Nimbus / Supervisor / DRPC / ZooKeeper 之间的身份认证授权插件SimpleACLAuthorizer控制谁能对集群执行什么操作ImpersonationAuthorizer控制用户模拟数据面安全worker 间 Netty 连接鉴权、worker 进程按提交者用户运行、SSL/TLS 加密。另外关于 Storm 认为哪些属于安全漏洞的假设、信任边界与范围请先阅读官方 Apache Storm Security Model在提交安全问题时建议先读它。2. 防火墙 / OS 层安全即使不开启正式的认证与授权也可以通过操作系统限制来获得一个相对安全的集群。这通常需要配置防火墙、限制网络访问、只允许集群内部和可信主机/服务之间的连接。即便计划开启 Auth也建议做好 OS 层加固。如果集群处理的数据敏感还可在集群主机之间配置 IPsec 加密所有流量。具体 OS 配置细节因发行版而异超出本文范围。2.1 Storm 使用的端口清单加固的第一步是明确哪些端口需要暴露给谁。下表来自 SECURITY.md端口默认值与 conf/defaults.yaml 中的配置一一对应默认端口Storm 配置项客户端主机/进程服务端2181storm.zookeeper.portNimbus、Supervisor、Worker 进程ZooKeeper6627nimbus.thrift.portStorm 客户端、Supervisor、UINimbus6628supervisor.thrift.portNimbusSupervisor8080ui.port客户端 Web 浏览器UI8000logviewer.port客户端 Web 浏览器Logviewer3772drpc.port外部 DRPC 客户端DRPC3773drpc.invocations.portWorker 进程DRPC3774drpc.http.port外部 HTTP DRPC 客户端DRPC670{0,1,2,3}supervisor.slots.portsWorker 进程Worker 进程注意worker 端口6700~6703只是默认值conf/defaults.yaml 中以列表形式定义实际端口随部署而异。建议防火墙只放行上述端口且来源仅限集群自身与受信任主机。2.2 UI / Logviewer 访问控制UI 与 Logviewer 进程不仅能查看集群状态还能操纵正在运行中的拓扑因此一般不应直接暴露给集群用户之外的人。通常需要某种形式的认证典型做法有方式一Java servlet 过滤器ui.filter: filter.class ui.filter.params: param1:value1 logviewer.filter: filter.class logviewer.filter.params: param1:value1默认值均为null见 conf/defaults.yaml 与logviewer.filter。方式二反向代理将 UI/Logviewer 端口限制为仅接受本机连接再用 Apache httpd 等 Web 服务器做认证/授权并反向代理到 Storm 进程。此时 UI 进程storm.yaml中的logviewer.port要设为代理端口而各 logviewer 进程要设为自身实际绑定的端口。servlet 过滤器更受推荐因为它允许每个拓扑单独指定谁能谁不能访问与该拓扑相关的页面——这与SimpleACLAuthorizer结合topology.users/topology.groups的逐拓扑授权模型是一致的。使用 hadoop-auth 的 AuthenticationFilterStorm UI或 Logviewer可直接复用 hadoop-auth 的AuthenticationFilter做 Kerberos SPNEGO 认证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}主体hostname 即 UI 守护进程所在主机名。配置完成后访问 UI 前必须先执行kinit。启用后可用如下命令访问 Storm 的 REST APIcurl -i --negotiate -u:anyUser -b ~/cookiejar.txt -c ~/cookiejar.txt http://storm-ui-hostname:8080/api/v1/cluster/summary各浏览器启用 SPNEGO 协商的方式Firefox进入about:config搜索network.negotiate-auth.trusted-uris双击后添加值http://storm-ui-hostname:8080Google Chrome命令行启动参数google-chrome --auth-server-whitelist*storm-ui-hostname --auth-negotiate-delegate-whitelist*storm-ui-hostnameIE将storm-ui-hostname加入受信任网站并允许对该网站进行协商。注意Caution在 AD MIT Kerberos 环境下Kerberos 票据的 key size 大于 UI Jetty 服务器默认的请求头大小需要在storm.yaml中把ui.header.buffer.bytes设置为 65536默认值仅为 4096见 conf/defaults.yaml否则 UI 请求可能因请求头过大而失败。此问题详见 STORM-633。3. UI / DRPC 的 SSL 配置UI 与 DRPC 都支持 SSL。生成含正确密钥与证书的 keystore 需由用户提前完成。3.1 UI 启用 HTTPS在storm.yaml中设置以下配置ui.https.portHTTPS 监听端口ui.https.keystore.type例jksui.https.keystore.path例/etc/ssl/storm_keystore.jksui.https.keystore.passwordkeystore 密码ui.https.key.password私钥密码可选配置ui.https.truststore.path例/etc/ssl/storm_truststore.jksui.https.truststore.passwordtruststore 密码ui.https.truststore.type例jks双向认证mTLS配置ui.https.want.client.auth设为 true 时服务端请求客户端证书认证但即使客户端未提供认证也保持连接ui.https.need.client.auth设为 true 时服务端强制要求客户端提供认证否则拒绝连接。3.2 DRPC 启用 HTTPS与 UI 配置结构完全一致仅配置项前缀不同drpc.https.portdrpc.https.keystore.type例jksdrpc.https.keystore.path例/etc/ssl/storm_keystore.jksdrpc.https.keystore.passwordkeystore 密码drpc.https.key.password私钥密码可选配置drpc.https.truststore.path例/etc/ssl/storm_truststore.jksdrpc.https.truststore.passwordtruststore 密码drpc.https.truststore.type例jks双向认证配置drpc.https.want.client.authdrpc.https.need.client.auth在 conf/defaults.yaml 中可以看到drpc.https.port默认为-1即关闭drpc.https.keystore.type默认为JKSdrpc.https.keystore.password默认为空——需要你在storm.yaml中显式覆盖。本地测试 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流程先生成服务器 keystore 与自签名 CA → 将 CA 导入 server/client 两个 truststore → 用服务器 keystore 生成 CSR → 用 CA 签名 CSR → 最后把 CA 与签名证书依次导入服务器 keystore。生产环境请替换为真实的 CA 签发证书。4. Kerberos 认证Storm 通过 Thrift 与 SASL 提供可插拔的认证支持。文档以 Kerberos 为例大数据生态最常见的方案。KDC 的搭建与各节点 Kerberos 配置不在本文范围默认认为已就绪。4.1 创建无头主体Headless Principals与 keytab每个 ZooKeeper Server、Nimbus、DRPC Server 都需要一个服务主体按惯例包含其运行主机的 FQDN。注意 ZooKeeper 用户必须是zookeeper。Supervisor 与 UI 也需要一个用于运行的主体但它们是发起连接的一方不需要服务主体。# ZooKeeperZK ensemble 中每台机器都需要一个 sudo kadmin.local -q addprinc zookeeper/zk1.example.comSTORM.EXAMPLE.COM sudo kadmin.local -q ktadd -k /tmp/zk.keytab zookeeper/zk1.example.comSTORM.EXAMPLE.COM # Nimbus 和 DRPC sudo kadmin.local -q addprinc storm/storm.example.comSTORM.EXAMPLE.COM sudo kadmin.local -q ktadd -k /tmp/storm.keytab storm/storm.example.comSTORM.EXAMPLE.COM # 所有 UI、Logviewer 和 Supervisor sudo kadmin.local -q addprinc stormSTORM.EXAMPLE.COM sudo kadmin.local -q ktadd -k /tmp/storm.keytab stormSTORM.EXAMPLE.COM务必把 keytab 分发到对应主机并设置文件系统权限确保只有运行 ZK 或 Storm 的无头用户能读取。4.2 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.confKerberos 传输插件实现在 KerberosSaslTransportPlugin.java替换默认的SimpleTransportPlugin后Nimbus 的 Thrift 服务即要求 SASL 认证。Nimbus 与 Supervisor 进程还要连接 ZooKeeper需要给 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以上堆内存值与 conf/defaults.yaml、conf/defaults.yaml、conf/defaults.yaml 的默认 childopts 对应你只需在其后追加 login config 参数。storm 节点的 jaas.conf 应包含以下 section仓库中 conf/storm_jaas.conf 提供了带占位符的模板StormServer供 nimbus 与 DRPC 节点使用Supervisor 节点无需包含StormClient供所有要与 nimbus 通信的 Storm 客户端使用包括 ui、logviewer、supervisor网关gateway上也要用该 section但结构略有不同Client供要与 ZooKeeper 通信的进程使用实际上只需要在 nimbus 和 supervisor 上包含Server供 ZooKeeper 服务端使用。jaas 中包含未使用的 section 没有问题。模板StormServer { com.sun.security.auth.module.Krb5LoginModule required useKeyTabtrue keyTab$keytab storeKeytrue useTicketCachefalse principal$principal; }; StormClient { com.sun.security.auth.module.Krb5LoginModule required useKeyTabtrue keyTab$keytab storeKeytrue useTicketCachefalse serviceName$nimbus_user principal$principal; }; Client { com.sun.security.auth.module.Krb5LoginModule required useKeyTabtrue keyTab$keytab storeKeytrue useTicketCachefalse serviceNamezookeeper principal$principal; }; Server { com.sun.security.auth.module.Krb5LoginModule required useKeyTabtrue keyTab$keytab storeKeytrue useTicketCachefalse principal$principal; };基于上文生成的 keytab 的完整示例StormServer { com.sun.security.auth.module.Krb5LoginModule required useKeyTabtrue keyTab/keytabs/storm.keytab storeKeytrue useTicketCachefalse principalstorm/storm.example.comSTORM.EXAMPLE.COM; }; StormClient { com.sun.security.auth.module.Krb5LoginModule required useKeyTabtrue keyTab/keytabs/storm.keytab storeKeytrue useTicketCachefalse serviceNamestorm principalstormSTORM.EXAMPLE.COM; }; Client { com.sun.security.auth.module.Krb5LoginModule required useKeyTabtrue keyTab/keytabs/storm.keytab storeKeytrue useTicketCachefalse serviceNamezookeeper principalstormSTORM.EXAMPLE.COM; }; Server { com.sun.security.auth.module.Krb5LoginModule required useKeyTabtrue keyTab/keytabs/zk.keytab storeKeytrue useTicketCachefalse serviceNamezookeeper principalzookeeper/zk1.example.comSTORM.EXAMPLE.COM; };Nimbus 还会把主体principal翻译成本地用户名供其他服务使用。Kerberos 认证下配置storm.principal.tolocal: org.apache.storm.security.auth.KerberosPrincipalToLocal实现在 KerberosPrincipalToLocal.javaconf/defaults.yaml 的默认值是DefaultPrincipalToLocal。此项只在 nimbus 上必须其它节点配置也无害。还需要告诉拓扑从 ZooKeeper 的视角看supervisor 守护进程与 nimbus 守护进程以谁的身份运行storm.zookeeper.superACL: sasl:${nimbus-user}其中nimbus-user是 nimbus 向 ZooKeeper 认证时使用的 Kerberos 用户。如果 ZooKeeper 会剥离 host 与 realm那么这里也要对应地剥离。4.3 ZooKeeper Ensemble 加固安全 ZK 的完整细节超出本文范围但通常需要在每台服务器上启用 SASL 认证并可选择剥离 host 与 realmauthProvider.1 org.apache.zookeeper.server.auth.SASLAuthenticationProvider kerberos.removeHostFromPrincipal true kerberos.removeRealmFromPrincipal true并在启动 ZK 服务端的命令行中加入 jaas.conf使其能找到 keytab-Djava.security.auth.login.config/jaas/zk_jaas.conf仓库 conf/zookeeper_jaas.conf 提供了 ZK 侧 JAAS 模板可参考。4.4 网关Gateways理想情况下最终用户只需在执行与 Storm 交互前运行一次kinit。为此网关上的默认 jaas.conf 应为StormClient { com.sun.security.auth.module.Krb5LoginModule required doNotPromptfalse useTicketCachetrue serviceName$nimbus_user; };如果用户使用拥有 keytab 的无头账号也可以覆盖此配置。5. 授权设置Authorization认证解决“你是谁”的问题授权解决“你能做什么”的问题二者缺一不可。5.1 SimpleACLAuthorizerNimbus 推荐授权插件Nimbus 首选的授权插件是SimpleACLAuthorizernimbus.authorizer: org.apache.storm.security.auth.authorizer.SimpleACLAuthorizerDRPC 有独立的授权配置不要对 DRPC 使用 SimpleACLAuthorizer。从源码看SimpleACLAuthorizer.java 把 Nimbus 的 Thrift 操作分为几类L39-L83userCommandssubmitTopology、fileUpload、createStateInZookeeper、getNimbusConf、listBlobs、getClusterInfo、getTopologyHistory、getLeader、getTopologySummaries等通用集群操作supervisorCommandsfileDownload、processWorkerMetrics、getSupervisorAssignments、sendSupervisorWorkerHeartbeats等topoReadOnlyCommandsgetTopologyConf、getTopologyInfo、getTopologyPageInfo、getComponentPageInfo、getLogConfig等只读操作topoCommandskillTopology、rebalance、activate、deactivate、uploadNewCredentials、setLogConfig等写操作。permit()L141-L184的判定顺序为管理员nimbus.admins/nimbus.admins.groups放行一切 → supervisor 用户仅放行 supervisorCommands → 普通用户按 userCommands 与 topoCommands 分别校验其中拓扑级操作还会结合topology.users/topology.groups只读操作额外参考topology.readonly.users/topology.readonly.groups逐拓扑授权。SimpleACLAuthorizer 需要知道 supervisor 用户是谁以及所有管理员用户包括运行 ui 守护进程的用户nimbus.supervisor.userssupervisor 用户列表nimbus.admins管理员用户列表。两者均可使用完整的 Kerberos 主体名或剥离 host 与 realm 后的用户名。日志服务器有自己的授权配置logs.users与logs.groups应设为集群所有节点的管理员用户/组。拓扑提交时提交者还可以在拓扑配置中额外指定用户/组配合集群级设置这些用户/组将被授予在 logviewer 中查看该拓扑 worker 日志的权限——这正是 SimpleACLAuthorizer.java 中checkTopoPermission对topology.users/topology.groups的处理逻辑。5.2 限制谁能访问 Storm默认情况下任何持有有效 Kerberos 票据的用户都可以部署拓扑或执行 activate/deactivate、查看集群信息等操作。可以通过在storm.yaml中指定nimbus.users或nimbus.groups来限制nimbus.users: - testuser或nimbus.groups: - storm配置了nimbus.users后只有列表内的用户能部署拓扑或访问集群nimbus.groups则限制为属于这些组的用户。源码中L164-L170只有在nimbus.users与nimbus.groups同时为空时才视为未做限制。5.3 Supervisor 无头用户与用户组设置多租户场景下为保证用户隔离supervisor 必须运行在无头用户headless user和唯一用户组之下在所有 supervisor 主机上添加所选的无头用户创建唯一用户组并把它设为 supervisor 节点上无头用户的主组在这些 supervisor 节点上为 storm 设置相应属性。5.4 多租户调度器Multitenant Scheduler为更好地支持多租户Storm 提供了专门的新调度器storm.scheduler: org.apache.storm.scheduler.multitenant.MultitenantScheduler实现位于 MultitenantScheduler.java。注意该调度器的很多特性依赖 Storm 认证——没有认证调度器就不知道用户是谁也就无法正确隔离拓扑。多租户调度器的目标是隔离不同拓扑同时允许限制单个用户在整个集群中占用的总资源。调度器配置可以通过storm.yaml或独立配置文件multitenant-scheduler.yaml应放在与storm.yaml相同的目录设置推荐使用multitenant-scheduler.yaml因为它可以在不重启 nimbus 的情况下热更新。目前只有一个配置项multitenant.scheduler.user.pools从用户名到该用户拓扑可保证使用的最大节点数的映射。例如multitenant.scheduler.user.pools: evans: 10 derek: 10仓库 conf/user-resource-pools-example.yaml 提供了用户资源池的示例配置可参考。5.5 以提交拓扑的用户身份运行 worker 进程默认情况下Storm 以运行 supervisor 的用户身份运行 worker这对安全不理想。要改为以启动拓扑的用户身份运行supervisor.run.worker.as.user: true默认值为false见 conf/defaults.yaml。启用后还需正确配置以下文件worker-launcher是一个特殊程序允许 supervisor 以不同用户身份启动 worker。它需要属主为 root、属组为只有 supervisor 无头用户所在的组且权限为6550octal。另有一个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且不能有 world 或 group 写权限。相关实现可参考仓库 storm-core/src/native/worker-launcher 目录下的 worker-launcher 原生程序源码。5.6 Storm-Netty 认证worker 之间 Netty 连接上的认证默认是关闭的conf/defaults.yaml 中storm.messaging.netty.authentication默认为false。可以在集群级或按拓扑开启开启后将阻止任何未授权消息被处理storm.messaging.netty.authentication: true5.7 用户模拟ImpersonationStorm 客户端可以代表另一个用户提交请求。例如userX提交一个 oozie 工作流工作流执行过程中用户oozie想代表userX提交拓扑就可以利用模拟impersonation特性。代表其他用户提交拓扑可使用StormSubmitter.submitTopologyAsAPI或者使用NimbusClient.getConfiguredClientAs以其他用户的身份获取 nimbus 客户端进而执行任意 nimbus 操作如 kill/rebalance/activate/deactivate。要确保只有授权用户能执行模拟应以nimbus.impersonation.authorizer启动 nimbus设置为org.apache.storm.security.auth.authorizer.ImpersonationAuthorizer。该授权器使用nimbus.impersonation.acl作为授权 ACL。从 ImpersonationAuthorizer.java 的prepare()L41-L46可以看到ACL 是模拟用户 → {hosts、groups}的两层映射结构。以下是支持模拟的 nimbus 配置示例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]为支持 oozie 场景可提供如下配置nimbus.impersonation.acl: oozie: hosts: [oozie-host1, oozie-host2, 127.0.0.1] groups: [some-group-that-userX-is-part-of]即只允许来自 oozie 主机含 127.0.0.1的oozie用户模拟some-group-that-userX-is-part-of组中的用户。6. 凭证自动推送与续期单个拓扑可以自行把凭证票据与令牌推送给 worker以便访问受保护的服务——但对所有用户暴露这一能力是负担。在常见场景下插件可以填充凭证 → 在另一端解包成 java Subject → 需要时由 Nimbus 续期。相关配置topology.auto-credentialsjava 插件列表所有插件必须实现IAutoCredentials接口在网关上填充凭证并在 worker 侧解包。Kerberos 安全集群上默认应指向org.apache.storm.security.auth.kerberos.AutoTGTnimbus.credential.renewers.classes也应设为此值以便 Nimbus 定期代表用户续期 TGT。nimbus.credential.renewers.freq.secs控制续期器多久轮询一次以判断是否有需要续期的凭证默认值600 秒见 conf/defaults.yaml通常够用。从 AutoTGT.java 源码看AutoTGT同时实现IAutoCredentials、ICredentialsRenewer与IMetricsRegistrantL42populateCredentials()通过 JAASLoginContext完成登录并取出 Kerberos TGT序列化后以TGT键存入凭证 mapL71-L79worker 侧再由populateSubject()反序列化回Subject续期窗口约为票据生命周期的 80%TICKET_RENEW_WINDOW 0.80f。此外Nimbus 自身也可以代表提交拓扑的用户获取凭证配置方式nimbus.autocredential.plugins.classes完全限定类名列表所有类必须实现INimbusCredentialPlugin。Nimbus 会在拓扑提交时调用所有已配置实现的populateCredentials方法。应与topology.auto-credentials和nimbus.credential.renewers.classes配合使用使凭证能在 worker 侧填充且 Nimbus 能自动续期。目前有两个使用示例AutoHDFS 与 AutoHBase它们为拓扑提交者自动填充 hdfs 与 hbase 的 delegation token这样用户就不必把 keytab 分发到所有可能的 worker 主机上。7. 拓扑规模限制默认允许提交任意大小的拓扑但 ZooKeeper 等组件对拓扑大小存在实际限制。以下配置用于限制拓扑最大规模YAML 配置项说明nimbus.slots.perTopology单个拓扑最多可使用的 slot/worker 数量nimbus.executors.perTopology单个拓扑最多可使用的 executor/线程数量8. 日志清理Logviewer 守护进程还负责清理已死亡拓扑的旧日志文件YAML 配置项说明logviewer.cleanup.age.minsworker 日志必须老到多少分钟按最后修改时间才被认为可清理存活 worker 的日志不会被 logviewer 清理它们由标准日志服务滚动如 0.11 中的 log4j2logviewer.cleanup.interval.secslogviewer 清理 worker 日志的时间间隔秒conf/defaults.yaml 中logviewer.cleanup.age.mins默认值为 10080即 7 天可作为参考基准。9. 配置汇总与实战顺序建议将本文涉及的关键配置按加固层次汇总均写入storm.yaml或对应的独立配置文件层次关键配置说明传输层storm.thrift.transport默认SimpleTransportPlugin开启 Kerberos 时改为KerberosSaslTransportPlugin主体映射storm.principal.tolocal默认DefaultPrincipalToLocalKerberos 时改为KerberosPrincipalToLocalNimbus 授权nimbus.authorizer设为SimpleACLAuthorizer用户模拟nimbus.impersonation.authorizer/nimbus.impersonation.acl设为ImpersonationAuthorizer并配置 ACL集群访问限制nimbus.users/nimbus.groups白名单限制管理员/监管nimbus.admins/nimbus.supervisor.users/logs.users/logs.groups管理员与 supervisor 身份Web 层ui.filter/logviewer.filterhadoop-auth 过滤器或自定义 servlet filter加密ui.https.*/drpc.https.*HTTPS 与可选 mTLSworker 数据面storm.messaging.netty.authenticationNetty 连接鉴权进程隔离supervisor.run.worker.as.user配合 worker-launcher多租户storm.scheduler/multitenant.scheduler.user.poolsMultitenantScheduler规模限制nimbus.slots.perTopology/nimbus.executors.perTopology防止超大拓扑日志生命周期logviewer.cleanup.age.mins/logviewer.cleanup.interval.secs日志清理推荐的加固顺序先做 OS/防火墙层端口隔离 → 再为 UI/Logviewer 配置过滤器与 HTTPS → 搭建 KDC、生成主体与 keytab → 开启 Kerberos 传输Nimbus/DRPC/Supervisor/ZK 的 JAAS 与 superACL→ 配置 SimpleACLAuthorizer 与 ImpersonationAuthorizer → 按需启用 worker-as-user、Netty 认证与多租户调度 → 最后设置拓扑规模上限与日志清理策略。仓库中的 conf/jaas_digest.conf、conf/storm_jaas.conf、conf/zookeeper_jaas.conf 与 conf/storm.yaml.example 可作为落地配置的起点模板。10. 延伸阅读SECURITY.md本文对应的官方安全文档原文conf/defaults.yaml全部配置项默认值端口、childopts、SSL、日志清理等storm-client/src/jvm/org/apache/storm/security/auth/kerberosKerberos 传输插件、AutoTGT、主体映射实现storm-client/src/jvm/org/apache/storm/security/auth/authorizerSimpleACLAuthorizer 与 ImpersonationAuthorizer 实现storm-server/src/main/java/org/apache/storm/scheduler/multitenant/MultitenantScheduler.java多租户调度器实现storm-core/src/native/worker-launcherworker-launcher 原生程序源码docs/SECURITY.mddocs 目录下的安全文档副本docs/STORM-UI-REST-API.mdUI REST APISPNEGO 认证后可访问docs/Distributed-RPC.mdDRPC 协议与端口说明赞分享大数据流处理后端【免费下载链接】stormApache Storm项目地址https://gitcode.com/gh_mirrors/storm6/storm点击查看免费下载相关推荐3分钟完整解锁WeMod专业版Wand-Enhancer纯本地补丁新手指南3分钟完整解锁WeMod专业版Wand Enhancer纯本地补丁新手指南 打开WeMod专业版入口锁在灰色付费墙后面年费又不算便宜。Wand Enhan桌面应用前端如何5分钟掌握Mermaid Live Editor免费在线图表编辑器的终极指南如何5分钟掌握Mermaid Live Editor免费在线图表编辑器的终极指南 你是否曾为创建流程图、时序图或甘特图而烦恼Mermaid Live Edi前端开发者工具数据可视化Apache Druid 安全加固实战TLS 加密、认证授权与权限模型详解Apache Druid 安全加固实战TLS 加密、认证授权与权限模型详解 Apache Druid 默认关闭全部安全特性TLS、认证、授权以降低首次部数据库OLAP大数据后端上一篇Weylus终极多点触控交互系统让你的平板秒变电脑绘图板下一篇Checkmate数据库备份自动化定时任务与恢复演练流程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Apache Storm 集群安全加固实战指南：从防火墙端口到 Kerberos 认证与授权
大数据流处理后端【免费下载链接】stormApache Storm项目地址https://gitcode.com/gh_mirrors/storm6/storm点击查看免费下载本文基于 Apache Storm 官方安全文档仓库根目录 SECURITY.md并结合 conf/defaults.yaml 默认配置与 storm-client 安全插件源码编写。默认情况下Storm 的认证与授权全部关闭集群安全需要按本文档逐层开启读完本文你将掌握 Storm 的端口清单与网络层隔离、UI/Logviewer 的过滤器与 SSL、基于 Kerberos 的 Thrift/SASL 认证链路、SimpleACLAuthorizer 授权模型、多租户调度与 worker 进程用户隔离以及凭证自动推送与拓扑规模限制等完整加固方案。1. 安全模型概述Apache Storm 提供一整套可插拔的安全配置能力用于加固集群。默认状态下所有认证Authentication与授权Authorization都是关闭的storm.thrift.transport的默认值是org.apache.storm.security.auth.SimpleTransportPlugin见 conf/defaults.yaml即不做任何身份校验。你可以在需要时逐层开启防火墙 / OS 层安全不开启认证授权时靠系统级网络限制保证集群安全UI / Logviewer 访问控制通过 servlet 过滤器或反向代理做 Web 层认证Kerberos 认证通过 Thrift SASL 实现 Nimbus / Supervisor / DRPC / ZooKeeper 之间的身份认证授权插件SimpleACLAuthorizer控制谁能对集群执行什么操作ImpersonationAuthorizer控制用户模拟数据面安全worker 间 Netty 连接鉴权、worker 进程按提交者用户运行、SSL/TLS 加密。另外关于 Storm 认为哪些属于安全漏洞的假设、信任边界与范围请先阅读官方 Apache Storm Security Model在提交安全问题时建议先读它。2. 防火墙 / OS 层安全即使不开启正式的认证与授权也可以通过操作系统限制来获得一个相对安全的集群。这通常需要配置防火墙、限制网络访问、只允许集群内部和可信主机/服务之间的连接。即便计划开启 Auth也建议做好 OS 层加固。如果集群处理的数据敏感还可在集群主机之间配置 IPsec 加密所有流量。具体 OS 配置细节因发行版而异超出本文范围。2.1 Storm 使用的端口清单加固的第一步是明确哪些端口需要暴露给谁。下表来自 SECURITY.md端口默认值与 conf/defaults.yaml 中的配置一一对应默认端口Storm 配置项客户端主机/进程服务端2181storm.zookeeper.portNimbus、Supervisor、Worker 进程ZooKeeper6627nimbus.thrift.portStorm 客户端、Supervisor、UINimbus6628supervisor.thrift.portNimbusSupervisor8080ui.port客户端 Web 浏览器UI8000logviewer.port客户端 Web 浏览器Logviewer3772drpc.port外部 DRPC 客户端DRPC3773drpc.invocations.portWorker 进程DRPC3774drpc.http.port外部 HTTP DRPC 客户端DRPC670{0,1,2,3}supervisor.slots.portsWorker 进程Worker 进程注意worker 端口6700~6703只是默认值conf/defaults.yaml 中以列表形式定义实际端口随部署而异。建议防火墙只放行上述端口且来源仅限集群自身与受信任主机。2.2 UI / Logviewer 访问控制UI 与 Logviewer 进程不仅能查看集群状态还能操纵正在运行中的拓扑因此一般不应直接暴露给集群用户之外的人。通常需要某种形式的认证典型做法有方式一Java servlet 过滤器ui.filter: filter.class ui.filter.params: param1:value1 logviewer.filter: filter.class logviewer.filter.params: param1:value1默认值均为null见 conf/defaults.yaml 与logviewer.filter。方式二反向代理将 UI/Logviewer 端口限制为仅接受本机连接再用 Apache httpd 等 Web 服务器做认证/授权并反向代理到 Storm 进程。此时 UI 进程storm.yaml中的logviewer.port要设为代理端口而各 logviewer 进程要设为自身实际绑定的端口。servlet 过滤器更受推荐因为它允许每个拓扑单独指定谁能谁不能访问与该拓扑相关的页面——这与SimpleACLAuthorizer结合topology.users/topology.groups的逐拓扑授权模型是一致的。使用 hadoop-auth 的 AuthenticationFilterStorm UI或 Logviewer可直接复用 hadoop-auth 的AuthenticationFilter做 Kerberos SPNEGO 认证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}主体hostname 即 UI 守护进程所在主机名。配置完成后访问 UI 前必须先执行kinit。启用后可用如下命令访问 Storm 的 REST APIcurl -i --negotiate -u:anyUser -b ~/cookiejar.txt -c ~/cookiejar.txt http://storm-ui-hostname:8080/api/v1/cluster/summary各浏览器启用 SPNEGO 协商的方式Firefox进入about:config搜索network.negotiate-auth.trusted-uris双击后添加值http://storm-ui-hostname:8080Google Chrome命令行启动参数google-chrome --auth-server-whitelist*storm-ui-hostname --auth-negotiate-delegate-whitelist*storm-ui-hostnameIE将storm-ui-hostname加入受信任网站并允许对该网站进行协商。注意Caution在 AD MIT Kerberos 环境下Kerberos 票据的 key size 大于 UI Jetty 服务器默认的请求头大小需要在storm.yaml中把ui.header.buffer.bytes设置为 65536默认值仅为 4096见 conf/defaults.yaml否则 UI 请求可能因请求头过大而失败。此问题详见 STORM-633。3. UI / DRPC 的 SSL 配置UI 与 DRPC 都支持 SSL。生成含正确密钥与证书的 keystore 需由用户提前完成。3.1 UI 启用 HTTPS在storm.yaml中设置以下配置ui.https.portHTTPS 监听端口ui.https.keystore.type例jksui.https.keystore.path例/etc/ssl/storm_keystore.jksui.https.keystore.passwordkeystore 密码ui.https.key.password私钥密码可选配置ui.https.truststore.path例/etc/ssl/storm_truststore.jksui.https.truststore.passwordtruststore 密码ui.https.truststore.type例jks双向认证mTLS配置ui.https.want.client.auth设为 true 时服务端请求客户端证书认证但即使客户端未提供认证也保持连接ui.https.need.client.auth设为 true 时服务端强制要求客户端提供认证否则拒绝连接。3.2 DRPC 启用 HTTPS与 UI 配置结构完全一致仅配置项前缀不同drpc.https.portdrpc.https.keystore.type例jksdrpc.https.keystore.path例/etc/ssl/storm_keystore.jksdrpc.https.keystore.passwordkeystore 密码drpc.https.key.password私钥密码可选配置drpc.https.truststore.path例/etc/ssl/storm_truststore.jksdrpc.https.truststore.passwordtruststore 密码drpc.https.truststore.type例jks双向认证配置drpc.https.want.client.authdrpc.https.need.client.auth在 conf/defaults.yaml 中可以看到drpc.https.port默认为-1即关闭drpc.https.keystore.type默认为JKSdrpc.https.keystore.password默认为空——需要你在storm.yaml中显式覆盖。本地测试 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流程先生成服务器 keystore 与自签名 CA → 将 CA 导入 server/client 两个 truststore → 用服务器 keystore 生成 CSR → 用 CA 签名 CSR → 最后把 CA 与签名证书依次导入服务器 keystore。生产环境请替换为真实的 CA 签发证书。4. Kerberos 认证Storm 通过 Thrift 与 SASL 提供可插拔的认证支持。文档以 Kerberos 为例大数据生态最常见的方案。KDC 的搭建与各节点 Kerberos 配置不在本文范围默认认为已就绪。4.1 创建无头主体Headless Principals与 keytab每个 ZooKeeper Server、Nimbus、DRPC Server 都需要一个服务主体按惯例包含其运行主机的 FQDN。注意 ZooKeeper 用户必须是zookeeper。Supervisor 与 UI 也需要一个用于运行的主体但它们是发起连接的一方不需要服务主体。# ZooKeeperZK ensemble 中每台机器都需要一个 sudo kadmin.local -q addprinc zookeeper/zk1.example.comSTORM.EXAMPLE.COM sudo kadmin.local -q ktadd -k /tmp/zk.keytab zookeeper/zk1.example.comSTORM.EXAMPLE.COM # Nimbus 和 DRPC sudo kadmin.local -q addprinc storm/storm.example.comSTORM.EXAMPLE.COM sudo kadmin.local -q ktadd -k /tmp/storm.keytab storm/storm.example.comSTORM.EXAMPLE.COM # 所有 UI、Logviewer 和 Supervisor sudo kadmin.local -q addprinc stormSTORM.EXAMPLE.COM sudo kadmin.local -q ktadd -k /tmp/storm.keytab stormSTORM.EXAMPLE.COM务必把 keytab 分发到对应主机并设置文件系统权限确保只有运行 ZK 或 Storm 的无头用户能读取。4.2 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.confKerberos 传输插件实现在 KerberosSaslTransportPlugin.java替换默认的SimpleTransportPlugin后Nimbus 的 Thrift 服务即要求 SASL 认证。Nimbus 与 Supervisor 进程还要连接 ZooKeeper需要给 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以上堆内存值与 conf/defaults.yaml、conf/defaults.yaml、conf/defaults.yaml 的默认 childopts 对应你只需在其后追加 login config 参数。storm 节点的 jaas.conf 应包含以下 section仓库中 conf/storm_jaas.conf 提供了带占位符的模板StormServer供 nimbus 与 DRPC 节点使用Supervisor 节点无需包含StormClient供所有要与 nimbus 通信的 Storm 客户端使用包括 ui、logviewer、supervisor网关gateway上也要用该 section但结构略有不同Client供要与 ZooKeeper 通信的进程使用实际上只需要在 nimbus 和 supervisor 上包含Server供 ZooKeeper 服务端使用。jaas 中包含未使用的 section 没有问题。模板StormServer { com.sun.security.auth.module.Krb5LoginModule required useKeyTabtrue keyTab$keytab storeKeytrue useTicketCachefalse principal$principal; }; StormClient { com.sun.security.auth.module.Krb5LoginModule required useKeyTabtrue keyTab$keytab storeKeytrue useTicketCachefalse serviceName$nimbus_user principal$principal; }; Client { com.sun.security.auth.module.Krb5LoginModule required useKeyTabtrue keyTab$keytab storeKeytrue useTicketCachefalse serviceNamezookeeper principal$principal; }; Server { com.sun.security.auth.module.Krb5LoginModule required useKeyTabtrue keyTab$keytab storeKeytrue useTicketCachefalse principal$principal; };基于上文生成的 keytab 的完整示例StormServer { com.sun.security.auth.module.Krb5LoginModule required useKeyTabtrue keyTab/keytabs/storm.keytab storeKeytrue useTicketCachefalse principalstorm/storm.example.comSTORM.EXAMPLE.COM; }; StormClient { com.sun.security.auth.module.Krb5LoginModule required useKeyTabtrue keyTab/keytabs/storm.keytab storeKeytrue useTicketCachefalse serviceNamestorm principalstormSTORM.EXAMPLE.COM; }; Client { com.sun.security.auth.module.Krb5LoginModule required useKeyTabtrue keyTab/keytabs/storm.keytab storeKeytrue useTicketCachefalse serviceNamezookeeper principalstormSTORM.EXAMPLE.COM; }; Server { com.sun.security.auth.module.Krb5LoginModule required useKeyTabtrue keyTab/keytabs/zk.keytab storeKeytrue useTicketCachefalse serviceNamezookeeper principalzookeeper/zk1.example.comSTORM.EXAMPLE.COM; };Nimbus 还会把主体principal翻译成本地用户名供其他服务使用。Kerberos 认证下配置storm.principal.tolocal: org.apache.storm.security.auth.KerberosPrincipalToLocal实现在 KerberosPrincipalToLocal.javaconf/defaults.yaml 的默认值是DefaultPrincipalToLocal。此项只在 nimbus 上必须其它节点配置也无害。还需要告诉拓扑从 ZooKeeper 的视角看supervisor 守护进程与 nimbus 守护进程以谁的身份运行storm.zookeeper.superACL: sasl:${nimbus-user}其中nimbus-user是 nimbus 向 ZooKeeper 认证时使用的 Kerberos 用户。如果 ZooKeeper 会剥离 host 与 realm那么这里也要对应地剥离。4.3 ZooKeeper Ensemble 加固安全 ZK 的完整细节超出本文范围但通常需要在每台服务器上启用 SASL 认证并可选择剥离 host 与 realmauthProvider.1 org.apache.zookeeper.server.auth.SASLAuthenticationProvider kerberos.removeHostFromPrincipal true kerberos.removeRealmFromPrincipal true并在启动 ZK 服务端的命令行中加入 jaas.conf使其能找到 keytab-Djava.security.auth.login.config/jaas/zk_jaas.conf仓库 conf/zookeeper_jaas.conf 提供了 ZK 侧 JAAS 模板可参考。4.4 网关Gateways理想情况下最终用户只需在执行与 Storm 交互前运行一次kinit。为此网关上的默认 jaas.conf 应为StormClient { com.sun.security.auth.module.Krb5LoginModule required doNotPromptfalse useTicketCachetrue serviceName$nimbus_user; };如果用户使用拥有 keytab 的无头账号也可以覆盖此配置。5. 授权设置Authorization认证解决“你是谁”的问题授权解决“你能做什么”的问题二者缺一不可。5.1 SimpleACLAuthorizerNimbus 推荐授权插件Nimbus 首选的授权插件是SimpleACLAuthorizernimbus.authorizer: org.apache.storm.security.auth.authorizer.SimpleACLAuthorizerDRPC 有独立的授权配置不要对 DRPC 使用 SimpleACLAuthorizer。从源码看SimpleACLAuthorizer.java 把 Nimbus 的 Thrift 操作分为几类L39-L83userCommandssubmitTopology、fileUpload、createStateInZookeeper、getNimbusConf、listBlobs、getClusterInfo、getTopologyHistory、getLeader、getTopologySummaries等通用集群操作supervisorCommandsfileDownload、processWorkerMetrics、getSupervisorAssignments、sendSupervisorWorkerHeartbeats等topoReadOnlyCommandsgetTopologyConf、getTopologyInfo、getTopologyPageInfo、getComponentPageInfo、getLogConfig等只读操作topoCommandskillTopology、rebalance、activate、deactivate、uploadNewCredentials、setLogConfig等写操作。permit()L141-L184的判定顺序为管理员nimbus.admins/nimbus.admins.groups放行一切 → supervisor 用户仅放行 supervisorCommands → 普通用户按 userCommands 与 topoCommands 分别校验其中拓扑级操作还会结合topology.users/topology.groups只读操作额外参考topology.readonly.users/topology.readonly.groups逐拓扑授权。SimpleACLAuthorizer 需要知道 supervisor 用户是谁以及所有管理员用户包括运行 ui 守护进程的用户nimbus.supervisor.userssupervisor 用户列表nimbus.admins管理员用户列表。两者均可使用完整的 Kerberos 主体名或剥离 host 与 realm 后的用户名。日志服务器有自己的授权配置logs.users与logs.groups应设为集群所有节点的管理员用户/组。拓扑提交时提交者还可以在拓扑配置中额外指定用户/组配合集群级设置这些用户/组将被授予在 logviewer 中查看该拓扑 worker 日志的权限——这正是 SimpleACLAuthorizer.java 中checkTopoPermission对topology.users/topology.groups的处理逻辑。5.2 限制谁能访问 Storm默认情况下任何持有有效 Kerberos 票据的用户都可以部署拓扑或执行 activate/deactivate、查看集群信息等操作。可以通过在storm.yaml中指定nimbus.users或nimbus.groups来限制nimbus.users: - testuser或nimbus.groups: - storm配置了nimbus.users后只有列表内的用户能部署拓扑或访问集群nimbus.groups则限制为属于这些组的用户。源码中L164-L170只有在nimbus.users与nimbus.groups同时为空时才视为未做限制。5.3 Supervisor 无头用户与用户组设置多租户场景下为保证用户隔离supervisor 必须运行在无头用户headless user和唯一用户组之下在所有 supervisor 主机上添加所选的无头用户创建唯一用户组并把它设为 supervisor 节点上无头用户的主组在这些 supervisor 节点上为 storm 设置相应属性。5.4 多租户调度器Multitenant Scheduler为更好地支持多租户Storm 提供了专门的新调度器storm.scheduler: org.apache.storm.scheduler.multitenant.MultitenantScheduler实现位于 MultitenantScheduler.java。注意该调度器的很多特性依赖 Storm 认证——没有认证调度器就不知道用户是谁也就无法正确隔离拓扑。多租户调度器的目标是隔离不同拓扑同时允许限制单个用户在整个集群中占用的总资源。调度器配置可以通过storm.yaml或独立配置文件multitenant-scheduler.yaml应放在与storm.yaml相同的目录设置推荐使用multitenant-scheduler.yaml因为它可以在不重启 nimbus 的情况下热更新。目前只有一个配置项multitenant.scheduler.user.pools从用户名到该用户拓扑可保证使用的最大节点数的映射。例如multitenant.scheduler.user.pools: evans: 10 derek: 10仓库 conf/user-resource-pools-example.yaml 提供了用户资源池的示例配置可参考。5.5 以提交拓扑的用户身份运行 worker 进程默认情况下Storm 以运行 supervisor 的用户身份运行 worker这对安全不理想。要改为以启动拓扑的用户身份运行supervisor.run.worker.as.user: true默认值为false见 conf/defaults.yaml。启用后还需正确配置以下文件worker-launcher是一个特殊程序允许 supervisor 以不同用户身份启动 worker。它需要属主为 root、属组为只有 supervisor 无头用户所在的组且权限为6550octal。另有一个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且不能有 world 或 group 写权限。相关实现可参考仓库 storm-core/src/native/worker-launcher 目录下的 worker-launcher 原生程序源码。5.6 Storm-Netty 认证worker 之间 Netty 连接上的认证默认是关闭的conf/defaults.yaml 中storm.messaging.netty.authentication默认为false。可以在集群级或按拓扑开启开启后将阻止任何未授权消息被处理storm.messaging.netty.authentication: true5.7 用户模拟ImpersonationStorm 客户端可以代表另一个用户提交请求。例如userX提交一个 oozie 工作流工作流执行过程中用户oozie想代表userX提交拓扑就可以利用模拟impersonation特性。代表其他用户提交拓扑可使用StormSubmitter.submitTopologyAsAPI或者使用NimbusClient.getConfiguredClientAs以其他用户的身份获取 nimbus 客户端进而执行任意 nimbus 操作如 kill/rebalance/activate/deactivate。要确保只有授权用户能执行模拟应以nimbus.impersonation.authorizer启动 nimbus设置为org.apache.storm.security.auth.authorizer.ImpersonationAuthorizer。该授权器使用nimbus.impersonation.acl作为授权 ACL。从 ImpersonationAuthorizer.java 的prepare()L41-L46可以看到ACL 是模拟用户 → {hosts、groups}的两层映射结构。以下是支持模拟的 nimbus 配置示例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]为支持 oozie 场景可提供如下配置nimbus.impersonation.acl: oozie: hosts: [oozie-host1, oozie-host2, 127.0.0.1] groups: [some-group-that-userX-is-part-of]即只允许来自 oozie 主机含 127.0.0.1的oozie用户模拟some-group-that-userX-is-part-of组中的用户。6. 凭证自动推送与续期单个拓扑可以自行把凭证票据与令牌推送给 worker以便访问受保护的服务——但对所有用户暴露这一能力是负担。在常见场景下插件可以填充凭证 → 在另一端解包成 java Subject → 需要时由 Nimbus 续期。相关配置topology.auto-credentialsjava 插件列表所有插件必须实现IAutoCredentials接口在网关上填充凭证并在 worker 侧解包。Kerberos 安全集群上默认应指向org.apache.storm.security.auth.kerberos.AutoTGTnimbus.credential.renewers.classes也应设为此值以便 Nimbus 定期代表用户续期 TGT。nimbus.credential.renewers.freq.secs控制续期器多久轮询一次以判断是否有需要续期的凭证默认值600 秒见 conf/defaults.yaml通常够用。从 AutoTGT.java 源码看AutoTGT同时实现IAutoCredentials、ICredentialsRenewer与IMetricsRegistrantL42populateCredentials()通过 JAASLoginContext完成登录并取出 Kerberos TGT序列化后以TGT键存入凭证 mapL71-L79worker 侧再由populateSubject()反序列化回Subject续期窗口约为票据生命周期的 80%TICKET_RENEW_WINDOW 0.80f。此外Nimbus 自身也可以代表提交拓扑的用户获取凭证配置方式nimbus.autocredential.plugins.classes完全限定类名列表所有类必须实现INimbusCredentialPlugin。Nimbus 会在拓扑提交时调用所有已配置实现的populateCredentials方法。应与topology.auto-credentials和nimbus.credential.renewers.classes配合使用使凭证能在 worker 侧填充且 Nimbus 能自动续期。目前有两个使用示例AutoHDFS 与 AutoHBase它们为拓扑提交者自动填充 hdfs 与 hbase 的 delegation token这样用户就不必把 keytab 分发到所有可能的 worker 主机上。7. 拓扑规模限制默认允许提交任意大小的拓扑但 ZooKeeper 等组件对拓扑大小存在实际限制。以下配置用于限制拓扑最大规模YAML 配置项说明nimbus.slots.perTopology单个拓扑最多可使用的 slot/worker 数量nimbus.executors.perTopology单个拓扑最多可使用的 executor/线程数量8. 日志清理Logviewer 守护进程还负责清理已死亡拓扑的旧日志文件YAML 配置项说明logviewer.cleanup.age.minsworker 日志必须老到多少分钟按最后修改时间才被认为可清理存活 worker 的日志不会被 logviewer 清理它们由标准日志服务滚动如 0.11 中的 log4j2logviewer.cleanup.interval.secslogviewer 清理 worker 日志的时间间隔秒conf/defaults.yaml 中logviewer.cleanup.age.mins默认值为 10080即 7 天可作为参考基准。9. 配置汇总与实战顺序建议将本文涉及的关键配置按加固层次汇总均写入storm.yaml或对应的独立配置文件层次关键配置说明传输层storm.thrift.transport默认SimpleTransportPlugin开启 Kerberos 时改为KerberosSaslTransportPlugin主体映射storm.principal.tolocal默认DefaultPrincipalToLocalKerberos 时改为KerberosPrincipalToLocalNimbus 授权nimbus.authorizer设为SimpleACLAuthorizer用户模拟nimbus.impersonation.authorizer/nimbus.impersonation.acl设为ImpersonationAuthorizer并配置 ACL集群访问限制nimbus.users/nimbus.groups白名单限制管理员/监管nimbus.admins/nimbus.supervisor.users/logs.users/logs.groups管理员与 supervisor 身份Web 层ui.filter/logviewer.filterhadoop-auth 过滤器或自定义 servlet filter加密ui.https.*/drpc.https.*HTTPS 与可选 mTLSworker 数据面storm.messaging.netty.authenticationNetty 连接鉴权进程隔离supervisor.run.worker.as.user配合 worker-launcher多租户storm.scheduler/multitenant.scheduler.user.poolsMultitenantScheduler规模限制nimbus.slots.perTopology/nimbus.executors.perTopology防止超大拓扑日志生命周期logviewer.cleanup.age.mins/logviewer.cleanup.interval.secs日志清理推荐的加固顺序先做 OS/防火墙层端口隔离 → 再为 UI/Logviewer 配置过滤器与 HTTPS → 搭建 KDC、生成主体与 keytab → 开启 Kerberos 传输Nimbus/DRPC/Supervisor/ZK 的 JAAS 与 superACL→ 配置 SimpleACLAuthorizer 与 ImpersonationAuthorizer → 按需启用 worker-as-user、Netty 认证与多租户调度 → 最后设置拓扑规模上限与日志清理策略。仓库中的 conf/jaas_digest.conf、conf/storm_jaas.conf、conf/zookeeper_jaas.conf 与 conf/storm.yaml.example 可作为落地配置的起点模板。10. 延伸阅读SECURITY.md本文对应的官方安全文档原文conf/defaults.yaml全部配置项默认值端口、childopts、SSL、日志清理等storm-client/src/jvm/org/apache/storm/security/auth/kerberosKerberos 传输插件、AutoTGT、主体映射实现storm-client/src/jvm/org/apache/storm/security/auth/authorizerSimpleACLAuthorizer 与 ImpersonationAuthorizer 实现storm-server/src/main/java/org/apache/storm/scheduler/multitenant/MultitenantScheduler.java多租户调度器实现storm-core/src/native/worker-launcherworker-launcher 原生程序源码docs/SECURITY.mddocs 目录下的安全文档副本docs/STORM-UI-REST-API.mdUI REST APISPNEGO 认证后可访问docs/Distributed-RPC.mdDRPC 协议与端口说明赞分享大数据流处理后端【免费下载链接】stormApache Storm项目地址https://gitcode.com/gh_mirrors/storm6/storm点击查看免费下载相关推荐3分钟完整解锁WeMod专业版Wand-Enhancer纯本地补丁新手指南3分钟完整解锁WeMod专业版Wand Enhancer纯本地补丁新手指南 打开WeMod专业版入口锁在灰色付费墙后面年费又不算便宜。Wand Enhan桌面应用前端如何5分钟掌握Mermaid Live Editor免费在线图表编辑器的终极指南如何5分钟掌握Mermaid Live Editor免费在线图表编辑器的终极指南 你是否曾为创建流程图、时序图或甘特图而烦恼Mermaid Live Edi前端开发者工具数据可视化Apache Druid 安全加固实战TLS 加密、认证授权与权限模型详解Apache Druid 安全加固实战TLS 加密、认证授权与权限模型详解 Apache Druid 默认关闭全部安全特性TLS、认证、授权以降低首次部数据库OLAP大数据后端上一篇Weylus终极多点触控交互系统让你的平板秒变电脑绘图板下一篇Checkmate数据库备份自动化定时任务与恢复演练流程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考