尧图网站建设 
DataHub 采集执行器安全加固指南信任边界、锁定镜像与包索引控制【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub本篇指南围绕 DataHub 中ingestion executor采集执行器的安全模型展开为什么说在 UI 里提交采集配方等于在 executor 上执行代码、executor 如何以可信采集工作进程身份认证并访问密钥服务、*-locked锁定镜像通过剥离 pip/uv 和屏蔽默认包索引实现的运行时加固以及私有镜像PyPI proxy的包索引控制策略。读完后你可以依据 docs/docker/ingestion-executor-security.md 的信任边界模型为自己的部署组合出最小权限 锁定镜像 镜像白名单的完整加固方案并在源码层面理解每一项控制的落地方式。一、信任边界executor 是事实上的代码执行面ingestion executor负责为从 DataHubUI、GraphQL 或 OpenAPI 提交的配方执行datahub ingest。文档给出的核心定性是应把它当作executor 上的代码执行来对待。风险来源有两类配方字段可以导入任意 Python。自定义 source / transformer 类型、Kafka 连接的oauth_cb回调类、schema registry 类名等字段本质上都是让 executor 进程 import 一段你指定的 Python 代码的入口非锁定镜像可以安装额外包。extra_pip_requirements允许配方在容器运行时pip install任意包等价于把包管理器的执行权交给了配方作者。由此推出的权限边界是任何拥有 Manage Metadata Ingestion 权限的人该权限包含在 Admin 角色中或者在某个 ingestion source 上同时持有 Edit Execute 权限的人就决定了 executor 上运行什么代码。因此文档给出的操作原则是这些权限只授予你愿意让其拥有 executor 代码执行权的运维人员配合密钥secrets和 executor 相关 token 的最小权限least privilege管理避免能提交配方的人顺带拿到高权限凭据。这一边界也解释了为什么后续的镜像加固都围绕收窄 executor 能装、能跑什么包来做——因为 executor 本身就是可信执行环境TEE之外的普通进程加固的核心是压缩攻击面。二、executor 的身份可信采集工作进程与密钥访问控制executor 并非匿名进程。它以trusted ingestion worker可信采集工作进程身份向 GMS 认证。在 OSS 快速启动配置中这一身份由系统级客户端凭据实现见 docker/datahub-actions/config/executor.yamldatahub: server: ${DATAHUB_GMS_PROTOCOL:-http}://${DATAHUB_GMS_HOST:-localhost}:${DATAHUB_GMS_PORT:-8080} extra_headers: Authorization: Basic ${DATAHUB_SYSTEM_CLIENT_ID:-__datahub_system}:${DATAHUB_SYSTEM_CLIENT_SECRET:-JohnSnowKnowsNothing}同一个 executor 动作还订阅 Kafka 上的执行请求dataHubExecutionRequest实体的dataHubExecutionRequestInput/dataHubExecutionRequestSignalaspect 变更按executorId过滤后路由给type: executor的动作处理executor.yaml。也就是说认证凭据 按 executorId 的任务路由共同构成了谁能让哪个 executor 跑什么的执行链。密钥访问SECRET_SERVICE_CALLER_GUARD_MODE密钥是采集配方中的敏感数据连接串、云凭据等。GMS 侧的getSecretValues接口通过caller guard机制区分人与系统进程默认SECRET_SERVICE_CALLER_GUARD_MODEENFORCE时浏览器会话和用户 PAT个人访问令牌不能调用getSecretValues而 datahub-actions即 executor 动作可以。源码中该配置的完整语义见 SecretServiceConfiguration.java三种取值及其用途在 Javadoc 中写得很明确ENFORCE默认——当检测到人类浏览器/移动端调用 decrypt 时直接抛SecurityExceptionAUDIT——只记录告警日志但放行适合灰度切换阶段DISABLED——完全不强制作为事故应急的 kill-switch。该枚举默认值为ENFORCESecretServiceConfiguration.java 第 25 行并通过 application.yaml 第 179 行 暴露为环境变量SECRET_SERVICE_CALLER_GUARD_MODE。SecretServiceFactory.java 在构造 SecretService 时将该配置映射为运行时模式配置缺省时回落到 ENFORCE。这个设计的意义在于密钥读取被收敛到executor 动作这一条系统通道上。人类用户即使用 PAT 也无法绕过 UI 直接批量拉取密钥明文而配方运行时又能正常取密——信任边界第一节的权限与凭据边界本节在这里闭合。在 DataHub Cloud 上等价的角色是embedded executorRemote Executor其密钥安全注意事项参见 Configuring Remote Executor。三、锁定*-locked镜像从构建期把包管理器移除Locked变体的datahub-actions镜像tag 形如*-locked面向依赖预构建的 bundled venv位于DATAHUB_BUNDLED_VENV_PATH默认/opt/datahub/venvs的部署连接者在构建期装好运行时不再安装任何东西。final-locked 阶段的实现细节打开 docker/datahub-actions/Dockerfile镜像由APP_ENV选择 full / slim / locked 三个变体全部基于 Chainguard Wolfi 基础镜像。final-locked阶段Dockerfile 第 443 行起做了四层递进式的处理默认 venv 只装 datahub-actions不装 metadata-ingestion。metadata-ingestion 源码树以文件形式拷入/metadata-ingestionbundled venv 使用 editable install 指向它——这是代码在镜像里但运行时不可 pip 安装的折中Dockerfile 第 465-500 行剥离所有 venv 中的 pip/uv。通过 docker/snippets/strip_pip_uv_from_venvs.sh 遍历/home/datahub/.venv与/opt/datahub/venvs/*卸载 pip、删除bin/uv、bin/pip等可执行文件及 site-packages 中的 pip/uv 包、dist-info 与本地缓存脚本全文。该脚本特意保留为.sh文件经COPY引入避免 DockerRUN把$v/$sp当作空的环境变量展开移除系统级 uv 与 pip wheel。apk del --no-cache uv并删除/usr/share/python-wheels/pip-*.whl——后者是因为py3-pip-wheel会带入一个 bootstrap pip wheel而 python 包还在时无法 apk 移除它只能单独删掉 wheel 文件以收敛 SBOM 扫描面Dockerfile 第 514-518 行把默认包索引指向不可用的 localhost 端点。作为最后一道纵深防御# Defense in depth: if any pip/uv-style tool is reintroduced, default index URL is unusable. ENV UV_INDEX_URLhttp://127.0.0.1:1/simple ENV PIP_INDEX_URLhttp://127.0.0.1:1/simpleDockerfile 第 521-523 行含义是即使未来有人误把 pip/uv 加回镜像pip install也会因为默认索引指向127.0.0.1:1一个必然拒绝连接的地址而失败。锁定镜像的取舍Tradeoff锁定镜像不能在运行时用任意pip install扩展。需要新增连接器时正确路径是重建镜像用 bundled venv builder 配合构建变量BUNDLED_VENV_PLUGINS默认值s3,demo-data,file,datahub-gc,datahub-documents见 Dockerfile 第 228 行与必传的BUNDLED_CLI_VERSION重新构建。文档同时警告不要拿锁定镜像当作Dockerfile 里RUN pip追加插件这类流程的基础镜像——它最终层里根本没有包管理器。完整的重建流程见 Bundled ingestion virtual environments。Remote Executordatahub-executor镜像在适用场景下遵循同样的 bundled-venv 契约部署细节同样参见 Configuring Remote Executor。四、包索引控制私有镜像与构建期索引引导即便不采用锁定镜像、连接器仍从 PyPI 解析控制环境能访问哪些索引也能显著降低供应链风险。文档给出的运营层三件套是让所有安装流量走内部镜像如 Artifactory、Nexus 或 DevPI只放行审批过的包收紧出站 egress使 executor 无法直接触达任意第三方索引 URL这些运营控制与 RBAC 一样属于纵深防御不能替代对第一节信任边界的审视。构建期用镜像相关构建参数引导安装从 DataHub 的 Dockerfile 构建自定义镜像时可以在构建期就固定索引来源。datahub-actions镜像的 Python 基础层通过 docker/snippets/uv/ 下的配置体系生成uv.tomlgenerate-config.py 支持两种模式——既有 profiledefault/chainguard/chainguard-ci见 docker/snippets/uv/profiles/default.toml当前为空文件、即默认公开 PyPI注释里给出了自定义[[index]]的写法示例custom profile显式要求DEFAULT_INDEX_URL可再叠加空格分隔的EXTRA_INDEX_URLS作为附加索引生成时统一使用index-strategy unsafe-best-match。脚本对未知 profile 会直接报错退出避免把拼写错误静默当成从零构建。文档中点名的构建期变量为PIP_MIRROR_URL、PIP_EXTRA_INDEX_URL与UV_INDEX_URL设置于 Python 基础镜像层。关键的操作闭环是运行时/编排层的网络策略必须与构建期策略对齐——如果编排平台允许 executor 工作负载绕过你的内部镜像直连 PyPI那么构建期再严格的索引配置也会在运行时失效。五、加固方案小结与延伸阅读把本文三条主线合起来一套可落地的 executor 加固组合是层次控制手段仓库依据权限边界Manage Metadata Ingestion / EditExecute 只授予可信运维密钥与 token 最小权限docs/docker/ingestion-executor-security.md凭据边界executor 以系统凭据认证DATAHUB_SYSTEM_CLIENT_ID/SECRETSECRET_SERVICE_CALLER_GUARD_MODEENFORCE阻断人类调用者读密executor.yaml、SecretServiceConfiguration.java运行时安装面采用*-locked镜像bundled venv 预装pip/uv 剥离索引指向127.0.0.1:1Dockerfile final-locked供应链面内部镜像/代理 egress 限制 构建期索引引导PIP_MIRROR_URL、UV_INDEX_URL等docker/snippets/uv/generate-config.py延伸阅读均为仓库内文档Bundled ingestion virtual environments锁定镜像下重建而非热装的完整流程Ingestion Executor 概念文档executor 事件流与动作框架的背景Configuring Remote ExecutorDataHub Cloud 侧 embedded executor 及其密钥安全注意事项。适用前提本文所有镜像与配置证据均来自当前仓库的 docker/datahub-actions/Dockerfile 与 docker/datahub-actions/config/基于 Chainguard Wolfi 基础镜像与 Python 3.11自建镜像时若更换基础镜像BASE_IMAGE构建参数strip 脚本与 Wolfi 相关的包处理方式需自行验证。【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 DataHub 采集执行器安全加固指南：信任边界、锁定镜像与包索引控制
DataHub 采集执行器安全加固指南信任边界、锁定镜像与包索引控制【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub本篇指南围绕 DataHub 中ingestion executor采集执行器的安全模型展开为什么说在 UI 里提交采集配方等于在 executor 上执行代码、executor 如何以可信采集工作进程身份认证并访问密钥服务、*-locked锁定镜像通过剥离 pip/uv 和屏蔽默认包索引实现的运行时加固以及私有镜像PyPI proxy的包索引控制策略。读完后你可以依据 docs/docker/ingestion-executor-security.md 的信任边界模型为自己的部署组合出最小权限 锁定镜像 镜像白名单的完整加固方案并在源码层面理解每一项控制的落地方式。一、信任边界executor 是事实上的代码执行面ingestion executor负责为从 DataHubUI、GraphQL 或 OpenAPI 提交的配方执行datahub ingest。文档给出的核心定性是应把它当作executor 上的代码执行来对待。风险来源有两类配方字段可以导入任意 Python。自定义 source / transformer 类型、Kafka 连接的oauth_cb回调类、schema registry 类名等字段本质上都是让 executor 进程 import 一段你指定的 Python 代码的入口非锁定镜像可以安装额外包。extra_pip_requirements允许配方在容器运行时pip install任意包等价于把包管理器的执行权交给了配方作者。由此推出的权限边界是任何拥有 Manage Metadata Ingestion 权限的人该权限包含在 Admin 角色中或者在某个 ingestion source 上同时持有 Edit Execute 权限的人就决定了 executor 上运行什么代码。因此文档给出的操作原则是这些权限只授予你愿意让其拥有 executor 代码执行权的运维人员配合密钥secrets和 executor 相关 token 的最小权限least privilege管理避免能提交配方的人顺带拿到高权限凭据。这一边界也解释了为什么后续的镜像加固都围绕收窄 executor 能装、能跑什么包来做——因为 executor 本身就是可信执行环境TEE之外的普通进程加固的核心是压缩攻击面。二、executor 的身份可信采集工作进程与密钥访问控制executor 并非匿名进程。它以trusted ingestion worker可信采集工作进程身份向 GMS 认证。在 OSS 快速启动配置中这一身份由系统级客户端凭据实现见 docker/datahub-actions/config/executor.yamldatahub: server: ${DATAHUB_GMS_PROTOCOL:-http}://${DATAHUB_GMS_HOST:-localhost}:${DATAHUB_GMS_PORT:-8080} extra_headers: Authorization: Basic ${DATAHUB_SYSTEM_CLIENT_ID:-__datahub_system}:${DATAHUB_SYSTEM_CLIENT_SECRET:-JohnSnowKnowsNothing}同一个 executor 动作还订阅 Kafka 上的执行请求dataHubExecutionRequest实体的dataHubExecutionRequestInput/dataHubExecutionRequestSignalaspect 变更按executorId过滤后路由给type: executor的动作处理executor.yaml。也就是说认证凭据 按 executorId 的任务路由共同构成了谁能让哪个 executor 跑什么的执行链。密钥访问SECRET_SERVICE_CALLER_GUARD_MODE密钥是采集配方中的敏感数据连接串、云凭据等。GMS 侧的getSecretValues接口通过caller guard机制区分人与系统进程默认SECRET_SERVICE_CALLER_GUARD_MODEENFORCE时浏览器会话和用户 PAT个人访问令牌不能调用getSecretValues而 datahub-actions即 executor 动作可以。源码中该配置的完整语义见 SecretServiceConfiguration.java三种取值及其用途在 Javadoc 中写得很明确ENFORCE默认——当检测到人类浏览器/移动端调用 decrypt 时直接抛SecurityExceptionAUDIT——只记录告警日志但放行适合灰度切换阶段DISABLED——完全不强制作为事故应急的 kill-switch。该枚举默认值为ENFORCESecretServiceConfiguration.java 第 25 行并通过 application.yaml 第 179 行 暴露为环境变量SECRET_SERVICE_CALLER_GUARD_MODE。SecretServiceFactory.java 在构造 SecretService 时将该配置映射为运行时模式配置缺省时回落到 ENFORCE。这个设计的意义在于密钥读取被收敛到executor 动作这一条系统通道上。人类用户即使用 PAT 也无法绕过 UI 直接批量拉取密钥明文而配方运行时又能正常取密——信任边界第一节的权限与凭据边界本节在这里闭合。在 DataHub Cloud 上等价的角色是embedded executorRemote Executor其密钥安全注意事项参见 Configuring Remote Executor。三、锁定*-locked镜像从构建期把包管理器移除Locked变体的datahub-actions镜像tag 形如*-locked面向依赖预构建的 bundled venv位于DATAHUB_BUNDLED_VENV_PATH默认/opt/datahub/venvs的部署连接者在构建期装好运行时不再安装任何东西。final-locked 阶段的实现细节打开 docker/datahub-actions/Dockerfile镜像由APP_ENV选择 full / slim / locked 三个变体全部基于 Chainguard Wolfi 基础镜像。final-locked阶段Dockerfile 第 443 行起做了四层递进式的处理默认 venv 只装 datahub-actions不装 metadata-ingestion。metadata-ingestion 源码树以文件形式拷入/metadata-ingestionbundled venv 使用 editable install 指向它——这是代码在镜像里但运行时不可 pip 安装的折中Dockerfile 第 465-500 行剥离所有 venv 中的 pip/uv。通过 docker/snippets/strip_pip_uv_from_venvs.sh 遍历/home/datahub/.venv与/opt/datahub/venvs/*卸载 pip、删除bin/uv、bin/pip等可执行文件及 site-packages 中的 pip/uv 包、dist-info 与本地缓存脚本全文。该脚本特意保留为.sh文件经COPY引入避免 DockerRUN把$v/$sp当作空的环境变量展开移除系统级 uv 与 pip wheel。apk del --no-cache uv并删除/usr/share/python-wheels/pip-*.whl——后者是因为py3-pip-wheel会带入一个 bootstrap pip wheel而 python 包还在时无法 apk 移除它只能单独删掉 wheel 文件以收敛 SBOM 扫描面Dockerfile 第 514-518 行把默认包索引指向不可用的 localhost 端点。作为最后一道纵深防御# Defense in depth: if any pip/uv-style tool is reintroduced, default index URL is unusable. ENV UV_INDEX_URLhttp://127.0.0.1:1/simple ENV PIP_INDEX_URLhttp://127.0.0.1:1/simpleDockerfile 第 521-523 行含义是即使未来有人误把 pip/uv 加回镜像pip install也会因为默认索引指向127.0.0.1:1一个必然拒绝连接的地址而失败。锁定镜像的取舍Tradeoff锁定镜像不能在运行时用任意pip install扩展。需要新增连接器时正确路径是重建镜像用 bundled venv builder 配合构建变量BUNDLED_VENV_PLUGINS默认值s3,demo-data,file,datahub-gc,datahub-documents见 Dockerfile 第 228 行与必传的BUNDLED_CLI_VERSION重新构建。文档同时警告不要拿锁定镜像当作Dockerfile 里RUN pip追加插件这类流程的基础镜像——它最终层里根本没有包管理器。完整的重建流程见 Bundled ingestion virtual environments。Remote Executordatahub-executor镜像在适用场景下遵循同样的 bundled-venv 契约部署细节同样参见 Configuring Remote Executor。四、包索引控制私有镜像与构建期索引引导即便不采用锁定镜像、连接器仍从 PyPI 解析控制环境能访问哪些索引也能显著降低供应链风险。文档给出的运营层三件套是让所有安装流量走内部镜像如 Artifactory、Nexus 或 DevPI只放行审批过的包收紧出站 egress使 executor 无法直接触达任意第三方索引 URL这些运营控制与 RBAC 一样属于纵深防御不能替代对第一节信任边界的审视。构建期用镜像相关构建参数引导安装从 DataHub 的 Dockerfile 构建自定义镜像时可以在构建期就固定索引来源。datahub-actions镜像的 Python 基础层通过 docker/snippets/uv/ 下的配置体系生成uv.tomlgenerate-config.py 支持两种模式——既有 profiledefault/chainguard/chainguard-ci见 docker/snippets/uv/profiles/default.toml当前为空文件、即默认公开 PyPI注释里给出了自定义[[index]]的写法示例custom profile显式要求DEFAULT_INDEX_URL可再叠加空格分隔的EXTRA_INDEX_URLS作为附加索引生成时统一使用index-strategy unsafe-best-match。脚本对未知 profile 会直接报错退出避免把拼写错误静默当成从零构建。文档中点名的构建期变量为PIP_MIRROR_URL、PIP_EXTRA_INDEX_URL与UV_INDEX_URL设置于 Python 基础镜像层。关键的操作闭环是运行时/编排层的网络策略必须与构建期策略对齐——如果编排平台允许 executor 工作负载绕过你的内部镜像直连 PyPI那么构建期再严格的索引配置也会在运行时失效。五、加固方案小结与延伸阅读把本文三条主线合起来一套可落地的 executor 加固组合是层次控制手段仓库依据权限边界Manage Metadata Ingestion / EditExecute 只授予可信运维密钥与 token 最小权限docs/docker/ingestion-executor-security.md凭据边界executor 以系统凭据认证DATAHUB_SYSTEM_CLIENT_ID/SECRETSECRET_SERVICE_CALLER_GUARD_MODEENFORCE阻断人类调用者读密executor.yaml、SecretServiceConfiguration.java运行时安装面采用*-locked镜像bundled venv 预装pip/uv 剥离索引指向127.0.0.1:1Dockerfile final-locked供应链面内部镜像/代理 egress 限制 构建期索引引导PIP_MIRROR_URL、UV_INDEX_URL等docker/snippets/uv/generate-config.py延伸阅读均为仓库内文档Bundled ingestion virtual environments锁定镜像下重建而非热装的完整流程Ingestion Executor 概念文档executor 事件流与动作框架的背景Configuring Remote ExecutorDataHub Cloud 侧 embedded executor 及其密钥安全注意事项。适用前提本文所有镜像与配置证据均来自当前仓库的 docker/datahub-actions/Dockerfile 与 docker/datahub-actions/config/基于 Chainguard Wolfi 基础镜像与 Python 3.11自建镜像时若更换基础镜像BASE_IMAGE构建参数strip 脚本与 Wolfi 相关的包处理方式需自行验证。【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考