Apache Storm 集群安全加固实战：从 OS 层防护到 Kerberos 认证与 ACL 授权-北京尧图网络

后端大数据【免费下载链接】stormApache Storm项目地址https://gitcode.com/gh_mirrors/storm22/storm点击查看免费下载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.KerberosSaslTransportPluginGSSAPI/Kerberos 机制见 KerberosSaslTransportPlugin.java。它负责验证你是谁。授权Authorization由 Nimbus 的nimbus.authorizer插件决定你能做什么。首选插件是SimpleACLAuthorizer负责验证你能做什么。很多安全特性自 Storm 0.10 起才可用本文所有配置以当前仓库master 分支实现为准。无论是否启用认证授权官方文档都建议先做好防火墙等 OS 层防护。防火墙与 OS 层安全在开启形式化认证/授权之前可以通过配置操作系统来限制可执行的操作——即使你计划启用认证这一步也是好习惯。建议启用防火墙只允许来自集群自身、受信主机与受信服务的入站连接。如果处理的数据敏感建议用 IPsec 加密集群主机间的所有流量。Storm 使用的端口清单默认端口Storm 配置项客户端主机/进程服务端2181storm.zookeeper.portNimbus、Supervisors 与 Worker 进程ZooKeeper6627nimbus.thrift.portStorm 客户端、Supervisors 与 UINimbus6628supervisor.thrift.portNimbusSupervisors8080ui.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 进程端口只是默认值实际端口以你部署时的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 的 AuthenticationFilterStorm UI或 logviewer可以配置为使用 hadoop-auth 的AuthenticationFilterui.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}形式的 principalhostname是 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 协商Firefox进入about:config搜索network.negotiate-auth.trusted-uris双击添加值http://storm-ui-hostname:8080。Google Chrome从命令行启动google-chrome --auth-server-whitelist*storm-ui-hostname --auth-negotiate-delegate-whitelist*storm-ui-hostname。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 SSLUI 与 DRPC 都支持配置 SSL生成 keystore 与证书是用户在此步骤之前自行完成的工作。UI 的 HTTPS 配置在storm.yaml中设置ui.https.portui.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启用双向认证2-way authenticationui.https.want.client.auth设为 true 时服务端请求客户端证书认证但即使客户端未提供认证也保持连接ui.https.need.client.auth设为 true 时服务端强制要求客户端提供认证DRPC 的 HTTPS 配置与 UI 类似配置 DRPC SSLdrpc.https.portdrpc.https.keystore.type例如jksdrpc.https.keystore.path例如/etc/ssl/storm_keystore.jksdrpc.https.keystore.passwordkeystore 密码drpc.https.key.password私钥密码可选配置drpc.https.truststore.pathdrpc.https.truststore.passworddrpc.https.truststore.type双向认证drpc.https.want.client.authdrpc.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-signedAuthenticationKerberosStorm 通过 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 而异# 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 分发到相应主机并设置 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.confNimbus 和 supervisor 进程还会连接 ZooKeeperZK如需让它们用 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.confjaas.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 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; };仓库中可参考的 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 与 realmauthProvider.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 doNotPromptfalse useTicketCachetrue serviceName$nimbus_user; };终端用户如果有带 keytab 的 headless 账号可以覆盖此配置。AuthorizationSimpleACLAuthorizer 授权设置认证解决你是谁授权解决你能做什么。Nimbus 的首选授权插件是SimpleACLAuthorizer配置nimbus.authorizer: org.apache.storm.security.auth.authorizer.SimpleACLAuthorizerDRPC 有独立的 authorizer 配置不要对 DRPC 使用 SimpleACLAuthorizer详见后文 DRPC 小节。源码层面的授权规则从 SimpleACLAuthorizer.java 的实现看每个进入的 Thrift 请求都会调用permit()按以下顺序判定管理员nimbus.adminsadmins与nimbus.admins.groupsadminsGroups命中的用户/组可执行任意操作直接放行Supervisor 用户nimbus.supervisor.users命中的用户只能执行 supervisor 命令集合fileDownload、processWorkerMetrics、getSupervisorAssignments、sendSupervisorWorkerHeartbeats普通用户命令submitTopology、fileUpload、getNimbusConf、getClusterInfo、getLeader、isTopologyNameAllowed、getTopologySummaries、getTopologySummaryByName、getTopologySummary、getSupervisorPageInfo、getOwnerResourceSummaries——当nimbus.users非空时仅列表内用户或其所属组在nimbus.groups中可执行拓扑级命令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.userssupervisor 用户nimbus.admins管理员用户。两者都可以是完整 Kerberos principal 名也可以是剥离 host 与 realm 后的用户名。Log server 有独立的授权配置logs.userslogs.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 用户与唯一组下运行在所有 supervisor 主机上添加选定的 headless 用户创建唯一组并将其设为 supervisor 节点上 headless 用户的主组然后在 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/stormstorm.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/implSUPERVISOR_RUN_WORKER_AS_USER与 worker-launcher 路径常量同样定义在 Config.java。Storm-Netty 认证Worker 之间 Netty 连接的认证默认关闭可在集群级或按拓扑设置。开启后任何未授权消息都无法被处理storm.messaging.netty.authentication: true用户模拟Impersonating a UserStorm 客户端可以代表另一个用户提交请求。例如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.ImpersonationAuthorizernimbus.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 定期代表用户续期 TGTnimbus.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 等组件对拓扑大小有限制。以下配置可限制拓扑的最大规模YAML 配置说明nimbus.slots.perTopology任意拓扑可使用的最大 slots/workers 数nimbus.executors.perTopology任意拓扑可使用的最大 executors/线程数日志清理Log CleanupLogviewer daemon 现在也负责清理已死拓扑的旧日志文件YAML 配置说明logviewer.cleanup.age.minsworker 日志按最后修改时间计多旧才被视为可清理。存活 worker 的日志不会被 logviewer 清理它们通过标准日志服务如 0.11 中的 log4j2滚动logviewer.cleanup.interval.secslogviewer 清理 worker 日志的间隔秒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.DRPCSimpleACLAuthorizerDRPCSimpleACLAuthorizer.java并有配套单测 DRPCSimpleACLAuthorizerTest.javaDRPC 的 SSL 与 Kerberos 配置则与前述 UI/Nimbus 方案一致。测试与验证仓库中包含与安全相关的集成测试与单元测试可作配置正确性的参照AuthTest.java认证/授权插件的服务端测试SimpleACLAuthorizerTest.java验证 SimpleACLAuthorizer 的 permit 判定DRPCSimpleACLAuthorizerTest.javaDRPC ACL 授权测试StormCluster.java集成测试中对安全配置的封装。开启认证授权后建议按防火墙端口最小化 → UI 访问控制 → HTTPS → Kerberos 认证 → 授权 ACL → 多租户隔离 → 用户模拟 → 自动凭证的顺序逐步验证每步通过后再进入下一步避免多因素叠加导致排障困难。赞分享后端大数据【免费下载链接】stormApache Storm项目地址https://gitcode.com/gh_mirrors/storm22/storm点击查看免费下载相关推荐Apache Storm 集群安全加固实战指南从防火墙端口到 Kerberos 认证与授权Apache Storm 集群安全加固实战指南从防火墙端口到 Kerberos 认证与授权本文基于 Apache Storm 官方安全文档仓库根目录 SE大数据流处理后端Apache Storm 安全部署实战指南认证、授权、TLS/mTLS 与集群加固Apache Storm 安全部署实战指南认证、授权、TLS/mTLS 与集群加固本文以 Apache Storm 官方安全指南为核心系统讲解如何在生产环大数据流处理后端如何5分钟掌握Mermaid Live Editor免费在线图表编辑器的终极指南如何5分钟掌握Mermaid Live Editor免费在线图表编辑器的终极指南你是否曾为创建流程图、时序图或甘特图而烦恼Mermaid Live Edi前端开发者工具数据可视化上一篇系统性调试方法论Systematic Debugging实战指南以 Dillinger 仓库为例的四阶段根因分析下一篇OSXCross快速入门10分钟搭建macOS交叉编译环境创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

Apache Storm 集群安全加固实战：从 OS 层防护到 Kerberos 认证与 ACL 授权

相关推荐

CMake FindOpenCL 模块全解析：从 find_package 到 OpenCL::OpenCL 导入目标

YOLO船舶检测实战：数据集解析与训练避坑指南

题解：洛谷 P14361 [CSP-S 2025] 社团招新

更多资讯

MASTG iOS 非生产资源详解：如何识别并从生产构建中剔除调试日志、测试端点与开发凭据

AI 为什么能学习？以及AI 与人脑的本质差距是什么？

2026年SMT贴片打样与量产产线选型指南

智慧政务AI大模型应用方案：从私有化部署到RAG落地实践

Julep mem-mcp Phase 2 兼容：让 .ctx 提示词包在 dotctx 加载器中忠实落地

计及氢能的综合能源优化调度：Matlab建模与实现

今日更新

PHP htmlentities()函数用法讲解

AI Agent工程实战：从七要素到七个决策点的系统设计指南

AI入局芯片设计验证：验证收敛50倍加速的真相与应对

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？