使用 Fleet 与 Okta Workflows 自动化生成每日操作系统版本报告【免费下载链接】fleetOpen device management项目地址: https://gitcode.com/GitHub_Trending/fl/fleet本文介绍如何基于 Fleet 的os_versionsREST API 拉取全公司设备的操作系统版本与主机数分布再借助 Okta Workflows 的卡片化编排API 调用、Reduce 迭代、文本合成、Slack 推送实现每日自动生成并投递 OS 报告。读完本文你将掌握 Fleet 操作系统聚合接口的调用方式与响应结构以及一套可直接复用的、可扩展至 Jira / Google Sheets 等目标端的自动化流水线方案。Okta Workflows 主流程与辅助流程总览背景审计季的 OS 盘点需求在实际场景中团队在准备 ISO27001 审计时需要随时掌握公司设备操作系统版本的分布状况——哪些版本仍在运行、哪些版本需要升级、升级进度如何。Fleet 作为基于 osquery 的开源设备管理平台允许通过 SQL 查询向设备提问而其完善的 REST API在 server/api_endpoints/api_endpoints.yml 中统一声明让开发者可以方便地拉取聚合数据并接入任意自动化系统。实现每日 OS 报告只需要一个 API 调用外加一个 Okta WorkflowFleet 负责提供权威数据Okta Workflows 负责按日调度、加工数据并投递到 Slack。Slack 中展示的每日 OS 版本报告消息第一步从 Fleet 拉取操作系统版本数据整个方案的数据源头只有一个端点GET https://your-fleet-server/api/v1/fleet/os_versions该端点在 server/service/handler.go 中注册为osVersionsEndpoint聚合统计类型在 server/datastore/mysql/aggregated_stats.go 中定义为os_versions。认证方式Fleet 的所有 API 请求都需要携带 API token 认证。按 docs/REST API/rest-api.md 的说明token 可在 Fleet UI 的My account Get API token/profile页面获取对 SSO / MFA 用户直接使用 UI 页面获取的 token 即可。随后在请求头中携带Authorization: Bearer your token使用 curl 验证curl -s \ -H Authorization: Bearer your token \ https://your-fleet-server/api/v1/fleet/os_versions响应结构端点的请求与响应结构定义在 server/service/hosts.go响应体包含count总条数、counts_updated_at聚合计数更新时间、meta分页元数据以及os_versions数组。响应示例节选如下{ count: 1, counts_updated_at: 2023-12-06T22:17:30Z, os_versions: [ { os_version_id: 123, hosts_count: 21, name: Microsoft Windows 11 Pro 23H2 10.0.22621.1234, name_only: Microsoft Windows 11 Pro 23H2, version: 10.0.22621.1234, platform: windows, generated_cpes: [], vulnerabilities_count: 1, vulnerabilities: [] } ], meta: { has_next_results: false, has_previous_results: false } }每个os_versions元素是一个OSVersion对象其字段定义在 server/fleet/hosts.go字段说明id/os_version_idOS 版本唯一标识hosts_count运行该操作系统的设备数量nameOS 名称与版本号组合如 macOS、Microsoft Windows 11 Enterprisename_only仅操作系统名称version字母数字版本号如 13.3.0、10.0.22621.1234platform平台标识windows/darwin/linux/chrome/ios/ipados/androidgenerated_cpes用于漏洞匹配的 CPE 名称目前仅 macOS 生成vulnerabilities/vulnerabilities_count与该 OS 版本关联的漏洞信息Linux 按内核漏洞聚合kernels仅 Linux 系统返回的内核列表聚合端点不返回此字段参数与排序根据 docs/REST API/rest-api.md 与请求结构server/service/hosts.go该端点支持以下查询参数参数类型说明fleet_idintegerFleet Premium按团队过滤0表示未分配主机platformstring按平台过滤darwin、windows、linux、chrome、ios、ipados、androidos_namestring按 OS 名称过滤需与os_version同时指定os_versionstring按版本号过滤需与os_name同时指定max_vulnerabilitiesinteger限制每个 OS 版本返回的漏洞条数page/per_pageinteger分页默认每页 20 条order_keystring排序字段允许hosts_count默认hosts_countorder_directionstringasc/desc默认ascafterstring基于order_key的游标翻页从 server/service/hosts.go 的实现可以看到默认按hosts_count升序返回结果且可通过order_key/order_direction调整。这也解释了原方案中为何需要Reverse卡片作者希望报告按主机数量从高到低展示最流行的版本在前而默认返回顺序与其期望相反直接翻转即可。提示counts_updated_at字段server/fleet/hosts.go表示聚合数据的统计时间可在报告中一并展示让读者知道数据的时效性。第二步Okta Workflow 总体设计Okta Workflows 采用可视化的卡片编排。整个方案拆分为主流程Main Flow与辅助流程Helper Flow主流程负责发起 API 调用、反转顺序、调用辅助流程、拼接日期与消息文本、构造 Slack 请求负载并 POST 发送辅助流程接收主流程传入的 OS 版本列表通过Reduce卡片迭代每一条记录提取关键字段并累加成一段报告文本最后Return给主流程。第三步调用 Fleet API 与反转顺序主流程首先通过 HTTP 卡片向 Fleet 发起 GET 请求URL 即为上文端点并在请求头中带上Authorization: Bearer token。拿到 JSON 响应体后由于默认返回顺序不是期望的顺序作者使用一个简单的Reverse卡片将列表反转使主机数量最多的 OS 版本排在最前面。随后将整个 JSON 列表传给辅助流程的Reduce卡片列表在该步骤被命名为osVersion。第四步在辅助流程中用 Reduce 迭代生成报告文本Reduce卡片是本次编排的核心它本质上是对传入列表的迭代器——每次循环取列表中的一个元素执行指定操作并把结果累积起来最终把整个列表折叠成一段文本。具体迭代过程如下Get Multiple卡片提取字段JSON 中的每个 OS 版本对象除host_count与version外还有其他字段如platform、name。这里只关心两个值用Get Multiple卡片配合点号dot notation路径语法分别取出host_count与version作为两个输出值供下游使用。Compose卡片拼接单行将上一步的两个值拖入Compose卡片生成一行文本。其中Memo在主流程中传入的标题文本相当于报告标题作为前缀version值两侧包裹星号*因为消息将发送到 Slack星号会被渲染为粗体。Return卡片回传结果当Reduce遍历完列表中所有元素后将累积生成的整段文本返回主流程。为了直观理解迭代过程假设列表中有三个 macOS 版本其累积效果如下第一次循环MacOS Versions and Counts: 13.3.0: 4第二次循环MacOS Versions and Counts: 13.3.0: 4 13.2.1: 2第三次循环MacOS Versions and Counts: 13.3.0: 4 13.2.1: 2 13.2.0: 2如此往复直到遍历完列表中的所有条目最终在辅助流程末尾把一整块报告文本返回给主流程。第五步格式化日期为了让报告更易读主流程需要对当前日期做格式化。使用Date to Text卡片把 ISO 格式的日期转换为人类可读的输出例如Thursday, May 4, 2023。Okta Workflows 文档中对不同的格式符号有详细说明可按需定制其他日期样式。第六步组装 Slack 消息并发送接下来是最后一公里最终Compose卡片把辅助流程返回的报告文本、格式化后的日期等所有片段拼接成完整消息正文。Construct卡片构造负载Construct卡片用于构造 key:value 形式的 JSON 对象这里按 Slackchat.postMessageAPI 的要求生成负载。除channel与text外由于使用机器人账号发送还加入了username字段。生成的负载示例{ username: Milo, channel: C0467T97NLF, text: :cat-wave: Were monitoring the upgrade to 13.3.1, here is the daily MacOS status for *Wednesday, May 3, 2023*:\n\nMacOS Versions Count:\n*13.3.1*: 471\n*13.3.0*: 4\n*13.2.1*: 2\n*13.0.0*: 1\n*12.5.1*: 6\n\n:fleet: Find out more details https://your-fleet.example.com/dashboard/mac|here! :computer: :fleet:\n }POST卡片发送最后用 HTTPPOST卡片把负载发送到 Slack 的 Webhook 或 API 地址完成消息投递。扩展与容错这套方案并不局限于 Slack换一个目的地同样的报告数据可以发送到 Jira自动创建工单、写入 Google Spreadsheet或接入任意支持 HTTP 的系统中调整调度频率该流程可以按需配置为每日运行也可随时切换为每周运行错误处理还可以解析 HTTP 返回值并利用If Error卡片对非 200 状态码做分支处理原方案为简化起见暂时跳过了这一步。总结整个自动化链条可以概括为Fleetos_versions聚合 API 提供权威的 OS 版本与主机数数据 → Okta Workflows 主流程负责调度、反转排序、格式化日期与构造 Slack 负载 → 辅助流程借助Reduce/Get Multiple/Compose/Return卡片把 JSON 列表迭代折叠成可读的报告文本 → 最终 POST 到 Slack。它同时展示了 Fleet REST API 在自动化与可编程场景下的灵活用法接口本身的排序、过滤与分页参数见 docs/REST API/rest-api.md可以支撑比全量拉取 客户端处理更精细的查询策略例如只统计某个平台platformdarwin或只关注某几个版本配合hosts_count排序即可在数据源头完成大部分加工。【免费下载链接】fleetOpen device management项目地址: https://gitcode.com/GitHub_Trending/fl/fleet创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 使用 Fleet 与 Okta Workflows 自动化生成每日操作系统版本报告
使用 Fleet 与 Okta Workflows 自动化生成每日操作系统版本报告【免费下载链接】fleetOpen device management项目地址: https://gitcode.com/GitHub_Trending/fl/fleet本文介绍如何基于 Fleet 的os_versionsREST API 拉取全公司设备的操作系统版本与主机数分布再借助 Okta Workflows 的卡片化编排API 调用、Reduce 迭代、文本合成、Slack 推送实现每日自动生成并投递 OS 报告。读完本文你将掌握 Fleet 操作系统聚合接口的调用方式与响应结构以及一套可直接复用的、可扩展至 Jira / Google Sheets 等目标端的自动化流水线方案。Okta Workflows 主流程与辅助流程总览背景审计季的 OS 盘点需求在实际场景中团队在准备 ISO27001 审计时需要随时掌握公司设备操作系统版本的分布状况——哪些版本仍在运行、哪些版本需要升级、升级进度如何。Fleet 作为基于 osquery 的开源设备管理平台允许通过 SQL 查询向设备提问而其完善的 REST API在 server/api_endpoints/api_endpoints.yml 中统一声明让开发者可以方便地拉取聚合数据并接入任意自动化系统。实现每日 OS 报告只需要一个 API 调用外加一个 Okta WorkflowFleet 负责提供权威数据Okta Workflows 负责按日调度、加工数据并投递到 Slack。Slack 中展示的每日 OS 版本报告消息第一步从 Fleet 拉取操作系统版本数据整个方案的数据源头只有一个端点GET https://your-fleet-server/api/v1/fleet/os_versions该端点在 server/service/handler.go 中注册为osVersionsEndpoint聚合统计类型在 server/datastore/mysql/aggregated_stats.go 中定义为os_versions。认证方式Fleet 的所有 API 请求都需要携带 API token 认证。按 docs/REST API/rest-api.md 的说明token 可在 Fleet UI 的My account Get API token/profile页面获取对 SSO / MFA 用户直接使用 UI 页面获取的 token 即可。随后在请求头中携带Authorization: Bearer your token使用 curl 验证curl -s \ -H Authorization: Bearer your token \ https://your-fleet-server/api/v1/fleet/os_versions响应结构端点的请求与响应结构定义在 server/service/hosts.go响应体包含count总条数、counts_updated_at聚合计数更新时间、meta分页元数据以及os_versions数组。响应示例节选如下{ count: 1, counts_updated_at: 2023-12-06T22:17:30Z, os_versions: [ { os_version_id: 123, hosts_count: 21, name: Microsoft Windows 11 Pro 23H2 10.0.22621.1234, name_only: Microsoft Windows 11 Pro 23H2, version: 10.0.22621.1234, platform: windows, generated_cpes: [], vulnerabilities_count: 1, vulnerabilities: [] } ], meta: { has_next_results: false, has_previous_results: false } }每个os_versions元素是一个OSVersion对象其字段定义在 server/fleet/hosts.go字段说明id/os_version_idOS 版本唯一标识hosts_count运行该操作系统的设备数量nameOS 名称与版本号组合如 macOS、Microsoft Windows 11 Enterprisename_only仅操作系统名称version字母数字版本号如 13.3.0、10.0.22621.1234platform平台标识windows/darwin/linux/chrome/ios/ipados/androidgenerated_cpes用于漏洞匹配的 CPE 名称目前仅 macOS 生成vulnerabilities/vulnerabilities_count与该 OS 版本关联的漏洞信息Linux 按内核漏洞聚合kernels仅 Linux 系统返回的内核列表聚合端点不返回此字段参数与排序根据 docs/REST API/rest-api.md 与请求结构server/service/hosts.go该端点支持以下查询参数参数类型说明fleet_idintegerFleet Premium按团队过滤0表示未分配主机platformstring按平台过滤darwin、windows、linux、chrome、ios、ipados、androidos_namestring按 OS 名称过滤需与os_version同时指定os_versionstring按版本号过滤需与os_name同时指定max_vulnerabilitiesinteger限制每个 OS 版本返回的漏洞条数page/per_pageinteger分页默认每页 20 条order_keystring排序字段允许hosts_count默认hosts_countorder_directionstringasc/desc默认ascafterstring基于order_key的游标翻页从 server/service/hosts.go 的实现可以看到默认按hosts_count升序返回结果且可通过order_key/order_direction调整。这也解释了原方案中为何需要Reverse卡片作者希望报告按主机数量从高到低展示最流行的版本在前而默认返回顺序与其期望相反直接翻转即可。提示counts_updated_at字段server/fleet/hosts.go表示聚合数据的统计时间可在报告中一并展示让读者知道数据的时效性。第二步Okta Workflow 总体设计Okta Workflows 采用可视化的卡片编排。整个方案拆分为主流程Main Flow与辅助流程Helper Flow主流程负责发起 API 调用、反转顺序、调用辅助流程、拼接日期与消息文本、构造 Slack 请求负载并 POST 发送辅助流程接收主流程传入的 OS 版本列表通过Reduce卡片迭代每一条记录提取关键字段并累加成一段报告文本最后Return给主流程。第三步调用 Fleet API 与反转顺序主流程首先通过 HTTP 卡片向 Fleet 发起 GET 请求URL 即为上文端点并在请求头中带上Authorization: Bearer token。拿到 JSON 响应体后由于默认返回顺序不是期望的顺序作者使用一个简单的Reverse卡片将列表反转使主机数量最多的 OS 版本排在最前面。随后将整个 JSON 列表传给辅助流程的Reduce卡片列表在该步骤被命名为osVersion。第四步在辅助流程中用 Reduce 迭代生成报告文本Reduce卡片是本次编排的核心它本质上是对传入列表的迭代器——每次循环取列表中的一个元素执行指定操作并把结果累积起来最终把整个列表折叠成一段文本。具体迭代过程如下Get Multiple卡片提取字段JSON 中的每个 OS 版本对象除host_count与version外还有其他字段如platform、name。这里只关心两个值用Get Multiple卡片配合点号dot notation路径语法分别取出host_count与version作为两个输出值供下游使用。Compose卡片拼接单行将上一步的两个值拖入Compose卡片生成一行文本。其中Memo在主流程中传入的标题文本相当于报告标题作为前缀version值两侧包裹星号*因为消息将发送到 Slack星号会被渲染为粗体。Return卡片回传结果当Reduce遍历完列表中所有元素后将累积生成的整段文本返回主流程。为了直观理解迭代过程假设列表中有三个 macOS 版本其累积效果如下第一次循环MacOS Versions and Counts: 13.3.0: 4第二次循环MacOS Versions and Counts: 13.3.0: 4 13.2.1: 2第三次循环MacOS Versions and Counts: 13.3.0: 4 13.2.1: 2 13.2.0: 2如此往复直到遍历完列表中的所有条目最终在辅助流程末尾把一整块报告文本返回给主流程。第五步格式化日期为了让报告更易读主流程需要对当前日期做格式化。使用Date to Text卡片把 ISO 格式的日期转换为人类可读的输出例如Thursday, May 4, 2023。Okta Workflows 文档中对不同的格式符号有详细说明可按需定制其他日期样式。第六步组装 Slack 消息并发送接下来是最后一公里最终Compose卡片把辅助流程返回的报告文本、格式化后的日期等所有片段拼接成完整消息正文。Construct卡片构造负载Construct卡片用于构造 key:value 形式的 JSON 对象这里按 Slackchat.postMessageAPI 的要求生成负载。除channel与text外由于使用机器人账号发送还加入了username字段。生成的负载示例{ username: Milo, channel: C0467T97NLF, text: :cat-wave: Were monitoring the upgrade to 13.3.1, here is the daily MacOS status for *Wednesday, May 3, 2023*:\n\nMacOS Versions Count:\n*13.3.1*: 471\n*13.3.0*: 4\n*13.2.1*: 2\n*13.0.0*: 1\n*12.5.1*: 6\n\n:fleet: Find out more details https://your-fleet.example.com/dashboard/mac|here! :computer: :fleet:\n }POST卡片发送最后用 HTTPPOST卡片把负载发送到 Slack 的 Webhook 或 API 地址完成消息投递。扩展与容错这套方案并不局限于 Slack换一个目的地同样的报告数据可以发送到 Jira自动创建工单、写入 Google Spreadsheet或接入任意支持 HTTP 的系统中调整调度频率该流程可以按需配置为每日运行也可随时切换为每周运行错误处理还可以解析 HTTP 返回值并利用If Error卡片对非 200 状态码做分支处理原方案为简化起见暂时跳过了这一步。总结整个自动化链条可以概括为Fleetos_versions聚合 API 提供权威的 OS 版本与主机数数据 → Okta Workflows 主流程负责调度、反转排序、格式化日期与构造 Slack 负载 → 辅助流程借助Reduce/Get Multiple/Compose/Return卡片把 JSON 列表迭代折叠成可读的报告文本 → 最终 POST 到 Slack。它同时展示了 Fleet REST API 在自动化与可编程场景下的灵活用法接口本身的排序、过滤与分页参数见 docs/REST API/rest-api.md可以支撑比全量拉取 客户端处理更精细的查询策略例如只统计某个平台platformdarwin或只关注某几个版本配合hosts_count排序即可在数据源头完成大部分加工。【免费下载链接】fleetOpen device management项目地址: https://gitcode.com/GitHub_Trending/fl/fleet创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考