Fleetd 认证机制详解Fleet 终端 Agent 的 Enroll Secret、Node Key 与 TUF 安全更新【免费下载链接】fleetOpen device management项目地址: https://gitcode.com/GitHub_Trending/fl/fleetFleetd 是运行在每台终端macOS、Windows、Linux上的 Fleet 代理负责周期性上报设备数据并执行管理任务。本文基于 Fleet 仓库中 Fleetd 认证文档 与orbitfleetd 的主守护进程源码展开系统讲解三个组件orbit、osquery、Fleet desktop各自如何认证到 Fleet 服务器从安装期的 enroll secret到运行期的 node key 与每小时轮换的 Fleet desktop token再到 TUF 安全自动更新、自定义 CA 证书与 mTLS 的适用边界。读完后你可以完整理解一次 fleetd 安装后的认证链路并能结合 orbit 入口源码 与 keystore 实现 自行验证和排查认证问题。Fleetd 的三个组件及其职责Fleetd 支持 macOS x86_64 与 Apple Silicon通过 universal 二进制、Windows 与 Linuxx86_64 和 arm64。它由三个组件构成orbit主守护进程/服务负责在终端上启动并管理所有其他组件。orbit 在 macOS/Linux 上以root运行在 Windows 上以SYSTEM服务运行。其源码位于 orbit 目录osquery为终端提供基于 SQL 的探测、监控与分析能力是设备数据的实际采集者Fleet desktop系统托盘图标应用作为 GUI 用户与 Fleet 的交互入口。它随桌面环境存在在无图形界面的服务器等场景中可以禁用或缺失。三者分别使用独立的凭证认证到 Fleet这正是理解 fleetd 认证的关键一次 enroll secret换来三份相互独立的长期凭证。TLS所有组件通信的基线所有 fleetd 组件到 Fleet 的通信都基于 HTTPS。fleetd 也支持 mTLS见下文专门一节。从源码结构看TLS 相关能力集中在 orbit 的命令行参数中见 orbit.go 中的标志定义--fleet-url环境变量ORBIT_FLEET_URLFleet 服务器地址。若未带协议前缀orbit 会自动补上https://--fleet-certificateORBIT_FLEET_CERTIFICATEFleet 服务器证书链的路径用于自定义 CA 场景--insecureORBIT_INSECURE禁用 TLS 证书校验。源码中明确校验了--insecure与--fleet-certificate不可同时指定二者互斥--update-tls-certificateORBIT_UPDATE_TLS_CERTIFICATETUF 更新服务器的证书链同理与--insecure互斥。注册密钥Enroll Secret注册期的唯一凭证终端通过 enroll secret 在注册enrollment过程中向 Fleet 认证Fleet 免费版可以定义多个 enroll secretFleet 高级版premium可以全局Unassigned定义多个 enroll secret并为每个 fleet 定义多个 enroll secretFleet 会自动将设备加入与所用 enroll secret 对应的 fleet。Enroll secret 由 Fleet 随机生成若管理员未提供或由管理员自定义Fleet 随机生成的 enroll secret 为 24 字节随机数经 base64 编码。Enroll secret 只在注册过程中用于认证。一旦终端完成注册设备改用 node key 认证下文详述。通过 fleetctl 生成 fleetd 安装包使用fleetctl生成 fleetd 安装包时管理员需要提供 enroll secretfleetctl package --typepkg \ --fleet-desktop \ --fleet-url... \ --enroll-secret...Fleet URL 和 Enroll secret 会被内嵌进生成的安装包。安装包本质上就是 orbit 的可执行文件加上这两项预置配置——这与源码中的加载逻辑吻合orbit 启动时依次尝试从命令行参数、enroll secret 文件--enroll-secret-path、系统 keystore 中读取 enroll secret见 readEnrollSecretFromFile 与 tryReadEnrollSecretFromKeystore。fleetd 中的注册过程详解安装 fleetd 包时实际执行的是orbit二进制。以下按注册链的先后顺序拆解每个环节并对照源码。orbit 的注册与 node key首次启动时enroll secret 以仅root/SYSTEM可访问的文本文件形式放在端点文件系统上。orbit第一次启动时使用该 enroll secret 向 Fleet 注册。若 enroll secret 有效Fleet 服务器会生成一个随机的 orbit node key 返回给 orbitorbit进程将该 node key 写入一个仅root/SYSTEM可访问的文本文件。注册完成后所有 orbit 相关的对 Fleet 请求都使用该 orbit node key 认证。osquery 的注册与 node keyorbit随后启动osquery守护进程同样以root/SYSTEM运行。这里有一个容易忽略的实现细节osquery 复用的是与 orbit 相同的 enroll secret但传递方式是环境变量而非明文参数。从 orbit.go 中的这段代码 可以看到enrollSecret : c.String(enroll-secret) if enrollSecret ! { const enrollSecretEnvName ENROLL_SECRET options append(options, osquery.WithEnv([]string{enrollSecretEnvName enrollSecret}), osquery.WithFlags([]string{--enroll_secret_env, enrollSecretEnvName}), ) }即 orbit 把 enroll secret 注入 osquery 子进程的环境变量ENROLL_SECRET并通过--enroll_secret_env告知 osqueryd 从该环境变量读取密钥避免密钥出现在进程命令行参数中。注册成功后Fleet 同样生成一个随机的 osquery node key 返回osquery 将 node key 存储在其内部的 RocksDB 数据库文件中仅root/SYSTEM可访问。此后 osquery 相关请求使用该 osquery node key 认证。用 Hardware UUID 把 orbit 与 osquery 绑定为一台主机Fleet 服务器使用端点的 Hardware UUID 将orbit与osquery两个进程关联起来使其在 Fleet 中识别为同一台 host。对于克隆虚拟机等 Hardware UUID 重复的系统可以改用--host-identifierinstance标志取值uuid或instance默认uuid改用 osquery 的 instance ID 作为标识。源码中该标志的定义与校验见 host-identifier flag且只有当值为instance时才会把InstanceID传入注册信息// 仅当用户以 --host-identifierinstance 运行 orbit 时才发送 osquery 的 instance_id // 否则 orbit 与 osquery 通过 Hardware UUID 匹配。 if c.String(host-identifier) instance { orbitHostInfo.OsqueryIdentifier osqueryHostInfo.InstanceID }此外orbit 在 macOS 上还会对 Hardware UUID 做迁移检测把当前 UUID 与本地存储的文件比对若发现硬件已迁移例如 VM 快照恢复到不同物理机会删除旧的 osquery.db、orbit node key 与 Fleet desktop token 文件并重启触发重新注册见 硬件迁移检测逻辑。注册后 enroll secret 的归宿平台 keystore 迁移注册完成后enroll secret 不应继续以明文文件形式留在磁盘上。各平台行为不同macOS / Windowsenroll secret 从文件系统移除迁移到系统密钥存储——macOS 的 Keychain 与 Windows 的 Credentials Manager。从源码可见两个平台使用同一个服务名标识com.fleetdm.fleetd.enroll.secret见 keystore_darwin.go 与 keystore_windows.go。macOS 端通过 Security 框架以 GenericPassword 项存取SecItemAdd/SecItemUpdate/SecItemCopyMatchingWindows 端通过wincred库写入通用凭据。迁移流程由 readEnrollSecretFromFile 完成读取文件 → 写入/更新 keystore → 校验 keystore 中的值与文件一致 → 删除明文文件。Linux当前不支持将 enroll secret 迁移到系统密钥存储因此注册后 enroll secret 仍保留在/etc/default/orbit仅root可访问的文件中。源码还暴露了一个实用开关--disable-keystoreORBIT_DISABLE_KEYSTORE用于禁用 macOS Keychain 与 Windows Credentials Manager方便在特殊环境下回退到纯文件方案。Fleet desktop tokenGUI 用户身份的凭证orbit 启动 osquery 之后还会启动 Fleet desktop 托盘应用。注意它的运行身份以桌面 GUI 用户运行而非 root/SYSTEM。为避免把 root 级凭证暴露给 GUI 用户orbit 采用了一套独立的短时 token 机制启动 Fleet desktop 之前orbit 生成一个随机的 Fleet desktop token并通过 orbit 自己已认证的通信通道上报给 Fleet 服务器orbit 将 token 写入一个 GUI 用户可读的文件Fleet desktop 用该 token 向 Fleet 认证其请求当用户点击托盘菜单中的 My device 时Fleet desktop 会在默认浏览器中打开一个 URL其路径中包含该 token——正因 token 会进入浏览器 URLorbit 会每小时轮换一次token。从源码看token 本体是一个随机 UUID轮换逻辑位于 token ReadWriter 实现首次LoadOrGenerate时若文件不存在则生成新 tokenRotate生成新的随机 UUID 并带重试地写盘3 次尝试、5 秒间隔。token 文件被显式设为其他进程可读修正了早期版本0o600权限导致 GUI 用户无法读取的问题这正对应了GUI 用户持有 token的设计。注册完成后的通信通道总览以下是注册完成后 fleetd 各组件的认证通道updates.fleetdm.com 见下文 TUF 一节fleetd 自动更新TUF 签名保障orbit 使用 The Update FrameworkTUF执行安全的自动更新。默认情况下orbit 内嵌了 Fleet 公共根密钥只信任发布并签名于 Fleet 官方 TUF 仓库通过 HTTPS 访问的updates.fleetdm.com的更新。从 orbit.go 的更新配置逻辑 可以看到--update-urlORBIT_UPDATE_URL可指向用户自管的 TUF 服务器即更新源也可自定义--orbit-channel、--osqueryd-channel、--desktop-channel分别控制 orbit、osqueryd、Fleet desktop 的更新通道默认均为stable--update-interval控制更新检查频率默认 15 分钟另带随机化--disable-updates完全关闭自动更新开发模式--dev-mode下仍会拉取一次 osqueryd 用于初始化。fleetd 也可以定制为使用用户自管的 TUF 服务器更多细节见 orbit README。TLS 自定义 CA 证书默认情况下fleetd 使用操作系统的根 CA 证书存储同时内嵌了 Mozilla CA 证书库。fleetd 还支持设置自定义根 CA 证书用于与 Fleet 服务器及 TUF 服务器的通信——通过上文提到的--fleet-certificate与--update-tls-certificate分别指定两条链路的证书链。仓库中另有 Certificates in fleetd 指南 专门讲解该主题。mTLS 的适用边界需要注意一个重要限制Fleet 服务器本身不提供 mTLS 支持。希望在终端侧启用 mTLS 的用户必须自行搭建支持 mTLS 的负载均衡器或 TLS 终结器如 AWS ELB、nginx由它们终结 mTLS 后再转发明文/单向 TLS 到 Fleet。fleetd agent 本身提供了基础的 mTLS 客户端支持。从源码结构看相关能力体现在两处更新侧orbit 会尝试从 root-dir 加载客户端证书与私钥用于 TUF 更新服务器的认证见 update client certificate 加载Fleet 侧--fleet-desktop-alternative-browser-host标志的说明中明确提到当 Fleet 服务器启用了 TLS 客户端认证时浏览器访问可能需要使用替代的 host:port。ADE 与 Autopilot MDM 流程当 macOS/Windows 终端通过 MDM 协议Apple ADE、Windows Autopilot向 Fleet 注册时Fleet 会发送命令自动在已注册终端上安装 fleetd同时下发配置描述文件configuration profile自动配置 enroll secret 与 Fleet URL使上文描述的注册过程自动发生——无需终端上预先存在 enroll secret 文件。这一流程在源码中有对应实现macOS 上 orbit 可以启用--use-system-configuration标志循环轮询系统中的配置描述文件从中读取fleet-url与enroll-secret并写入本地状态文件每 30 秒重试一次直到读取成功见 配置描述文件读取逻辑。这也解释了为何该分支下 enroll secret 文件在配置描述文件到达前预期缺失——属于 ABM 引导阶段的正常状态而非错误。小结一次注册三份凭证各司其职组件运行身份注册期凭证运行期凭证凭证存储位置orbitroot/SYSTEMenroll secretorbit node key仅 root/SYSTEM 可读的文件osqueryroot/SYSTEM同一个 enroll secret经ENROLL_SECRET环境变量传递osquery node keyosquery 内部 RocksDBFleet desktopGUI 用户无不使用 enroll secretFleet desktop token每小时轮换GUI 用户可读的 token 文件macOS/Windows 注册完成后—enroll secret 迁移至 Keychain/Credentials Manager—com.fleetdm.fleetd.enroll.secret这套设计的安全要点在于注册期的一次性密钥enroll secret尽量短命并可从磁盘移除运行期凭证按组件隔离GUI 用户接触不到任何 root 级凭证且面向浏览器的 token 通过每小时轮换将 URL 泄露的窗口压到最小更新链路则由 TUF 签名独立于 Fleet API 之外进行完整性保障。理解了这条链路你就能在部署、排查与定制自定义 TUF、自定义 CA、--host-identifier、MDM 自动注册fleetd 时准确判断每个认证环节的预期行为。【免费下载链接】fleetOpen device management项目地址: https://gitcode.com/GitHub_Trending/fl/fleet创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Fleetd 认证机制详解Fleet 终端 Agent 的 Enroll Secret、Node Key 与 TUF 安全更新【免费下载链接】fleetOpen device management项目地址: https://gitcode.com/GitHub_Trending/fl/fleetFleetd 是运行在每台终端macOS、Windows、Linux上的 Fleet 代理负责周期性上报设备数据并执行管理任务。本文基于 Fleet 仓库中 Fleetd 认证文档 与orbitfleetd 的主守护进程源码展开系统讲解三个组件orbit、osquery、Fleet desktop各自如何认证到 Fleet 服务器从安装期的 enroll secret到运行期的 node key 与每小时轮换的 Fleet desktop token再到 TUF 安全自动更新、自定义 CA 证书与 mTLS 的适用边界。读完后你可以完整理解一次 fleetd 安装后的认证链路并能结合 orbit 入口源码 与 keystore 实现 自行验证和排查认证问题。Fleetd 的三个组件及其职责Fleetd 支持 macOS x86_64 与 Apple Silicon通过 universal 二进制、Windows 与 Linuxx86_64 和 arm64。它由三个组件构成orbit主守护进程/服务负责在终端上启动并管理所有其他组件。orbit 在 macOS/Linux 上以root运行在 Windows 上以SYSTEM服务运行。其源码位于 orbit 目录osquery为终端提供基于 SQL 的探测、监控与分析能力是设备数据的实际采集者Fleet desktop系统托盘图标应用作为 GUI 用户与 Fleet 的交互入口。它随桌面环境存在在无图形界面的服务器等场景中可以禁用或缺失。三者分别使用独立的凭证认证到 Fleet这正是理解 fleetd 认证的关键一次 enroll secret换来三份相互独立的长期凭证。TLS所有组件通信的基线所有 fleetd 组件到 Fleet 的通信都基于 HTTPS。fleetd 也支持 mTLS见下文专门一节。从源码结构看TLS 相关能力集中在 orbit 的命令行参数中见 orbit.go 中的标志定义--fleet-url环境变量ORBIT_FLEET_URLFleet 服务器地址。若未带协议前缀orbit 会自动补上https://--fleet-certificateORBIT_FLEET_CERTIFICATEFleet 服务器证书链的路径用于自定义 CA 场景--insecureORBIT_INSECURE禁用 TLS 证书校验。源码中明确校验了--insecure与--fleet-certificate不可同时指定二者互斥--update-tls-certificateORBIT_UPDATE_TLS_CERTIFICATETUF 更新服务器的证书链同理与--insecure互斥。注册密钥Enroll Secret注册期的唯一凭证终端通过 enroll secret 在注册enrollment过程中向 Fleet 认证Fleet 免费版可以定义多个 enroll secretFleet 高级版premium可以全局Unassigned定义多个 enroll secret并为每个 fleet 定义多个 enroll secretFleet 会自动将设备加入与所用 enroll secret 对应的 fleet。Enroll secret 由 Fleet 随机生成若管理员未提供或由管理员自定义Fleet 随机生成的 enroll secret 为 24 字节随机数经 base64 编码。Enroll secret 只在注册过程中用于认证。一旦终端完成注册设备改用 node key 认证下文详述。通过 fleetctl 生成 fleetd 安装包使用fleetctl生成 fleetd 安装包时管理员需要提供 enroll secretfleetctl package --typepkg \ --fleet-desktop \ --fleet-url... \ --enroll-secret...Fleet URL 和 Enroll secret 会被内嵌进生成的安装包。安装包本质上就是 orbit 的可执行文件加上这两项预置配置——这与源码中的加载逻辑吻合orbit 启动时依次尝试从命令行参数、enroll secret 文件--enroll-secret-path、系统 keystore 中读取 enroll secret见 readEnrollSecretFromFile 与 tryReadEnrollSecretFromKeystore。fleetd 中的注册过程详解安装 fleetd 包时实际执行的是orbit二进制。以下按注册链的先后顺序拆解每个环节并对照源码。orbit 的注册与 node key首次启动时enroll secret 以仅root/SYSTEM可访问的文本文件形式放在端点文件系统上。orbit第一次启动时使用该 enroll secret 向 Fleet 注册。若 enroll secret 有效Fleet 服务器会生成一个随机的 orbit node key 返回给 orbitorbit进程将该 node key 写入一个仅root/SYSTEM可访问的文本文件。注册完成后所有 orbit 相关的对 Fleet 请求都使用该 orbit node key 认证。osquery 的注册与 node keyorbit随后启动osquery守护进程同样以root/SYSTEM运行。这里有一个容易忽略的实现细节osquery 复用的是与 orbit 相同的 enroll secret但传递方式是环境变量而非明文参数。从 orbit.go 中的这段代码 可以看到enrollSecret : c.String(enroll-secret) if enrollSecret ! { const enrollSecretEnvName ENROLL_SECRET options append(options, osquery.WithEnv([]string{enrollSecretEnvName enrollSecret}), osquery.WithFlags([]string{--enroll_secret_env, enrollSecretEnvName}), ) }即 orbit 把 enroll secret 注入 osquery 子进程的环境变量ENROLL_SECRET并通过--enroll_secret_env告知 osqueryd 从该环境变量读取密钥避免密钥出现在进程命令行参数中。注册成功后Fleet 同样生成一个随机的 osquery node key 返回osquery 将 node key 存储在其内部的 RocksDB 数据库文件中仅root/SYSTEM可访问。此后 osquery 相关请求使用该 osquery node key 认证。用 Hardware UUID 把 orbit 与 osquery 绑定为一台主机Fleet 服务器使用端点的 Hardware UUID 将orbit与osquery两个进程关联起来使其在 Fleet 中识别为同一台 host。对于克隆虚拟机等 Hardware UUID 重复的系统可以改用--host-identifierinstance标志取值uuid或instance默认uuid改用 osquery 的 instance ID 作为标识。源码中该标志的定义与校验见 host-identifier flag且只有当值为instance时才会把InstanceID传入注册信息// 仅当用户以 --host-identifierinstance 运行 orbit 时才发送 osquery 的 instance_id // 否则 orbit 与 osquery 通过 Hardware UUID 匹配。 if c.String(host-identifier) instance { orbitHostInfo.OsqueryIdentifier osqueryHostInfo.InstanceID }此外orbit 在 macOS 上还会对 Hardware UUID 做迁移检测把当前 UUID 与本地存储的文件比对若发现硬件已迁移例如 VM 快照恢复到不同物理机会删除旧的 osquery.db、orbit node key 与 Fleet desktop token 文件并重启触发重新注册见 硬件迁移检测逻辑。注册后 enroll secret 的归宿平台 keystore 迁移注册完成后enroll secret 不应继续以明文文件形式留在磁盘上。各平台行为不同macOS / Windowsenroll secret 从文件系统移除迁移到系统密钥存储——macOS 的 Keychain 与 Windows 的 Credentials Manager。从源码可见两个平台使用同一个服务名标识com.fleetdm.fleetd.enroll.secret见 keystore_darwin.go 与 keystore_windows.go。macOS 端通过 Security 框架以 GenericPassword 项存取SecItemAdd/SecItemUpdate/SecItemCopyMatchingWindows 端通过wincred库写入通用凭据。迁移流程由 readEnrollSecretFromFile 完成读取文件 → 写入/更新 keystore → 校验 keystore 中的值与文件一致 → 删除明文文件。Linux当前不支持将 enroll secret 迁移到系统密钥存储因此注册后 enroll secret 仍保留在/etc/default/orbit仅root可访问的文件中。源码还暴露了一个实用开关--disable-keystoreORBIT_DISABLE_KEYSTORE用于禁用 macOS Keychain 与 Windows Credentials Manager方便在特殊环境下回退到纯文件方案。Fleet desktop tokenGUI 用户身份的凭证orbit 启动 osquery 之后还会启动 Fleet desktop 托盘应用。注意它的运行身份以桌面 GUI 用户运行而非 root/SYSTEM。为避免把 root 级凭证暴露给 GUI 用户orbit 采用了一套独立的短时 token 机制启动 Fleet desktop 之前orbit 生成一个随机的 Fleet desktop token并通过 orbit 自己已认证的通信通道上报给 Fleet 服务器orbit 将 token 写入一个 GUI 用户可读的文件Fleet desktop 用该 token 向 Fleet 认证其请求当用户点击托盘菜单中的 My device 时Fleet desktop 会在默认浏览器中打开一个 URL其路径中包含该 token——正因 token 会进入浏览器 URLorbit 会每小时轮换一次token。从源码看token 本体是一个随机 UUID轮换逻辑位于 token ReadWriter 实现首次LoadOrGenerate时若文件不存在则生成新 tokenRotate生成新的随机 UUID 并带重试地写盘3 次尝试、5 秒间隔。token 文件被显式设为其他进程可读修正了早期版本0o600权限导致 GUI 用户无法读取的问题这正对应了GUI 用户持有 token的设计。注册完成后的通信通道总览以下是注册完成后 fleetd 各组件的认证通道updates.fleetdm.com 见下文 TUF 一节fleetd 自动更新TUF 签名保障orbit 使用 The Update FrameworkTUF执行安全的自动更新。默认情况下orbit 内嵌了 Fleet 公共根密钥只信任发布并签名于 Fleet 官方 TUF 仓库通过 HTTPS 访问的updates.fleetdm.com的更新。从 orbit.go 的更新配置逻辑 可以看到--update-urlORBIT_UPDATE_URL可指向用户自管的 TUF 服务器即更新源也可自定义--orbit-channel、--osqueryd-channel、--desktop-channel分别控制 orbit、osqueryd、Fleet desktop 的更新通道默认均为stable--update-interval控制更新检查频率默认 15 分钟另带随机化--disable-updates完全关闭自动更新开发模式--dev-mode下仍会拉取一次 osqueryd 用于初始化。fleetd 也可以定制为使用用户自管的 TUF 服务器更多细节见 orbit README。TLS 自定义 CA 证书默认情况下fleetd 使用操作系统的根 CA 证书存储同时内嵌了 Mozilla CA 证书库。fleetd 还支持设置自定义根 CA 证书用于与 Fleet 服务器及 TUF 服务器的通信——通过上文提到的--fleet-certificate与--update-tls-certificate分别指定两条链路的证书链。仓库中另有 Certificates in fleetd 指南 专门讲解该主题。mTLS 的适用边界需要注意一个重要限制Fleet 服务器本身不提供 mTLS 支持。希望在终端侧启用 mTLS 的用户必须自行搭建支持 mTLS 的负载均衡器或 TLS 终结器如 AWS ELB、nginx由它们终结 mTLS 后再转发明文/单向 TLS 到 Fleet。fleetd agent 本身提供了基础的 mTLS 客户端支持。从源码结构看相关能力体现在两处更新侧orbit 会尝试从 root-dir 加载客户端证书与私钥用于 TUF 更新服务器的认证见 update client certificate 加载Fleet 侧--fleet-desktop-alternative-browser-host标志的说明中明确提到当 Fleet 服务器启用了 TLS 客户端认证时浏览器访问可能需要使用替代的 host:port。ADE 与 Autopilot MDM 流程当 macOS/Windows 终端通过 MDM 协议Apple ADE、Windows Autopilot向 Fleet 注册时Fleet 会发送命令自动在已注册终端上安装 fleetd同时下发配置描述文件configuration profile自动配置 enroll secret 与 Fleet URL使上文描述的注册过程自动发生——无需终端上预先存在 enroll secret 文件。这一流程在源码中有对应实现macOS 上 orbit 可以启用--use-system-configuration标志循环轮询系统中的配置描述文件从中读取fleet-url与enroll-secret并写入本地状态文件每 30 秒重试一次直到读取成功见 配置描述文件读取逻辑。这也解释了为何该分支下 enroll secret 文件在配置描述文件到达前预期缺失——属于 ABM 引导阶段的正常状态而非错误。小结一次注册三份凭证各司其职组件运行身份注册期凭证运行期凭证凭证存储位置orbitroot/SYSTEMenroll secretorbit node key仅 root/SYSTEM 可读的文件osqueryroot/SYSTEM同一个 enroll secret经ENROLL_SECRET环境变量传递osquery node keyosquery 内部 RocksDBFleet desktopGUI 用户无不使用 enroll secretFleet desktop token每小时轮换GUI 用户可读的 token 文件macOS/Windows 注册完成后—enroll secret 迁移至 Keychain/Credentials Manager—com.fleetdm.fleetd.enroll.secret这套设计的安全要点在于注册期的一次性密钥enroll secret尽量短命并可从磁盘移除运行期凭证按组件隔离GUI 用户接触不到任何 root 级凭证且面向浏览器的 token 通过每小时轮换将 URL 泄露的窗口压到最小更新链路则由 TUF 签名独立于 Fleet API 之外进行完整性保障。理解了这条链路你就能在部署、排查与定制自定义 TUF、自定义 CA、--host-identifier、MDM 自动注册fleetd 时准确判断每个认证环节的预期行为。【免费下载链接】fleetOpen device management项目地址: https://gitcode.com/GitHub_Trending/fl/fleet创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
