基于 Apache DolphinScheduler 的安全漏洞报告指南与安全模型全解析
2026/9/15 17:47:40 网站建设 项目流程

基于 Apache DolphinScheduler 的安全漏洞报告指南与安全模型全解析

【免费下载链接】dolphinschedulerApache DolphinScheduler is the modern data orchestration platform. Agile to create high performance workflow with low-code项目地址: https://gitcode.com/GitHub_Trending/dol/dolphinscheduler

Apache DolphinScheduler(以下简称 DolphinScheduler)作为开源数据编排平台,允许用户在 Worker 节点上执行自定义命令与代码、管理多租户与数据源连接,其安全边界与漏洞判定也因此比一般 Web 系统更加复杂。本文以仓库内 安全漏洞报告文档 及其关联的 安全模型文档 为核心,系统讲解漏洞的私密上报流程、四种用户类型的职责与权限边界、数据源/资源/告警等模块的安全约定,并结合dolphinscheduler-api模块的认证源码与配置文件,帮助你正确区分"安全漏洞"与"授权范围内正常操作"的边界,安全地部署、使用与二次开发 DolphinScheduler。

一、如何报告安全漏洞:官方上报渠道与流程

Apache Software Foundation(ASF)在消除其软件项目中的安全问题上采取严格立场,DolphinScheduler 同样高度重视与其功能相关的安全性问题。如果你对 DolphinScheduler 的安全性存有疑虑,或发现了漏洞、潜在威胁,请遵循以下官方流程上报。

1.1 上报邮箱与报告要素

将问题通过邮件发送至security@dolphinscheduler.apache.org,与 Apache 安全团队取得联系。邮件中需要包含以下核心要素:

  1. 明确项目名称:在邮件中将项目名称指定为DolphinScheduler
  2. 问题描述:提供相关问题或潜在威胁的详细描述;
  3. 复现方法:强烈建议附上问题复现与重现的具体步骤,便于安全团队评估与分析。

在收到报告后,Apache 安全团队与 DolphinScheduler 社区会完成评估、分析和调查,随后与你取得联系。

1.2 报告前的两条铁律

  • 私密优先:在公共领域公开该安全问题之前,请务必先在安全邮箱中私下报告,切勿直接公开漏洞细节;
  • 先核对安全模型:提交前,请先阅读仓库中的 安全模型文档,确认该问题是否属于真正的安全漏洞,还是已被列为"授权范围内正常操作"。

1.3 与 ASF 安全流程的衔接

仓库根目录的 SECURITY.md 进一步明确了这一约定:DolphinScheduler 遵循 Apache Software Foundation 的通用安全流程,可疑漏洞应私密报告至security@apache.org禁止针对安全报告直接提交公开的 GitHub issue 或 pull request。换言之,社区级邮箱security@dolphinscheduler.apache.org与基金会级邮箱security@apache.org构成了双层上报通道,两者都强调同一原则:先私密、后公开,先沟通、后披露

从源码结构看,该约定还体现在项目对鉴权凭据的默认信任策略上(详见下文"认证方式"与"误认为是安全漏洞的示例"):一旦用户通过任何途径获得平台的鉴权信息,平台即视为正常授权用户并完全信任其操作,这正是上报前必须先核对安全模型的根本原因。

二、DolphinScheduler 安全模型:角色、边界与信任前提

安全模型文档从"用户从了解到使用 DolphinScheduler 的全生命周期"出发,描述了不同角色用户的工作范围、职责与重点功能,帮助使用者在部署、使用、运维阶段明确注意事项与规则,也帮助开发者界定"安全漏洞"与"正常功能"的边界。

2.1 平台使用工作流与四类角色

无论使用单节点、伪集群还是集群部署(服务器或云部署),系统使用通常经历四个阶段:

  1. 系统部署:配置运行环境;
  2. 创建系统用户:配置对应资源;
  3. 创建工作流定义:配置任务运行;
  4. 系统运维:日常监控与维护。

围绕上述四个步骤,系统涉及四类用户,其权限与信任边界各不相同:

用户类型定义权限边界与安全职责
服务部署人员拥有操作服务器权限的人员负责服务器安全边界与环境要求,需掌握任务运行方式
系统管理员拥有平台全部操作权限管理队列、租户、用户、告警组、worker 分组、令牌等全部配置
系统普通用户实际的工作流开发与运营用户创建/运行工作流、维护开发所需的部分资源
未登录用户未通过认证的匿名访问者平台不允许未登录用户访问系统,下文讨论不包含该类用户

2.2 服务部署人员的安全职责

服务部署人员需确认服务启动用户的权限,明确部署用户的操作权限边界,具体包括:

  1. 多租户运行:需要具备创建用户与切换用户权限;
  2. 自定义脚本与代码:DolphinScheduler 支持运行用户自定义的脚本和代码,用户可通过节点配置在机器上执行任意命令或代码,部署人员需通过权限保护敏感文件;
  3. 数据源连接:服务器会执行用户自定义 SQL,平台不限制 SQL 类型,SQL 执行权限与创建数据源的用户权限相关;
  4. 网络与交互安全:确保业务所需 worker 分组中所有 worker 服务器与任务运行所需资源之间的网络和交互安全;
  5. 本地任务类型:worker 本地任务(如 datax 等)需要具备调用对应服务的权限;
  6. 资源中心文件系统:资源中心可直接对接本地文件系统,集群部署下可通过共享文件方式将其他服务器文件挂载到 API 服务器,部署人员需确保挂载目录中的文件允许系统用户操作,并信任操作者的行为;
  7. K8s 任务类型:k8s 集群由运维提供,运维需保证集群服务安全,防止 pod 逃逸等安全问题。

2.3 系统管理员的安全职责

系统管理员拥有平台所有操作权限,实际使用中应严格控制管理员账户的使用范围,并高度信任管理员不会滥用此功能:

  • 可操作队列管理、租户管理、用户管理、告警组管理、worker 分组管理、令牌管理等全部功能,能操作所有配置(包括连接资源所需的敏感凭证等重要信息);
  • 在用户管理模块可对资源、数据源、项目等进行授权,需要明确授权后用户将对对应资源拥有所有使用权限
  • 系统管理员同时拥有普通用户的全部操作权限。

2.4 系统普通用户的操作范围

普通用户是实际的工作流开发与运营用户,应高度信任其不会滥用功能:

  • 可创建工作流与任务,任务在 worker 中执行,用户可以自定义任意命令和代码在指定 worker 分组中运行——包括 shell、SQL、跳转至其他服务器执行 shell 脚本等所有支持的任务类型;
  • 任务运行会产生日志,用户可通过 UI 页面查看、下载任务运行日志;
  • 可创建数据源连接,可修改、删除有权限的连接及其配置,尤其是对敏感凭据的操作可能对资源本身或系统造成影响。

三、平台核心模块的安全约定

平台除核心的工作流开发与运行外,还需要配置、管理对应的环境和资源,各模块的安全约定如下:

3.1 数据源管理

所有用户均可操作数据源管理,管理员用户可对普通用户授权后进行操作。数据源任务运行的权限由数据源连接提供,连接配置应尽量控制任务执行权限。数据源配置中用户可以自定义连接参数,且对所有使用该数据源的任务生效。

3.2 资源中心

资源中心可配置本地、分布式文件存储、云对象存储等多种方式。当进行文件的创建或上传操作时,所有文件和资源都会被存储在分布式文件系统 HDFS 或远端的对象存储。用户可修改有权限文件的内容,此过程需要信任用户不会损坏文件、不会造成其他安全风险。

3.3 告警管理

所有用户可将有权限的告警通道配置到各自的流程中,用户可以修改包含敏感凭据的告警配置。告警配置应用于工作流运行超时、结果等规则的告警中,需要信任用户的告警配置与告警信息发送不会对告警通道和接收告警人员产生影响。

3.4 安全中心

管理员用户可配置队列、租户、用户、告警组、worker 分组、令牌、k8s 集群、k8s 命名空间等资源,需要信任用户对资源的权限分配、使用与维护不会对平台和服务本身产生影响。

3.5 网络环境前提

DolphinScheduler 的部署与使用默认用户网络是安全和值得信任的,平台不处理内网交叉渗透问题。这一前提直接决定了后续"误认为是安全漏洞的示例"中多项判定的边界。

四、认证方式:四种登录实现与源码佐证

安全模型指出,DolphinScheduler 支持四种认证方式:自身账号密码登录、LDAP、通过 Casdoor 实现的 SSO 登录、通过 OAuth2 授权登录,且 OAuth2 授权登录方式可以与其他认证方式同时使用。需要高度信任以任何方式登录的用户都不会滥用对应权限和功能。

这一描述在源码中得到完整印证。认证类型的定义位于 AuthenticationType.java:

  • PASSWORD(0, "verify via user name and password")—— 用户名密码认证;
  • LDAP(1, "verify via LDAP server")—— LDAP 服务器认证;
  • CASDOOR_SSO(2, "verify via casdoor sso provider")—— Casdoor SSO 认证;
  • OIDC(3, "verify via OpenID Connect provider")—— OIDC/OAuth2 授权登录。

认证方式由配置项security.authentication.type控制,默认值为PASSWORD,见 SecurityConfig.java。各认证器位于 security 包 下,分别由pwd/PasswordAuthenticatorldap/LdapAuthenticatorsso/CasdoorAuthenticatoroidc/OidcAuthenticator实现。

以 LDAP 为例,LdapAuthenticator.java 的登录逻辑为:调用ldapService.ldapLogin(userName, password)校验凭据,成功后查询本地用户,若用户不存在且配置了自动创建(createIfUserNotExists()),则自动创建对应用户。其底层配置项在 LdapService.java 中定义,包括:

配置项默认值含义
security.authentication.ldap.urlnullLDAP 服务器地址
security.authentication.ldap.base-dnnullLDAP 基础 DN
security.authentication.ldap.usernamenull绑定用户名
security.authentication.ldap.passwordnull绑定密码
security.authentication.ldap.user.admin-usernamenull管理员用户名
security.authentication.ldap.user.admin-user-filternull管理员用户过滤条件
security.authentication.ldap.user.identity-attributenull用户身份属性
security.authentication.ldap.user.email-attributenull用户邮箱属性
security.authentication.ldap.user.not-exist-actionDENYLDAP 用户不存在时的动作
security.authentication.ldap.ssl.enablefalse是否启用 SSL

五、误认为是安全漏洞的典型示例(7 类边界判定)

以下是以往使用者和开发者提出过的一些错误漏洞报告。核心判定逻辑是:平台信任授权范围内的一切用户操作,凡是在权限范围内、经用户主动配置或主动行为引发的风险,均不属于安全漏洞。

  1. 利用插件的不安全设置进行攻击:用户使用插件时将某些参数设置为不安全配置,进而通过该配置进行系统攻击,不属于安全漏洞。用户对参数的设置属于主动行为,授权即已信任用户的参数配置操作。例如在使用 mysql 驱动连接 doris 时,在 JDBC 连接参数中加入{"aaa":"dsf&allowLoadLocalInfile=true#"},该配置可能将本地敏感文件发送至服务器,但既然用户按需增加了配置,则信任用户的所有操作。

  2. 利用部署时的安全配置访问系统:部署用户应按官网操作将敏感配置修改,这类配置属于服务敏感信息,其安全级别等同于服务数据库连接信息。当其他用户通过任何途径获取到敏感配置后,平台即视为正常授权用户,完全信任其操作。例如用户通过配置文件获取了auth-token数据,通过该配置进行鉴权并创建用户,再对系统进行操作——既然用户已获得平台鉴权信息,则认为信任其所有操作。

  3. 执行平台在任务执行过程中产生的中间文件:任务运行中产生的中间文件封装了运行所需的环境和参数等信息,与任务存储在同一节点。运行这些文件与其他用户在同一节点运行同一任务没有差异。在部署和权限分配中,将 worker 等资源分配给用户,意味着完全信任该用户对该服务节点的所有操作。例如 remote shell 任务会在服务器中生成中间文件,用户通过 shell 节点操作该文件,因用户具有该节点权限,则信任其对该节点的所有操作。

  4. 已授权用户通过页面输入框输入脚本进行攻击:DolphinScheduler 有多个输入框允许用户按需自定义配置。作为开源任务调度系统,管理员在部署、授权等涉及安全的过程中需要完全信任目标用户授权范围内的所有操作。用户通过页面或接口增加、修改配置的行为若属于权限范围内操作,则不属于安全漏洞。

  5. 通过修改镜像或提供不安全的镜像运行进行攻击:DolphinScheduler 本身与任务运行均支持 k8s 集群。在服务或任务运行之前,用户需确保镜像功能和所配置参数,信任服务、任务运行过程中的所有操作。因此,在镜像运行之前通过任何途径修改任务或参数进行攻击,不属于安全漏洞。

  6. 通过获取服务日志中打印的某些敏感信息进行攻击:服务日志中会打印部分敏感信息,服务部署人员可通过日志查看程序运行详情。服务部署人员被认为是可信任用户,不会攻击程序,因此该类型问题不属于漏洞。

  7. 系统管理员访问不受信任的三方网站导致的安全问题:系统管理员被认为具备基本的安全防范意识,因安全防范意识薄弱所引发的问题不属于漏洞。

六、安全实践建议

结合文档边界与仓库实现,给部署者与使用者三点实践建议:

  1. 部署阶段守住第一道防线:服务部署人员应严格按文档控制服务启动用户权限、保护敏感配置(如数据库连接信息、auth-token类鉴权凭据)、约束 worker 分组的网络边界,这些是平台信任模型的前提条件;
  2. 认证配置按需收紧:通过security.authentication.type选择合适的认证方式,LDAP/OIDC/Casdoor 场景下合理设置用户不存在时的动作(如保持默认DENY),避免越权自动建号;
  3. 上报漏洞遵守私密原则:先阅读 安全模型 核对边界,再通过security@dolphinscheduler.apache.orgsecurity@apache.org私密上报,并附上项目名称、问题描述与复现步骤,待官方团队评估后再考虑是否公开披露。

理解 DolphinScheduler 的信任模型——"授权即信任、主动配置即负责"——是正确部署、使用与贡献这个平台的前提,也是提交高质量安全报告的基础。

【免费下载链接】dolphinschedulerApache DolphinScheduler is the modern data orchestration platform. Agile to create high performance workflow with low-code项目地址: https://gitcode.com/GitHub_Trending/dol/dolphinscheduler

创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询