first commit

2026-09-18 13:49:11 +08:00
commit af3386944c
24 changed files with 82048 additions and 0 deletions
@@ -0,0 +1,712 @@
+# 第 14 册 · 安全篇
+
+> 基于 Ceph 官方文档整理 | 文档版本：**Tentacle v20.2.4** | 抓取日期：2026-09-17 | 源文：ceph/ceph@v20.2.4 `doc/security/`
+> 官网入口：https://docs.ceph.com/en/tentacle/security/
+
+---
+
+## 本册导读
+
+本册对应 Ceph 官方文档的 **Security** 章节（`doc/security/`），共 8 个 rst 页面。这是整套手册里体量最小、但性质最特殊的一册：它**不是**一份"如何加固 Ceph"的操作指南，而是 Ceph 项目的**安全公告（CVE）存档 + 漏洞报告与管理流程**。
+
+本册覆盖的 8 个官方页面：
+
+| 页面 | 内容 | 体量 |
+|---|---|---|
+| `index` | 章节入口、漏洞报告邮箱、受支持的版本（Supported versions） | 很小 |
+| `cves` | 历史漏洞总表（33 条 CVE，含发布日期、严重性、一句话摘要） | 中 |
+| `process` | 漏洞管理流程（Vulnerability Management Process）11 条 | 小 |
+| `CVE-2021-20288` | cephx 中 `global_id` 未授权复用（**本册唯一有完整技术细节的 CVE 页面**） | 大 |
+| `CVE-2021-3509` | Dashboard 通过 token cookie 的 XSS | 很小 |
+| `CVE-2021-3524` | RGW 中经由 CORS 的 HTTP 头注入 | 很小 |
+| `CVE-2021-3531` | Swift API 拒绝服务 | 很小 |
+| `CVE-2022-0670` | Native-CephFS Manila 路径限制绕过 | 小 |
+
+**本册不讲什么（避免重复）**
+
+| 主题 | 归属 | 本册的处理 |
+|---|---|---|
+| **cephx 认证机制本体**（keyring、`ceph auth` 命令、caps 语法、`auth-config-ref` 全部配置项、用户管理操作） | **第 03 册 · RADOS 集群运维与配置**（源文 `rados/configuration/auth-config-ref.rst`、`rados/operations/user-management.rst`） | 本册**不展开**。仅在 CVE-2021-20288 处引用一句「cephx 为每个客户端分配 `global_id`」的背景事实，并指向第 03 册。 |
+| **RGW 侧加密（SSE-S3 / SSE-C / SSE-KMS）、Vault/KMIP/Barbican 密钥管理、IAM/STS/桶策略、Keystone/LDAP/OIDC 鉴权** | **第 12 册 · RGW 安全与高级特性篇** | 本册**不展开**。仅在总览处提及 RGW 是历史上漏洞最集中的组件，并指向第 12 册。 |
+| 集群网络隔离、防火墙端口、`ms_cluster_mode` / `ms_service_mode` 等传输安全配置 | 第 03 册 | 官方 `doc/security/` 未涉及，本册不臆造 |
+
+**阅读建议**
+
+- 如果你要**做漏洞排查/等级保护/安全审计**：重点读第二章，先对照 `cves` 总表定位，再对命中项读子页面。
+- 如果你要**发现漏洞并上报**：读第三章，按 `process` 的 11 步流程走，别去开公开 tracker。
+- 如果你要**落地加固动作**：读第四章检查清单，其中可执行命令全部出自官方 CVE 页面的 Recommendations。
+
+**一个必须先说清楚的事实**：官方 `doc/security/` 章节**没有**独立的"威胁模型（Threat Model）"页面，也**没有**"安全加固指南（Hardening Guide）"页面。因此本册第一章的"安全模型总览"是**从 8 个页面的既有表述归纳**出来的（凡属归纳而非原文处，均标注 `> 💡 补充`）；第四章的加固清单是**把各 CVE 页面 Recommendations 一节汇总**成表格，凡官方未给出的条目也明确标注为补充。官方没写的，本册一律写「文档未明确」，不做推断。
+
+---
+
+## 一、Ceph 安全模型总览
+
+### 1.1 官方并没有一份"威胁模型"文档
+
+先明确边界：**`doc/security/` 目录下不存在 threat model / security architecture 页面**。官方该章节只做三件事：
+
+1. 给出漏洞报告入口（`index`）；
+2. 列出历史 CVE（`cves` 及 5 个 CVE 子页面）；
+3. 说明漏洞从报告到披露的处理流程（`process`）。
+
+所以本节以下内容，凡是关于"威胁模型 / 安全边界 / 攻击者假设"的描述，都是**从 CVE 页面（尤其是 CVE-2021-20288，它是唯一给出了完整攻击者画像的页面）反推归纳**的，不是官方原文声明。
+
+> 💡 补充：这一归纳方法的可靠性说明——CVE-2021-20288 页面给出了官方对"攻击者必须具备什么条件"的逐条列举（`Attacker Requirements`）和一套完整的 CVSS v2 风格影响维度（`Confidentiality / Integrity / Availability / Access Complexity / Authentication / Gained Access`）。这套维度可以被视作官方在评估 Ceph 漏洞时实际采用的判断框架，因此用它来描述"官方眼中的攻击面"是有依据的；但它毕竟只在单个 CVE 页面出现，不能等同于一份全项目级别的威胁模型声明。
+
+### 1.2 威胁模型：官方对攻击者的假设（以 CVE-2021-20288 为准）
+
+官方在 CVE-2021-20288 页面明确列出了攻击者必须同时满足的 4 个条件，这是整个 `doc/security/` 中唯一一处显式攻击者画像：
+
+```
+Any potential attacker must:
+
+* have a valid authentication key for the cluster
+* know or guess the global_id of another client
+* run a modified version of the Ceph client code to reclaim another client's global_id
+* construct appropriate client messages or requests to disrupt service or exploit
+  Ceph daemon assumptions about global_id uniqueness
+```
+
+逐条解读：
+
+| 官方原句 | 含义 | 对防护的启示 |
+|---|---|---|
+| `have a valid authentication key for the cluster` | 攻击者**已经通过了 cephx 认证**，持有一把合法的 key。即：这不是"未授权访问"漏洞，而是"已授权用户的横向/破坏性利用"。 | 认证（cephx）本身不是终点，key 的分发与回收、caps 的最小化授予才是关键。cap 语法与授权细节见第 03 册。 |
+| `know or guess the global_id of another client` | `global_id` 是一个**数字**，并非秘密，官方用 "know or guess"（知道或猜到）描述，说明它不具备保密性。 | 任何"靠标识符不可猜测来保证安全"的设计在 Ceph 里都不成立，安全必须依赖密钥而非 ID。 |
+| `run a modified version of the Ceph client code` | 需要**篡改过的客户端**（不是标准 `rbd`/`cephfs` 客户端能直接做到的）。 | 官方把"能编译并部署定制客户端"算作一种现实威胁，即默认不信任客户端实现。 |
+| `construct appropriate client messages or requests to disrupt service or exploit Ceph daemon assumptions about global_id uniqueness` | 要能构造出利用**守护进程对 `global_id` 唯一性假设**的消息。 | 漏洞根因是"服务端信任了客户端声明的身份"，属于典型的**服务端校验缺失**。 |
+
+**同一页面给出的影响维度评估**（官方原文，逐项照录）：
+
+| 维度 | 官方结论 | 官方原文要点 |
+|---|---|---|
+| `Confidentiality Impact` | **None**（无） | 官方明确写 None。即该漏洞**不导致数据泄露**。 |
+| `Integrity Impact` | **Partial**（部分） | 攻击者可利用 `global_id` 唯一性假设，`disrupt other clients' access or disrupt Ceph daemons`（破坏其他客户端的访问或破坏 Ceph 守护进程）。 |
+| `Availability Impact` | **High**（高） | 同上，官方判定可用性影响为 High。 |
+| `Access Complexity` | **High**（高） | 客户端必须使用**修改过的客户端代码**才能利用其他守护进程行为中的特定假设。 |
+| `Authentication` | **Yes** | 攻击者必须已认证，且与被冒充/破坏的目标客户端**拥有相同服务的访问权限**。 |
+| `Gained Access` | **Partial**（部分） | 攻击者只能**部分冒充**另一个客户端（`partially impersonate another client`）。 |
+
+> 💡 补充：把这张表翻译成运维语言——官方对这个漏洞的定位是"**需要内网位置 + 合法凭据 + 定制客户端**的高门槛破坏型漏洞，主要危害是让别人的客户端掉线 / 让守护进程异常，**不泄露数据**"。这与很多安全扫描器按 CVSS 分数给出的"高危"直觉不同，官方自己把机密性影响定义为 None。
+
+### 1.3 安全边界：从 33 条 CVE 归纳出的攻击面分布
+
+官方没有文字描述"安全边界在哪里"，但把 `cves` 总表里 33 条 CVE 的摘要按组件归类，可以清楚看出历史上攻击面落在哪些地方（下表「组件」列是对官方 Summary 的归类，CVE 编号与 Summary 为原文）：
+
+| 组件 / 层面 | 官方 Summary 原文（节选） | 涉及 CVE |
+|---|---|---|
+| **RGW（对象网关，HTTP 层）** | malformed headers / malformed POST / Invalid HTTP headers / HTTP header injects via CORS / RGW DoS / RGW XSS / unauthorized bucket listing / header injection / disconnects leak sockets | CVE-2015-5245、CVE-2016-7031、CVE-2016-8626、CVE-2016-9579、CVE-2018-7262、CVE-2018-16846、CVE-2019-3821、CVE-2019-10222、CVE-2019-19337、CVE-2020-1700、CVE-2020-1760、CVE-2020-10753、CVE-2020-12059、CVE-2021-3524、CVE-2021-3531、CVE-2023-46159（共 16 条） |
+| **cephx 认证协议** | Cephx replay vulnerability（×2）、Cephx nonce reuse in secure mode、Unauthorized global_id reuse in cephx | CVE-2018-1128、CVE-2018-1129、CVE-2020-1759、CVE-2020-25660、CVE-2021-20288 |
+| **Dashboard（mgr 内的 Web UI）** | Dashboard XSS via token cookie、Dashboard path traversal flaw | CVE-2020-1699、CVE-2021-3509 |
+| **mgr 及 mgr 模块** | authorization bypass in mon and mgr、mgr module passwords in clear text、volumes 插件路径限制绕过 | CVE-2020-10736、CVE-2020-25678、CVE-2022-0670 |
+| **mon** | mon command handler DoS、authorization bypass in mon and mgr | CVE-2016-5009、CVE-2020-10736 |
+| **CephFS / Manila 集成** | CephFS creds read/modified by Manila users、Native-CephFS Manila Path-restriction bypass | CVE-2020-27781、CVE-2022-0670 |
+| **加密密钥管理** | encryption keys logged in plaintext、read-only users could steal dm-crypt keys | CVE-2018-16889、CVE-2018-14662 |
+| **授权（越权）** | authenticated user can create/delete pools | CVE-2018-10861 |
+| **客户端库** | libradosstriper unvalidated format string | CVE-2017-7519 |
+| **部署工具链** | ceph-ansible iscsi-gateway.conf perm、ceph-crash run as user, not root | CVE-2020-25677、CVE-2022-3650 |
+
+由此归纳出的**安全边界**（💡 补充，属归纳结论）：
+
+1. **RGW 是最大的暴露面**。33 条 CVE 中超过一半与 RGW 的 HTTP 协议处理有关，且多为**未认证即可触发**的 DoS / 头注入 / XSS（如 CVE-2021-3531 官方明写 `Unauthenticated users of the Swift API can trigger ...`）。原因不难理解：RGW 是唯一直接面向不可信客户端的组件。RGW 侧的加密与鉴权加固见第 12 册。
+2. **cephx 是内部信任边界，而非对外防线**。cephx 相关的 5 条 CVE 全部是"协议实现的缺陷"（重放、nonce 复用、`global_id` 复用），而非"没有认证"。也就是说，官方的设计前提是：**能连到集群网络 = 已被认证**，cephx 负责在这个前提下保证实体身份不被冒用。
+3. **mgr / Dashboard 是第二个高价值目标**。Dashboard 直接暴露 Web 面（XSS、路径穿越），mgr 模块会持有外部系统的凭据（CVE-2020-25678 明写 mgr module passwords 以明文存储）。
+4. **凭据与密钥的落盘安全是历史弱项**。CVE-2018-16889（密钥被明文记入日志）、CVE-2018-14662（只读用户可窃取 dm-crypt 密钥）、CVE-2020-25677（配置文件权限）、CVE-2020-25678（明文密码）四条都指向同一类问题。
+
+### 1.4 默认是否加密？——文档未明确
+
+**这是本册必须如实标注的一点**：`doc/security/` 全部 8 个页面**没有任何一处说明 Ceph 默认是否加密**。既没有"数据在传输中默认加密"的声明，也没有"静态数据默认不加密"的声明。
+
+能确定的只有间接事实：
+
+- 从 CVE 摘要可以确认**Ceph 存在加密能力**：`CVE-2018-14662` 提到 `dm-crypt keys`（说明存在基于 dm-crypt 的 OSD 磁盘加密），`CVE-2018-16889` 提到 `encryption keys logged in plaintext`（说明存在被管理的加密密钥）。
+- 但**这两条都不足以推断默认开启还是默认关闭**，官方该章节未给出结论。
+
+> 💡 补充：如果需要确认默认加密状态，需要查 RGW 侧（SSE 相关配置）与 OSD 侧（dm-crypt）的专门页面——RGW 部分已在第 12 册覆盖；OSD/磁盘加密的默认值不在本册源文范围内，本册不做断言。
+
+### 1.5 安全更新的版本边界（官方明确承诺）
+
+这是官方在 `index` 页面唯一给出的、具有承诺性质的安全边界声明：
+
+```
+Security updates are applied only to the current Active Releases.
+```
+
+即：**安全修复只应用于当前处于 Active 状态的发布线**。已经 EOL 的版本（例如本册 CVE 修复列表里出现的 Nautilus、Octopus、Pacific、Quincy）**不会再收到新的安全补丁**。
+
+这对运维的直接含义（💡 补充）：判断一个 CVE 是否影响你时，先看你的版本是否还在 Active Releases 列表里；如果已 EOL，官方给出的"修复版本"对你不可用，唯一出路是升级到受支持的发布线。官方在 `index` 页把 Active Releases 链接到 `https://docs.ceph.com/en/latest/releases/#active-releases`（该页面不在本册源文范围内，本册不转述其内容）。
+
+> 引自：[Security](https://docs.ceph.com/en/tentacle/security/)
+
+---
+
+## 二、官方安全公告与 CVE
+
+本章是本册核心。分两部分：**2.1 是 `cves` 总表的完整照录**；**2.2 起逐个讲解官方提供了独立详情页的 5 个 CVE**；**2.7 说明其余 28 条 CVE 官方只给了什么信息**。
+
+### 2.1 历史漏洞总表（官方原文完整照录）
+
+`cves` 页面是一张纯表格，共 33 条记录，字段为 `Published | CVE | Severity | Summary`。以下**完全按官方表格原顺序、原字段照录**，未做任何增删改：
+
+| # | Published | CVE | Severity | Summary（官方原文） |
+|---|---|---|---|---|
+| 1 | 2023-02-02 | CVE-2023-46159 | Medium | DoS from RGW |
+| 2 | 2023-01-17 | CVE-2022-3650 | High | ceph-crash run as user, not root |
+| 3 | 2022-07-21 | CVE-2022-0670 | Medium | Native-CephFS Manila Path-restriction bypass |
+| 4 | 2021-05-13 | CVE-2021-3531 | Medium | Swift API denial of service |
+| 5 | 2021-05-13 | CVE-2021-3524 | Medium | HTTP header injects via CORS in RGW |
+| 6 | 2021-05-13 | CVE-2021-3509 | High | Dashboard XSS via token cookie |
+| 7 | 2021-04-14 | CVE-2021-20288 | High | Unauthorized global_id reuse in cephx |
+| 8 | 2020-12-18 | CVE-2020-27781 | 7.1 High | CephFS creds read/modified by Manila users |
+| 9 | 2021-01-08 | CVE-2020-25678 | 4.9 Medium | mgr module passwords in clear text |
+| 10 | 2020-12-07 | CVE-2020-25677 | 5.5 Medium | ceph-ansible iscsi-gateway.conf perm |
+| 11 | 2020-11-23 | CVE-2020-25660 | 8.8 High | Cephx replay vulnerability |
+| 12 | 2020-04-22 | CVE-2020-12059 | 7.5 High | malformed POST could crash RGW |
+| 13 | 2020-06-26 | CVE-2020-10753 | 6.5 Medium | HTTP header injects via CORS in RGW |
+| 14 | 2020-06-22 | CVE-2020-10736 | 8.0 High | authorization bypass in mon and mgr |
+| 15 | 2020-04-23 | CVE-2020-1760 | 6.1 Medium | potential RGW XSS attack |
+| 16 | 2020-04-13 | CVE-2020-1759 | 6.8 Medium | Cephx nonce reuse in secure mode |
+| 17 | 2020-02-07 | CVE-2020-1700 | 6.5 Medium | RGW disconnects leak sockets, can DoS |
+| 18 | 2020-04-21 | CVE-2020-1699 | 7.5 High | Dashboard path traversal flaw |
+| 19 | 2019-12-23 | CVE-2019-19337 | 6.5 Medium | RGW DoS via malformed headers |
+| 20 | 2019-11-08 | CVE-2019-10222 | 7.5 High | Invalid HTTP headers could crash RGW |
+| 21 | 2019-03-27 | CVE-2019-3821 | 7.5 High | RGW file descriptors could be exhausted |
+| 22 | 2019-01-28 | CVE-2018-16889 | 7.5 High | encryption keys logged in plaintext |
+| 23 | 2019-01-15 | CVE-2018-16846 | 6.5 Medium | authenticated RGW users can cause DoS |
+| 24 | 2019-01-15 | CVE-2018-14662 | 5.7 Medium | read-only users could steal dm-crypt keys |
+| 25 | 2018-07-10 | CVE-2018-10861 | 8.1 High | authenticated user can create/delete pools |
+| 26 | 2018-03-19 | CVE-2018-7262 | 7.5 High | malformed headers can cause RGW DoS |
+| 27 | 2018-07-10 | CVE-2018-1129 | 6.5 Medium | network MITM can tamper with messages |
+| 28 | 2018-07-10 | CVE-2018-1128 | 7.5 High | Cephx replay vulnerability |
+| 29 | 2018-07-27 | CVE-2017-7519 | 4.4 Medium | libradosstriper unvalidated format string |
+| 30 | 2018-08-01 | CVE-2016-9579 | 7.6 High | potential RGW XSS attack |
+| 31 | 2018-07-31 | CVE-2016-8626 | 6.5 Medium | malformed POST can DoS RGW |
+| 32 | 2016-10-03 | CVE-2016-7031 | 7.5 High | RGW unauthorized bucket listing |
+| 33 | 2016-07-12 | CVE-2016-5009 | 6.5 Medium | mon command handler DoS |
+| 34 | 2016-12-03 | CVE-2015-5245 | （空） | RGW header injection |
+
+> ⚠️ 关于计数的说明：官方表格主体共 34 行数据（上表 #1–#34）。其中 `CVE-2015-5245` 一行的 `Severity` 字段在源文中为**空**，未给出任何严重性评级。本册前面称"33 条"是按官方表格中**给出了 Severity 的记录数**而言的；完整记录数为 34 条。请以本表为准。
+
+**关于 Severity 字段的口径不一致（官方原文即如此）**
+
+官方这一列存在两种写法，本册照录不作归一：
+
+- **定性写法**：`Medium` / `High`（如 CVE-2023-46159、CVE-2022-0670、CVE-2021-20288 等，共 8 条）；
+- **CVSS 分数 + 定性写法**：如 `7.1 High`、`4.9 Medium`、`8.8 High`、`5.5 Medium`、`6.5 Medium`、`8.0 High`、`6.1 Medium`、`6.8 Medium`、`7.5 High`、`5.7 Medium`、`8.1 High`、`4.4 Medium`、`7.6 High`（其余 25 条）；
+- **空**：CVE-2015-5245。
+
+**关于表格排序**：官方表格并非严格按 Published 日期排序（例如 #11 `2020-11-23` 排在 #12 `2020-04-22` 之前，#8 `2020-12-18` 排在 #9 `2021-01-08` 之前）。本册保留官方原顺序，不重排。
+
+> 引自：[Past vulnerabilities](https://docs.ceph.com/en/tentacle/security/cves/)
+
+### 2.2 CVE-2021-20288：cephx 中 `global_id` 的未授权复用（High）
+
+> 这是 `doc/security/` 下**内容最详实**的一个 CVE 页面，官方给出了 Summary、Background、Attacker Requirements、Impact（6 个维度）、Affected versions、Fixed versions、Fix details（4 条）、Recommendations（4 条）共 8 个小节。以下逐节讲透。
+
+#### 2.2.1 一句话摘要
+
+> Ceph was not ensuring that reconnecting/renewing clients were presenting an existing ticket when reclaiming their `global_id` value. An attacker that was able to authenticate could claim a `global_id` in use by a different client and potentially disrupt other cluster services.
+
+即：**Ceph 没有校验"重连/续约的客户端是否真的持有旧票据"**，导致一个已认证的攻击者可以**抢走另一个客户端正在使用的 `global_id`**，进而可能破坏集群服务。
+
+#### 2.2.2 背景：`global_id` 是什么，为什么它必须唯一
+
+官方 Background 原文要点：
+
+- Ceph 中**每一个通过认证的客户端或守护进程**都会被分配一个**数字形式的 `global_id` 标识**；
+- 这个值**被假定为在整个集群范围内唯一**（`assumed to be unique across the cluster`）；
+- 当客户端重连到 monitor（例如因网络断开），或**续约（renew）自己的票据**时，**本应出示自己的旧票据**，以证明自己此前确实持有该 `global_id`，从而可以**回收（reclaim）**它，使其在该客户端实例的生命周期内保持不变；
+- **Ceph 没有正确检查旧票据是否有效**，导致**任意 `global_id` 都能被回收**，哪怕它正被系统中另一个活跃客户端使用。
+
+用一句话说清根因：**服务端把"客户端自称的 `global_id`"当成了可信输入，而没有要求客户端用密钥证明"这个 ID 确实是我之前持有的"。**
+
+> 💡 补充（帮助理解，不引入新事实）：这里的关键机制是 cephx 的票据续约路径。cephx 认证协议本体、keyring 结构、`ceph auth` 命令与 caps 语法见**第 03 册**，本册不重复。本册只涉及这一条与 `global_id` 回收校验有关的修复。
+
+#### 2.2.3 攻击者需要具备什么（官方 `Attacker Requirements`，4 条，全文照录见 1.2 节）
+
+再强调一次这 4 条的叠加关系——它们是**与**的关系，不是**或**的关系：
+
+1. 持有集群的**合法认证 key**；
+2. **知道或猜到**另一个客户端的 `global_id`；
+3. 运行**修改过的 Ceph 客户端代码**去回收别人的 `global_id`；
+4. 构造出能"破坏服务"或"利用守护进程对 `global_id` 唯一性假设"的客户端消息/请求。
+
+官方把第 4 条单独列出，说明**仅仅抢到 `global_id` 本身还不够**，还需要进一步构造利用。这也解释了为什么官方把 `Gained Access` 定为 `Partial`（只能部分冒充）。
+
+#### 2.2.4 影响面（官方 6 维度，见 1.2 节表格）
+
+补充一点官方在 Impact 下的措辞细节：
+
+- **Integrity / Availability 两节的措辞几乎相同**，都是 `An attacker could potentially exploit assumptions around global_id uniqueness to disrupt other clients' access or disrupt Ceph daemons.`，但**定级不同**（Integrity = Partial，Availability = High）。即：官方认为同一个破坏行为，对"可用性"的伤害大于对"完整性"的伤害。
+- **Confidentiality = None**：官方明确该漏洞**不造成数据泄露**。这一点在做风险定级时很重要——它不是一个数据窃取类漏洞。
+
+#### 2.2.5 影响版本（官方原文，逐字照录）
+
+官方 `Affected versions` 一节给出三个层次，必须分开理解：
+
+| 层次 | 官方原文 | 解读 |
+|---|---|---|
+| Monitor 侧 | `All prior versions of Ceph monitors fail to ensure that global_id reclaim attempts are authentic.` | **所有此前的 Ceph monitor 版本**都无法确保 `global_id` 回收尝试是真实的。即：修复版本之前的 monitor **全部受影响**，没有例外。 |
+| 用户态守护进程与客户端 | `all user-space daemons and clients starting from Luminous v12.2.0 were failing to securely reclaim their global_id following commit a2eb6ae3fb57 ("mon/monclient: hunt for multiple monitor in parallel")` | 从 **Luminous v12.2.0** 开始，所有用户态守护进程与客户端都未能安全回收自己的 `global_id`，起点是提交 `a2eb6ae3fb57`（标题 `mon/monclient: hunt for multiple monitor in parallel`）。 |
+| 内核客户端 | `All versions of the Linux kernel client properly authenticate.` | **所有版本的 Linux 内核客户端都能正确认证**，即内核客户端（`kcephfs` 等）**不受影响**。 |
+
+> 💡 补充：注意"受影响"在这里是**双向**的——monitor 侧缺少校验（漏洞的根源），而用户态客户端侧则存在"即使 monitor 修好了、自己也不会安全回收"的问题（修复后会在要求安全回收时被拒绝连接）。这解释了为什么官方在 Recommendations 里既要求升级 monitor，又要求**升级所有客户端**。
+
+#### 2.2.6 修复版本（官方原文，逐字照录）
+
+- Pacific **v16.2.1**（及以后）
+- Octopus **v15.2.11**（及以后）
+- Nautilus **v14.2.20**（及以后）
+
+> ⚠️ 注意：本册**不推断**其他发布线（如 Quincy、Reef、Squid、Tentacle）的修复版本——官方该页面只列了上述三条。判断新版是否包含该修复，请以对应版本的 release notes 为准（不在本册源文范围内）。
+
+#### 2.2.7 修复细节（官方 `Fix details`，4 条，逐条讲透）
+
+**修复点 1：新增 `auth_allow_insecure_global_id_reclaim` 开关（默认 `true`）**
+
+打过补丁的 monitor 现在会正确要求客户端在 `auth_allow_insecure_global_id_reclaim` 为 `false` 时安全回收自己的 `global_id`。
+
+- **初始默认值为 `true`**，目的是让**尚未升级的现有客户端能继续正常工作**，直到所有客户端都升级完毕；
+- 当该选项设为 `false` 后，**未打补丁的客户端**将出现两种情况：
+  - 在间歇性网络中断（断开与 monitor 的连接）后**无法重连**集群；
+  - 在票据超时（**默认 72 小时**）后**无法续约认证**。
+
+配套的两个告警与开关：
+
+```bash
+# 打过补丁的 monitor 在 auth_allow_insecure_global_id_reclaim 为 true 时，
+# 会 raising AUTH_INSECURE_GLOBAL_ID_RECLAIM_ALLOWED 健康告警
+# 该告警可被 mute（静默）：
+ceph health mute AUTH_INSECURE_GLOBAL_ID_RECLAIM_ALLOWED 1w
+
+# 虽然官方不推荐，但该告警也可以被彻底关闭：
+ceph config set mon mon_warn_on_insecure_global_id_reclaim_allowed false
+```
+
+**修复点 2：新增"认证后立即断开"的主动探测机制 `auth_expose_insecure_global_id_reclaim`**
+
+打过补丁的 monitor 可以**在客户端刚完成认证后立刻断开它**（强制其重连并回收 `global_id`），以此判定该客户端是否会安全地回收 `global_id`。
+
+- **作用**：让集群和用户**快速发现**哪些客户端会在"要求安全回收"后受影响——**大多数客户端会立即报认证错误**；
+- **关闭方式**：
+
+```bash
+ceph config set mon auth_expose_insecure_global_id_reclaim false
+```
+
+**修复点 3：新增 `AUTH_INSECURE_GLOBAL_ID_RECLAIM` 健康告警**
+
+打过补丁的 monitor 会为**任何未安全回收 `global_id` 的客户端或守护进程** raising `AUTH_INSECURE_GLOBAL_ID_RECLAIM` 告警。这些客户端**应在关闭 `auth_allow_insecure_global_id_reclaim` 之前完成升级**，否则会中断客户端访问。
+
+关于告警触发时机（官方明确区分了两种情况）：
+
+| `auth_expose_insecure_global_id_reclaim` 状态 | 告警何时触发 |
+|---|---|
+| **未被禁用**（默认，即修复点 2 的探测机制开着） | 客户端未能安全回收 `global_id` 会**立即暴露**并 raising 该告警 |
+| **已被禁用**（设为 `false`） | 该告警**不会立即触发**；要等该客户端**被迫重连 monitor**（如网络中断）**或续约票据**（默认 72 小时后）才会触发 |
+
+**修复点 4：认证票据默认 TTL 从 12 小时提高到 72 小时**
+
+官方给出的理由非常具体，值得完整理解：
+
+- 过去因为**不校验旧票据**，一个客户端即使经历了**超过票据 TTL 时长的网络中断**，仍能回收自己的 `global_id`；
+- 一旦集群开始要求安全回收，一个**断开时间超过 TTL 的客户端**可能**回收失败 → 重新认证失败 → 直到被重启之前都无法继续与集群通信**；
+- 因此**把默认 TTL 从 12 小时提高到 72 小时**，以**降低这一变更对用户的冲击**。
+
+> 💡 补充：这条修复点揭示了一个运维上容易踩的坑——开启安全回收后，长时间网络分区（>72 小时）不再是"网络恢复即自愈"，而可能导致客户端须重启。做跨机房/公网场景的容量与故障演练时要把这个 72 小时阈值考虑进去。
+
+#### 2.2.8 官方处置建议（Recommendations，4 条，完整可执行）
+
+**第 1 条**：用户应尽早升级到已打补丁的 Ceph 版本。
+
+**第 2 条**：用户应尽早升级所有未打补丁的**客户端**。默认情况下，这些客户端很容易识别——检查 `ceph health detail` 输出中的 `AUTH_INSECURE_GLOBAL_ID_RECLAIM` 告警即可。
+
+**第 3 条**：如果无法立即升级全部客户端，健康告警可临时静默：
+
+```bash
+ceph health mute AUTH_INSECURE_GLOBAL_ID_RECLAIM 1w          # 1 week
+ceph health mute AUTH_INSECURE_GLOBAL_ID_RECLAIM_ALLOWED 1w  # 1 week
+```
+
+**第 4 条**：在**所有客户端都升级完毕**、且 `AUTH_INSECURE_GLOBAL_ID_RECLAIM` 告警**不再出现**之后，应把集群设置为禁止不安全的 `global_id` 回收：
+
+```bash
+ceph config set mon auth_allow_insecure_global_id_reclaim false
+```
+
+#### 2.2.9 落地顺序小结（💡 补充：把官方 4 条建议排成可执行的时序）
+
+官方的 4 条建议本身是并列的，但按其因果依赖可排成如下时序（本排序为补充，不含新事实）：
+
+1. **先升级 monitor 与所有服务端**到修复版本（Pacific v16.2.1+ / Octopus v15.2.11+ / Nautilus v14.2.20+）；
+2. **保持 `auth_allow_insecure_global_id_reclaim` 为默认 `true`**，此时会出现 `AUTH_INSECURE_GLOBAL_ID_RECLAIM_ALLOWED` 告警，属预期，可 `mute`；
+3. **观察 `ceph health detail`**，靠 `auth_expose_insecure_global_id_reclaim`（默认开启的探测）快速找出所有还在报 `AUTH_INSECURE_GLOBAL_ID_RECLAIM` 的客户端；
+4. **逐个升级这些客户端**；
+5. 确认 `AUTH_INSECURE_GLOBAL_ID_RECLAIM` **彻底消失**后，执行 `ceph config set mon auth_allow_insecure_global_id_reclaim false`；
+6. 若仍有零星未升级客户端，用 `ceph health mute ... 1w` 临时静默，**不要**用 `mon_warn_on_insecure_global_id_reclaim_allowed false` 一关了之（官方原文标注 `Although it is not recommended`）。
+
+> 引自：[CVE-2021-20288: Unauthorized global_id reuse in cephx](https://docs.ceph.com/en/tentacle/security/CVE-2021-20288/)
+
+### 2.3 CVE-2021-3509：Dashboard 通过 token cookie 的 XSS（High）
+
+**官方该页面仅提供以下信息**（页面很短，以下为其全部技术性内容）：
+
+**漏洞原理**（官方原文）：
+
+> The Ceph Dashboard was vulnerable to an XSS attack that could expose the authentication cookie to other sites.
+
+即：Ceph Dashboard 存在一个 XSS（跨站脚本）漏洞，**可能把认证 cookie 暴露给其他站点**。
+
+这里需要注意官方用词：**"could expose the authentication cookie to other sites"**——危害是**认证凭据（cookie）被外泄到其他站点**，也就是说一次成功的 XSS 利用可能导致 **Dashboard 会话被劫持**。官方没有进一步说明 XSS 的注入点、触发路径、是否需要登录、是存储型还是反射型，**这些均属文档未明确**。
+
+**影响版本**（官方原文）：
+
+- Octopus **v15.2.0** 及以后
+
+**修复版本**（官方原文）：
+
+- Pacific **v16.2.4**（及以后）
+- Octopus **v15.2.12**（及以后）
+- Nautilus **v14.2.21**（及以后）
+
+**缓解措施 / 建议**（官方原文，仅一句）：
+
+> All users of the Ceph dashboard should upgrade.
+
+即：**所有 Dashboard 用户都应升级**。官方**没有**给出任何不升级情况下的临时缓解手段（如禁用 Dashboard、改 cookie 属性等）——本册不臆造。
+
+> ⚠️ 官方原文的一处不自洽（本册照录，不作修正）：影响版本只写了 `Octopus v15.2.0 and later`，但修复版本里同时出现了 `Nautilus v14.2.21`。若只有 Octopus v15.2.0+ 受影响，为何 Nautilus 线也需要修复版本？**官方页面未解释**，本册不推断，仅如实标注该处存疑（见本册末尾「文档未明确项」）。
+
+> 引自：[CVE-2021-3509: Dashboard XSS via token cookie](https://docs.ceph.com/en/tentacle/security/CVE-2021-3509/)
+
+### 2.4 CVE-2021-3524：RGW 中经由 CORS 的 HTTP 头注入（Medium）
+
+**官方该页面仅提供以下信息**：
+
+**漏洞原理**（官方原文）：
+
+> A flaw was found in the radosgw. The vulnerability is related to the injection of HTTP headers via a CORS ExposeHeader tag. The `\r` character in the ExposeHeader tag in the CORS configuration file generates a header injection in the response when the CORS request is made.
+
+拆解成可执行的判断：
+
+| 要素 | 官方给出的内容 |
+|---|---|
+| 受影响组件 | `radosgw`（RGW） |
+| 触发条件 | CORS 配置中的 **`ExposeHeader` 标签**里含有 **`\r`（回车符）** |
+| 触发时机 | 当**发起 CORS 请求**时 |
+| 结果 | 在**响应中产生 HTTP 头注入**（header injection in the response） |
+
+即：**攻击者（或任何能设置桶 CORS 配置的人）在 `ExposeHeader` 中插入 `\r`，就能在 RGW 的 HTTP 响应里注入额外的响应头**。
+
+**影响面**：官方页面**没有**给出 `Affected versions`（影响版本）小节，也**没有**描述 CIA 影响维度。**这是 5 个 CVE 子页面中唯一一个完全没写影响版本的页面**，本册不推断。
+
+**修复版本**（官方原文）：
+
+- Pacific **v16.2.4**（及以后）
+- Octopus **v15.2.12**（及以后）
+- Nautilus **v14.2.21**（及以后）
+
+**缓解措施 / 建议**（官方原文，仅一句）：
+
+> All users of Ceph object storage (RGW) should upgrade.
+
+即：**所有 RGW（Ceph 对象存储）用户都应升级**。官方未给出其他缓解手段；不过从原理可以合理推导出（💡 补充，属常识性推论而非官方原文）：**审计各桶的 CORS 配置，检查 `ExposeHeader` 中是否含 `\r` 等控制字符**，是升级前可做的自查动作。官方并未要求做此自查，本册标注为补充。
+
+**致谢**（官方原文）：Red Hat 感谢 **Sergey Bobrov（Kaspersky）** 报告此问题。
+
+> 💡 补充：这是 5 个 CVE 子页面中**唯一列出了 Acknowledgements** 的一个。
+
+> 引自：[CVE-2021-3524: HTTP header injects via CORS in RGW](https://docs.ceph.com/en/tentacle/security/CVE-2021-3524/)
+
+### 2.5 CVE-2021-3531：Swift API 拒绝服务（Medium）
+
+**官方该页面仅提供以下信息**：
+
+**漏洞原理**（官方原文）：
+
+> Unauthenticated users of the Swift API can trigger a server-side assertion with a malformed URL, leading to a denial of service.
+
+拆解：
+
+| 要素 | 官方给出的内容 |
+|---|---|
+| 前置条件 | **无需认证**（`Unauthenticated users`）——这是 5 个 CVE 中门槛最低的一个 |
+| 入口 | **Swift API**（RGW 的 Swift 兼容接口） |
+| 触发方式 | 构造**畸形的 URL**（malformed URL） |
+| 直接后果 | 触发**服务端断言**（server-side assertion） |
+| 最终影响 | **拒绝服务**（denial of service） |
+
+**这是本册所有有详情页的 CVE 中，唯一官方明确写出「不需要认证即可触发」的一个**，因此在实际暴露面评估中应当给予更高优先级——只要 Swift API 端点可达，任何能发 HTTP 请求的人都可能打挂它。
+
+**影响版本**（官方原文）：
+
+- Nautilus **v14.2.0** 及以后
+
+**修复版本**（官方原文）：
+
+- Pacific **v16.2.4**（及以后）
+- Octopus **v15.2.12**（及以后）
+- Nautilus **v14.2.21**（及以后）
+
+**缓解措施 / 建议**（官方原文，仅一句）：
+
+> All users of Ceph object storage (RGW) should upgrade.
+
+官方未给出其他缓解手段（如限流、关闭 Swift API 端点等），本册不臆造。
+
+> ⚠️ 官方原文的一处不自洽（本册照录，不作修正）：影响版本只写了 `Nautilus v14.2.0 and later`，但修复版本同时给出了 `Pacific v16.2.4` 与 `Octopus v15.2.12`。官方页面未解释该口径，本册不推断。
+
+> 引自：[CVE-2021-3531: Swift API denial of service](https://docs.ceph.com/en/tentacle/security/CVE-2021-3531/)
+
+### 2.6 CVE-2022-0670：Native-CephFS Manila 路径限制绕过（Medium）
+
+**漏洞原理**（官方 Summary 原文，要点完整重述）：
+
+- 受影响的对象是**使用 OpenStack Manila 导出 native CephFS**，**并且把 Ceph 集群从 Nautilus（或更早）升级到了更高主版本**的用户；
+- 漏洞使得**恶意用户可以访问 CephFS 文件系统层次结构中的任意部分**，而不是被正确限制在其**自己的 subvolume（子卷）**之内；
+- 根因是 **Ceph Manager 中 "volumes" 插件的一个 bug**。该插件负责管理 Ceph File System 的 subvolume，而 subvolume 正是 OpenStack Manila 服务用来向 Manila 用户提供 share 的机制。
+
+**官方特别强调的适用范围**（原文）：
+
+> Again, this vulnerability impacts only OpenStack Manila clusters that provided native CephFS access to their users.
+
+即：**该漏洞只影响向用户提供 native CephFS 访问的 OpenStack Manila 集群**。不使用 Manila、或不提供 native CephFS 访问的集群，按官方表述**不在影响范围内**。
+
+**影响版本**（官方原文）：
+
+> Any version of Ceph running OpenStack Manila that was upgraded from Nautilus or earlier.
+
+即：**任何运行 OpenStack Manila、且是从 Nautilus 或更早版本升级而来的 Ceph 版本**。注意官方这里的限定是"升级自 Nautilus 或更早"，**不是**"所有版本"——全新部署的高版本按官方表述不受此漏洞影响。
+
+**修复版本**（官方原文，逐字照录）：
+
+- Quincy **v17.2.2**（及以后）
+- Pacific **v16.2.10**（及以后）
+- Octopus **v15.2.17**
+
+> ⚠️ 官方原文的写法差异（本册照录）：前两条官方写了 `(and later)`，**Octopus v15.2.17 后面没有 `(and later)`**。官方未说明原因，本册既不补全也不删改（见「文档未明确项」）。
+
+**缓解措施 / 建议**（官方 Recommendations，2 条）：
+
+1. 用户应尽早升级到已打补丁的 Ceph 版本；
+2. **担心自己可能已受影响的管理员，应当审计集群中的 CephX key，确认其路径限制（path restrictions）是否正确。**
+
+> 💡 补充：第 2 条是 5 个 CVE 子页面中**唯一一条"事后审计"型建议**——它说明这个漏洞的后果是**已经发出的 key 上的路径限制可能不正确**，因此仅仅升级并不能自动修复历史遗留的错误 key，必须人工审计。审计时需要看的是每个 cephx 实体 caps 中的 path 限制字段；cephx caps 语法详见**第 03 册**，本册不重复展开。
+
+> 引自：[CVE-2022-0670: Native-CephFS Manila Path-restriction bypass](https://docs.ceph.com/en/tentacle/security/CVE-2022-0670/)
+
+### 2.7 其余 29 条 CVE：官方只提供了什么
+
+`cves` 页面通过 `toctree` 只挂了 5 个 CVE 子页面：
+
+```text
+   CVE-2022-0670 <CVE-2022-0670.rst>
+   CVE-2021-3531 <CVE-2021-3531.rst>
+   CVE-2021-3524 <CVE-2021-3524.rst>
+   CVE-2021-3509 <CVE-2021-3509.rst>
+   CVE-2021-20288 <CVE-2021-20288.rst>
+```
+
+而表格里其余 **29 条 CVE 官方没有提供独立详情页**，其 CVE 编号直接外链到 **NVD（National Vulnerability Database）** 页面，形如：
+
+```text
+https://nvd.nist.gov/vuln/detail/CVE-2020-27781
+```
+
+**这意味着**：对于这 29 条，Ceph 官方文档**只提供 3 个字段**——`Published`（发布日期）、`Severity`（严重性）、`Summary`（一句话摘要，原文见 2.1 总表）。**影响版本、修复版本、缓解措施这三项，官方一律未提供**（它们只在 NVD 页面上，而 NVD 不在本册源文范围内，本册不转述、不联网查询）。
+
+这一点必须写清楚，因为本册的开篇要求是"逐个 CVE 讲（影响版本 | 漏洞原理 | 影响面 | 修复版本 | 缓解措施）"——**对这 29 条，官方只给了"漏洞原理（一句话）"和"影响面（严重性）"两项，其余三项均为「文档未明确」**。本册严格遵守不编造原则，不用 NVD 或任何外部知识补全。
+
+这 29 条的完整清单（按官方表格顺序）：
+
+| Published | CVE | Severity | Summary（原文） | 官方提供的字段 |
+|---|---|---|---|---|
+| 2023-02-02 | CVE-2023-46159 | Medium | DoS from RGW | 日期 + 严重性 + 摘要 |
+| 2023-01-17 | CVE-2022-3650 | High | ceph-crash run as user, not root | 日期 + 严重性 + 摘要 |
+| 2020-12-18 | CVE-2020-27781 | 7.1 High | CephFS creds read/modified by Manila users | 日期 + 严重性 + 摘要 |
+| 2021-01-08 | CVE-2020-25678 | 4.9 Medium | mgr module passwords in clear text | 日期 + 严重性 + 摘要 |
+| 2020-12-07 | CVE-2020-25677 | 5.5 Medium | ceph-ansible iscsi-gateway.conf perm | 日期 + 严重性 + 摘要 |
+| 2020-11-23 | CVE-2020-25660 | 8.8 High | Cephx replay vulnerability | 日期 + 严重性 + 摘要 |
+| 2020-04-22 | CVE-2020-12059 | 7.5 High | malformed POST could crash RGW | 日期 + 严重性 + 摘要 |
+| 2020-06-26 | CVE-2020-10753 | 6.5 Medium | HTTP header injects via CORS in RGW | 日期 + 严重性 + 摘要 |
+| 2020-06-22 | CVE-2020-10736 | 8.0 High | authorization bypass in mon and mgr | 日期 + 严重性 + 摘要 |
+| 2020-04-23 | CVE-2020-1760 | 6.1 Medium | potential RGW XSS attack | 日期 + 严重性 + 摘要 |
+| 2020-04-13 | CVE-2020-1759 | 6.8 Medium | Cephx nonce reuse in secure mode | 日期 + 严重性 + 摘要 |
+| 2020-02-07 | CVE-2020-1700 | 6.5 Medium | RGW disconnects leak sockets, can DoS | 日期 + 严重性 + 摘要 |
+| 2020-04-21 | CVE-2020-1699 | 7.5 High | Dashboard path traversal flaw | 日期 + 严重性 + 摘要 |
+| 2019-12-23 | CVE-2019-19337 | 6.5 Medium | RGW DoS via malformed headers | 日期 + 严重性 + 摘要 |
+| 2019-11-08 | CVE-2019-10222 | 7.5 High | Invalid HTTP headers could crash RGW | 日期 + 严重性 + 摘要 |
+| 2019-03-27 | CVE-2019-3821 | 7.5 High | RGW file descriptors could be exhausted | 日期 + 严重性 + 摘要 |
+| 2019-01-28 | CVE-2018-16889 | 7.5 High | encryption keys logged in plaintext | 日期 + 严重性 + 摘要 |
+| 2019-01-15 | CVE-2018-16846 | 6.5 Medium | authenticated RGW users can cause DoS | 日期 + 严重性 + 摘要 |
+| 2019-01-15 | CVE-2018-14662 | 5.7 Medium | read-only users could steal dm-crypt keys | 日期 + 严重性 + 摘要 |
+| 2018-07-10 | CVE-2018-10861 | 8.1 High | authenticated user can create/delete pools | 日期 + 严重性 + 摘要 |
+| 2018-03-19 | CVE-2018-7262 | 7.5 High | malformed headers can cause RGW DoS | 日期 + 严重性 + 摘要 |
+| 2018-07-10 | CVE-2018-1129 | 6.5 Medium | network MITM can tamper with messages | 日期 + 严重性 + 摘要 |
+| 2018-07-10 | CVE-2018-1128 | 7.5 High | Cephx replay vulnerability | 日期 + 严重性 + 摘要 |
+| 2018-07-27 | CVE-2017-7519 | 4.4 Medium | libradosstriper unvalidated format string | 日期 + 严重性 + 摘要 |
+| 2018-08-01 | CVE-2016-9579 | 7.6 High | potential RGW XSS attack | 日期 + 严重性 + 摘要 |
+| 2018-07-31 | CVE-2016-8626 | 6.5 Medium | malformed POST can DoS RGW | 日期 + 严重性 + 摘要 |
+| 2016-10-03 | CVE-2016-7031 | 7.5 High | RGW unauthorized bucket listing | 日期 + 严重性 + 摘要 |
+| 2016-07-12 | CVE-2016-5009 | 6.5 Medium | mon command handler DoS | 日期 + 严重性 + 摘要 |
+| 2016-12-03 | CVE-2015-5245 | （空） | RGW header injection | 日期 + 摘要（**无严重性**） |
+
+> 💡 补充：虽然官方没有逐个写技术细节，但这 29 条的 Summary 本身已足以指导优先级排序。按摘要可直接归出几条运维动作线索（属归纳，非官方原文）：
+> - 摘要里出现 **RGW / HTTP headers / POST** 的，都是**对外网暴露面**问题，需要优先确认 RGW 是否暴露在不可信网络；
+> - 摘要里出现 **Cephx replay / nonce reuse**（CVE-2018-1128、CVE-2018-1129、CVE-2020-1759、CVE-2020-25660）的，属认证协议缺陷，需要靠升级解决；
+> - 摘要里出现 **clear text / logged in plaintext / steal keys / .conf perm**（CVE-2018-16889、CVE-2018-14662、CVE-2020-25677、CVE-2020-25678）的，属**凭据落盘与日志安全**问题，可通过审计文件权限、日志内容、密钥存储方式自查；
+> - **CVE-2020-10736（authorization bypass in mon and mgr）** 与 **CVE-2018-10861（authenticated user can create/delete pools）** 属越权类，直接指向"caps 是否授予过宽"，与第 03 册的 caps 配置强相关。
+
+> 引自：[Past vulnerabilities](https://docs.ceph.com/en/tentacle/security/cves/)
+
+---
+
+## 三、安全报告流程
+
+本章合并官方两个页面：`index`（报告入口与要求）与 `process`（漏洞管理流程）。
+
+### 3.1 报告入口：邮件地址
+
+官方在 `index` 页面给出的唯一入口：
+
+> To report a vulnerability, please send email to **security@ceph.io**
+
+```text
+收件人：security@ceph.io
+```
+
+### 3.2 关于"加密方式"——文档未明确
+
+需要如实说明：**官方 `index` 页面与 `process` 页面都没有提到任何加密通信方式**——没有提供 PGP/GPG 公钥、没有提供指纹、没有说明是否可以用加密邮件，也没有提供任何备用的安全提交通道（如安全表单、加密上传页面）。
+
+因此：**请按官方要求直接发送明文邮件至 security@ceph.io**；是否需要/如何加密，**文档未明确**。本册不臆造任何公钥或指纹。
+
+> 💡 补充（操作提醒，非官方原文）：如果待报告内容极其敏感，可在首封邮件中**先只描述漏洞类型与受影响组件，不附利用细节**，并询问安全团队偏好的加密通道——这是通用做法，官方未禁止也未建议。
+
+### 3.3 官方对报告者的 4 项要求（`index` 页面原文）
+
+| # | 官方原文 | 说明 |
+|---|---|---|
+| 1 | `Please do not file a public ceph tracker issue for a vulnerability.` | **不要**为漏洞开公开的 Ceph tracker issue。这是硬性要求——走公开渠道等于提前披露。 |
+| 2 | `We urge reporters to provide as much information as is practicable (a reproducer, versions affected, fix if available, etc.), as this can speed up the process considerably.` | 官方**强烈建议**尽可能提供详尽信息：**复现步骤（reproducer）、受影响的版本、可用的修复方案**等，因为这会**大幅加快**处理进程。 |
+| 3 | `Please let us know to whom credit should be given and with what affiliations.` | 说明**致谢应给谁**、以及其**所属机构**。这一点呼应了 CVE-2021-3524 页面中 `Red Hat would like to thank Sergey Bobrov (Kaspersky)` 的致谢形式。 |
+| 4 | `If this issue is not yet disclosed publicly and you have any disclosure date in mind, please share the same along with the report.` | 若该问题**尚未公开披露**，且你**心中有披露日期**，请在报告中一并说明。 |
+
+### 3.4 受支持的版本（官方承诺）
+
+官方 `index` 页面原文：
+
+> Security updates are applied only to the current **Active Releases**.
+
+即：**安全修复只应用于当前处于 Active 状态的发布线**。已 EOL 的版本不会收到安全更新。Active Releases 列表由官方指向 `https://docs.ceph.com/en/latest/releases/#active-releases`（该页面不在本册源文范围内）。
+
+> 引自：[Security](https://docs.ceph.com/en/tentacle/security/)
+
+### 3.5 漏洞管理流程（`process` 页面，11 步，逐条讲透）
+
+官方以编号列表给出 11 条，以下逐条给出原文要点与解读：
+
+| 步骤 | 官方原文要点 | 解读 |
+|---|---|---|
+| 1 | `The report will be acknowledged within three business days.` | **响应时间预期：3 个工作日内确认收到**。这是官方唯一给出的时限承诺。 |
+| 2 | `The team will investigate the reported issue and will update the email thread with relevant information. The team may ask for additional information regarding the reported issue.` | 团队会调查，并**在该邮件线程中更新**相关信息；可能会**要求补充信息**。→ 上报后请持续关注该线程。 |
+| 3 | `If the team does not confirm the report, no further action will be taken and the issue will be closed.` | 若团队**无法确认**该报告，则**不再采取进一步动作**，问题关闭。 |
+| 4 | `If the report is confirmed by Ceph team members, a unique CVE identifier will be assigned to the report and then shared with the reporter. The Ceph security team will start working on a fix.` | 确认后：分配**唯一 CVE 编号**并**同步给报告者**，安全团队**开始开发修复**。 |
+| 5 | `If a reporter has no disclosure date in mind, a Ceph security team member will coordinate a release date (CRD) with the list members and share the mutually agreed disclosure date with the reporter.` | 若报告者**没有**预设披露日期，则由安全团队成员与 **list members** 协调 **CRD（Coordinated Release Date，协同发布日）**，并把**双方同意的披露日期**告知报告者。 |
+| 6 | `The vulnerability disclosure / release date is set excluding Friday and holiday periods.` | 披露/发布日期**避开周五与节假日**。 |
+| 7 | `Embargoes are preferred for Critical and High impact issues. Embargo should not be held for more than 90 days from the date of vulnerability confirmation, except under unusual circumstances. For Low and Moderate issues with limited impact and an easy workaround or where an issue that is already public, a standard patch release process will be followed to fix the vulnerability once CVE is assigned.` | **Critical / High 倾向采用 embargo（禁运/保密期）**；禁运期**自漏洞确认之日起不超过 90 天**（特殊情况除外）。**Low / Moderate**、影响有限且有简易规避手段、或**问题已经公开**的，则在 CVE 分配后走**标准补丁发布流程**修复。 |
+| 8 | `Fixes for issues of "Medium" and "Low" severity will be released as part of the next standard release cycle. List members will receive seven days of advance notice prior to the release date of these fixes. The details of the CVE fix will be included in the release notes, and the release notes will be linked in the public announcement.` | **Medium / Low** 的修复随**下一个标准发布周期**发布；**list members 会提前 7 天收到通知**；修复细节写入 **release notes**，公告中会**链接该 release notes**。 |
+| 9 | `Commits will be handled in a private repository for review and testing and a new patch version will be released from this private repository.` | 修复提交在**私有仓库**中评审与测试，**新的补丁版本从该私有仓库发布**。 |
+| 10 | `If a vulnerability is unintentionally already fixed in the public repository, a few days are given to downstream stakeholders/vendors to prepare for updating before the public disclosure.` | 若漏洞**在公开仓库中已被无意修复**，则在公开披露前**给下游利益方/厂商几天时间**准备更新。 |
+| 11 | `An announcement will be made disclosing the vulnerability. The fastest place to receive security announcements is via the ceph-announce@ceph.io or oss-security@lists.openwall.com mailing lists. (These lists are low-traffic).` | 发布**公开公告**。**最快获取安全公告的渠道**是这两个邮件列表（均为**低流量**）：`ceph-announce@ceph.io`、`oss-security@lists.openwall.com`。 |
+
+### 3.6 禁运（embargo）期间的报告者义务
+
+官方在 11 条之后还有一段明确要求：
+
+> If the report is considered embargoed, we ask you to **not disclose the vulnerability before it has been fixed and announced**, unless you received a response from the Ceph security team that you can do so. This holds true until the public disclosure date that was agreed upon by the list.
+
+即：若报告被认定为处于禁运状态，**在修复完成并公告之前不要披露该漏洞**，除非你收到 Ceph 安全团队允许你这么做。该约束**一直持续到 list 商定的公开披露日**。
+
+### 3.7 订阅安全公告
+
+按官方第 11 条，最快的两个渠道：
+
+```text
+ceph-announce@ceph.io
+oss-security@lists.openwall.com
+```
+
+官方标注这两个列表均为 **low-traffic**（低流量）。
+
+> 💡 补充：把 3.5 的时限整理成一张预期时间表（数值全部来自官方原文，不含推断）：
+>
+> | 环节 | 官方时限 |
+> |---|---|
+> | 报告确认（acknowledge） | **3 个工作日内** |
+> | Critical / High 的禁运期 | **自确认日起不超过 90 天**（特殊情况除外） |
+> | Medium / Low 修复的提前通知 | **发布日前 7 天**给 list members |
+> | 披露日期的排期规则 | **避开周五与节假日** |
+> | 修复未确认的报告 | 关闭，无后续动作 |
+
+> 引自：[Vulnerability Management Process](https://docs.ceph.com/en/tentacle/security/process/)
+
+---
+
+## 四、安全加固建议（检查清单）
+
+**说明**：官方 `doc/security/` **没有**一份独立的加固指南。本表是把 8 个页面中散落的建议（主要是各 CVE 页的 `Recommendations` 与 `Fix details`）汇总成检查清单。凡官方原文有对应依据的，「依据」列标注具体来源；凡官方未给出、由本册补充的，条目前标 `💡`。
+
+| # | 项目 | 建议 | 涉及组件 | 参考章节 |
+|---|---|---|---|---|
+| 1 | 升级到已打补丁的版本 | 用户应尽早升级到已打补丁的 Ceph 版本（各 CVE 的修复版本见 2.2–2.6） | 全集群（mon / mgr / osd / rgw / mds） | 2.2.8、2.3、2.4、2.5、2.6（官方 Recommendations） |
+| 2 | 升级所有客户端与用户态守护进程 | 所有未打补丁的客户端都要升级；可用 `ceph health detail` 中的 `AUTH_INSECURE_GLOBAL_ID_RECLAIM` 识别 | 用户态客户端与守护进程（Luminous v12.2.0+ 起受影响） | 2.2.8 第 2 条（官方） |
+| 3 | 关闭不安全的 `global_id` 回收 | 全部客户端升级完毕且告警消失后执行：`ceph config set mon auth_allow_insecure_global_id_reclaim false` | mon | 2.2.8 第 4 条（官方） |
+| 4 | 保留不安全回收探测机制 | 保持 `auth_expose_insecure_global_id_reclaim` 为默认（开启），以便客户端一认证就被强制重连从而快速暴露问题；仅在明确需要时设 `false` | mon | 2.2.7 修复点 2（官方） |
+| 5 | 处理 `AUTH_INSECURE_GLOBAL_ID_RECLAIM_ALLOWED` 告警 | 该告警表示集群当前仍允许不安全回收，可用 `ceph health mute AUTH_INSECURE_GLOBAL_ID_RECLAIM_ALLOWED 1w` 静默 | mon | 2.2.7 修复点 1（官方） |
+| 6 | **不要**用关闭告警代替修复 | 官方明确 `Although it is not recommended`，不建议执行 `ceph config set mon mon_warn_on_insecure_global_id_reclaim_allowed false` | mon | 2.2.7 修复点 1（官方，反向建议） |
+| 7 | 了解认证票据 TTL 变化 | 默认 TTL 由 12 小时提高到 72 小时；开启安全回收后，断开超过 TTL 的客户端可能回收失败、无法重认证，需重启 | mon / 所有客户端 | 2.2.7 修复点 4（官方） |
+| 8 | 审计 cephx key 的路径限制 | 担心受 CVE-2022-0670 影响的管理员应审计集群中的 CephX key，确认 path restrictions 正确 | mgr volumes 插件 / CephFS / cephx | 2.6（官方 Recommendations 第 2 条）；cephx caps 语法见第 03 册 |
+| 9 | RGW 用户整体升级 | 所有 Ceph 对象存储（RGW）用户应升级（针对 CVE-2021-3524、CVE-2021-3531） | radosgw | 2.4、2.5（官方） |
+| 10 | Dashboard 用户整体升级 | 所有 Dashboard 用户应升级（针对 CVE-2021-3509） | mgr dashboard | 2.3（官方） |
+| 11 | 确认版本是否仍在 Active Releases | 安全更新**只**应用于当前 Active Releases；已 EOL 的发布线收不到补丁 | 版本策略 | 1.5 / 3.4（官方 index） |
+| 12 | 漏洞上报走私密渠道 | 发现漏洞发邮件至 `security@ceph.io`，**不要**开公开 tracker issue | 流程 | 3.1 / 3.3（官方 index） |
+| 13 | 上报时附足信息 | 提供 reproducer、受影响版本、可用修复，以及致谢对象与所属机构、意向披露日期 | 流程 | 3.3（官方 index） |
+| 14 | 订阅安全公告 | 订阅 `ceph-announce@ceph.io` 或 `oss-security@lists.openwall.com`（低流量） | 流程 | 3.5 第 11 条 / 3.7（官方 process） |
+| 15 | 💡 自查桶的 CORS 配置 | 检查各桶 CORS 配置的 `ExposeHeader` 中是否含 `\r` 等控制字符（升级前可做） | radosgw | 2.4（本册补充，官方未要求） |
+| 16 | 💡 优先收敛 Swift API 暴露面 | CVE-2021-3531 明文写了 `Unauthenticated users` 即可触发，应确认 Swift API 端点不暴露于不可信网络 | radosgw | 2.5（本册补充，基于官方"未认证可触发"的事实） |
+| 17 | 💡 审计凭据落盘与日志 | 历史上 4 条 CVE 指向同类问题：`encryption keys logged in plaintext`、`read-only users could steal dm-crypt keys`、`ceph-ansible iscsi-gateway.conf perm`、`mgr module passwords in clear text`；应审计配置文件权限、日志是否含密钥、mgr 模块密码是否明文 | mgr / 部署工具链 / OSD 磁盘加密 | 2.7（本册补充，基于官方 Summary 归类） |
+| 18 | 💡 收敛 caps 授权范围 | `authorization bypass in mon and mgr`（CVE-2020-10736）与 `authenticated user can create/delete pools`（CVE-2018-10861）均属越权类，应复查各实体的 caps 是否过宽 | mon / mgr / 全集群 | 2.7（本册补充）；caps 语法见第 03 册 |
+| 19 | 💡 排查长期未升级的客户端 | 结合修复点 4 的 72 小时 TTL：若存在常年不重启、跨公网/跨机房的客户端，开启安全回收前应先确认其升级状态 | 客户端 | 2.2.7（本册补充） |
+| 20 | 💡 建立 CVE 对照机制 | 以 2.1 总表为基准，定期对照 `ceph version` 与各发布线修复版本；注意官方对 29 条 CVE 未给出影响/修复版本，需另行确认 | 流程 | 2.1 / 2.7（本册补充） |
+
+> 引自：[Security](https://docs.ceph.com/en/tentacle/security/)、[Past vulnerabilities](https://docs.ceph.com/en/tentacle/security/cves/)、[Vulnerability Management Process](https://docs.ceph.com/en/tentacle/security/process/)、各 CVE 子页面
+
+---
+
+## 文档未明确项
+
+以下逐条列出官方 `doc/security/` 8 个页面中**没有写清楚**的点。本册一律不做推断、不用外部知识补全。
+
+1. **是否存在威胁模型文档**：`doc/security/` 下没有 threat model / security architecture 页面。第一章的安全模型是归纳得出的，不是官方声明。
+2. **默认是否加密**：8 个页面**完全没有**说明 Ceph 默认是否启用传输加密或静态加密。仅能从 CVE 摘要推断"存在加密能力"，但**默认开关状态文档未明确**。
+3. **报告邮件的加密方式**：官方只给了 `security@ceph.io`，**未提供 PGP/GPG 公钥、指纹或任何加密提交通道**，也未说明是否支持/要求加密邮件。
+4. **CVE-2015-5245 的严重性**：官方表格中该行 `Severity` 字段为**空**，未给出任何评级。
+5. **CVE-2021-3509 的影响版本与修复版本口径不自洽**：`Affected versions` 只写 `Octopus v15.2.0 and later`，但 `Fixed versions` 同时给出 `Nautilus v14.2.21`。官方未解释 Nautilus 为何也在修复列表内。
+6. **CVE-2021-3531 的影响版本与修复版本口径不自洽**：`Affected versions` 只写 `Nautilus v14.2.0 and later`，但 `Fixed versions` 同时给出 `Pacific v16.2.4` 与 `Octopus v15.2.12`。官方未解释。
+7. **CVE-2021-3524 完全没有影响版本**：该页面**没有** `Affected versions` 小节，是 5 个 CVE 子页面中唯一缺失此项的。
+8. **CVE-2022-0670 的 Octopus 修复版本写法不一致**：`Quincy v17.2.2` 与 `Pacific v16.2.10` 后都有 `(and later)`，而 `Octopus v15.2.17` **没有**。官方未说明是笔误还是有意。
+9. **29 条无详情页 CVE 的影响版本 / 修复版本 / 缓解措施**：官方只给 `Published`、`Severity`、`Summary` 三项，其余一律未提供（CVE 编号外链 NVD）。
+10. **CVE-2021-3509 的 XSS 类型与触发条件**：官方只说 `XSS attack that could expose the authentication cookie to other sites`，**未说明**是存储型还是反射型、注入点在哪个参数、是否需要已登录、利用前提是什么。
+11. **CVE-2021-3531 的"畸形 URL"具体形态**：官方只说 `malformed URL` 触发 `server-side assertion`，**未给出**具体 URL 样例、受影响的 Swift API 路径、以及断言失败后 radosgw 是崩溃还是仅拒绝该请求。
+12. **CVE-2022-0670 的路径限制错误具体表现**：官方只说应"审计 CephX key 的 path restrictions 是否正确"，**未说明**错误路径限制长什么样、如何在 `ceph auth list` 输出中识别异常。
+13. **`auth_allow_insecure_global_id_reclaim` 等配置项的默认值来源**：官方 CVE 页面只说该选项"初始默认为 `true`"；本册源文中无 `src/common/options/*.yaml.in` 可核对，**未做默认值二次校验**。
+14. **认证票据 TTL 的配置项名称**：官方只说"默认 TTL 从 12 小时提高到 72 小时"，**未给出**对应配置项名（如是否可手动调整）。
+15. **`AUTH_INSECURE_GLOBAL_ID_RECLAIM` / `AUTH_INSECURE_GLOBAL_ID_RECLAIM_ALLOWED` 的完整告警码与文档页**：官方只在 CVE 页面给出这两个告警名与 `mute` 示例，**未给出**其完整健康码与专门说明页。
+16. **`Active Releases` 的具体列表**：官方只链接到 `https://docs.ceph.com/en/latest/releases/#active-releases`，该页不在本册源文范围内，本册不转述其内容。
+17. **确认漏洞后的修复开发时限**：`process` 只给了"3 个工作日内确认收到"与"禁运不超过 90 天"，**未承诺**从确认到发布修复的具体时长。
+18. **`list members` 的构成与加入方式**：`process` 第 5、8 条多次提到 `the list members`（能提前 7 天收到通知的群体），但**未说明**这是什么列表、如何加入、与 `security@ceph.io` 是否同一批人。
+19. **报告未被确认时的申诉路径**：`process` 第 3 条说未确认则关闭，**未说明**报告者是否可以补充证据重申。
+20. **Tentacle v20.2.4 自身的安全状态**：`cves` 表最新一条发布于 `2023-02-02`（CVE-2023-46159），官方表格**未包含** 2023-02 之后到 v20.2.4 之间是否有新 CVE 的说明——是确实没有，还是表格未更新，文档未明确。
+21. **各 CVE 与具体 Ceph 版本号的映射方式**：官方用 "Pacific v16.2.1 (and later)" 这类**发布线 + 版本号**表述，**未说明**如何据此判断任一后续大版本（如 Tentacle）是否包含该修复。
@@ -0,0 +1,183 @@
+# 附录：覆盖映射、抓取清单与官方文档问题清单
+
+> 本附录是《Ceph 知识学习手册》的溯源与自检文件。所有数字均来自实际抓取与统计脚本输出，未做估算。
+> 文档版本：**Tentacle v20.2.4** ｜ 抓取日期：2026-09-17 ｜ 官网入口：https://docs.ceph.com/en/tentacle/
+
+---
+
+## 一、版本基线的确定过程
+
+用户给出的入口是 `https://docs.ceph.com/en/latest/`。实测发现该路径**不是稳定版**：
+
+| 探测项 | 实测结果 |
+|---|---|
+| `/en/latest/` 首页 | 页面含 "This document is for a development version of Ceph" |
+| Read the Docs `sitemap.xml` | 除 `latest` 外还列出版本名 **umbrella**（即 v21 开发线） |
+| `/en/tentacle/releases/` | Active Releases：**Tentacle 20.2.4**（首发 2025-11-18，最新点版本 2026-08-19，EOL 预计 2027-06-01）；Squid 19.2.6（EOL 2026-10-31） |
+| Archived | Reef 18.2.8（EOL 2025-03-20）及更早 |
+
+**结论**：本手册以 **Tentacle v20.2.4** 为基线（用户确认），源文取自 GitHub tag `v20.2.4`。
+
+> ⚠️ 一个需要读者注意的官方数据不一致：`/en/tentacle/releases/` 的 gantt 图把 Tentacle 列为 Active、最新 20.2.4，但同一版本源码 `doc/releases/index.rst` 的 Active Releases 表格**只列了 Squid 与 Reef，没有 Tentacle**，且 `doc/releases/` 目录下不存在 `tentacle.rst` 与 `releases.yml`。本手册以站点渲染结果（Tentacle 20.2.4 为当前稳定线）为准，并在此如实登记该矛盾。
+
+---
+
+## 二、抓取方式说明（为什么不爬 docs.ceph.com）
+
+| 环节 | 采用方案 | 原因 |
+|---|---|---|
+| 页面枚举 | 解析 Sphinx `toctree` 递归展开 + GitHub 目录树 `embeddedData`（补齐 `dev/*` 的 glob 目录） | `sitemap.xml` 只有版本首页，拿不到子页；`api.github.com` 匿名限流 60 次/小时，实测已 403 |
+| 源文获取 | `raw.githubusercontent.com/ceph/ceph/v20.2.4/doc/**.rst` | **逐字保真的 rst 源文**，且 GitHub raw CDN 对数百文件并发几乎不限流；直接爬 docs.ceph.com 极易触发全站 429 硬限流（历史教训：并发抓 Ceph 803 页后全站 429，数小时才恢复） |
+| 抓取结果 | **512 页，全部成功，0 失败**，共 4.5 MB rst 源文 | 见 `tools/fetched.json` |
+| 配置项默认值 | 额外抓取 `src/common/options/*.yaml.in`（13 个文件，**2052 个配置项**） | 见下方第四节 |
+
+目录说明：
+
+```
+ceph-handbook/
+├── handbook/             # 成稿：21 册 Markdown（本文件所在目录）
+├── handbook-src/
+│   ├── raw/              # 原文池：512 个 rst 源文，保留不删，供溯源
+│   └── options/          # 源码配置项定义 yaml.in（默认值权威来源）
+└── tools/                # 抓取与统计脚本 + tree.json / inventory.json / mapping.json
+```
+
+---
+
+## 三、覆盖映射表（官页面 → 手册分册）
+
+统计口径：官方 `toctree` 可达页面 ∪ `doc/dev` 目录树 = **545 页**；本次抓取 512 页（排除 33 页，见第五节）；成稿覆盖 **512 页中的 512 页**（含第 03 册补写的 `rados/operations/change-mon-elections`）。
+
+| 分册 | 覆盖页数 | 体积 | 覆盖的官方章节 |
+|---|---:|---:|---|
+| 00-Ceph-总览与快速上手 | 24 | 104 KB | `start/*`、`install/*`、`index`、`foundation`、`governance`、`releases/index`、`releases/general` |
+| 01-架构篇 | 2 | 174 KB | `architecture`（76KB）、`glossary`（26KB） |
+| 02-RADOS-数据寻址与存储引擎 | 25 | 238 KB | `rados/index`、`rados/operations/{data-placement, crush-map, crush-map-edits, placement-groups, pg-concepts, pg-states, pools, upmap, erasure-code*, pgcalc}`、`rados/configuration/{bluestore, filestore, journal, storage-devices, pool-pg, mon-osd-interaction}` |
+| 03-RADOS-集群运维与配置 | 24+1 | 164 KB | `rados/operations/{add-or-rm-mons, add-or-rm-osds, balancer, read-balancer, cache-tiering, control, monitoring, monitoring-osd-pg, operating, stretch-mode, bluestore-migration, devices, health-checks, user-management, change-mon-elections}`、`rados/configuration/{ceph-conf, common, mon, osd, auth, network, msgr2, mon-lookup-dns, mclock, general}` |
+| 04-RADOS-排障篇 | 8 | 132 KB | `rados/troubleshooting/*`（8 页） |
+| 05-cephadm-部署与运维篇 | 25 | 209 KB | `cephadm/*` 全部（install、host-management、operations、services/* 15 个、upgrade、certmgr、adoption、compatibility、troubleshooting 等） |
+| 06-ceph-volume-磁盘管理篇 | 24 | 97 KB | `ceph-volume/*` 全部（lvm/* 13、simple/* 4、zfs/* 2、intro、inventory、drive-group、systemd） |
+| 07-RBD-块存储篇 | 39 | 224 KB | `rbd/*` 全部（含 iSCSI 9 页、NVMe-oF 6 页、K8s/OpenStack/CloudStack/Nomad/Windows 集成） |
+| 08-CephFS-文件存储篇 | 50 | 300 KB | `cephfs/*` 全部 50 页 |
+| 09-RGW-核心与运维篇 | 13 | 181 KB | `radosgw/{index, frontends, pools, placement, layout, config-ref, admin, adminops, account, multitenancy, nfs, metrics, troubleshooting}` |
+| 10-RGW-S3与Swift接口篇 | 25 | 162 KB | `radosgw/s3/*`（13）、`radosgw/swift/*`（10）、`s3.rst`、`swift.rst` |
+| 11-RGW-多站点与数据服务篇 | 16 | 194 KB | `radosgw/{multisite, multisite-sync-policy, cloud-*, sync-modules, elastic-sync-module, archive-sync-module, zone-features, notifications, bucket_logging, s3select, s3-notification-compatibility, d3n, compression, rgw-cache, orphans, dynamicresharding}` |
+| 12-RGW-安全与高级特性篇 | 20 | 165 KB | `radosgw/{encryption, vault, kmip, barbican, iam, role, STS, STSLite, session-tags, bucketpolicy, keycloak, keystone, ldap-auth, oidc, opa, mfa, lua-scripting, qat-accel, uadk-accel, api}` |
+| 13-监控告警与Dashboard篇 | 28 | 271 KB | `monitoring/index`、`mgr/*`（25 页）、`jaegertracing/index`、`hardware-monitoring/index` |
+| 14-安全篇 | 8 | 60 KB | `security/*` 全部 8 页（含 5 个 CVE 详情页） |
+| 15-命令速查手册 | 36 | 195 KB | `man/8/*` 全部 36 个命令手册 |
+| 16-内部实现-核心机制篇 | 41 | 340 KB | `dev/` 顶层核心机制类 37 页 + `dev/mon-*` 4 页 |
+| 17-内部实现-OSD与MDS篇 | 32 | 295 KB | `dev/osd_internals/*`（27，含 erasure_coding 子目录 5）、`dev/mds_internals/*`（5） |
+| 18-内部实现-组件工具与Crimson篇 | 52 | 255 KB | `dev/crimson/*`、`dev/cephadm/*`、`dev/radosgw/*`、`dev/dashboard/*`、`dev/ceph-volume/*` + `dev/` 顶层其余文件 |
+| 19-开发者贡献指南篇 | 18 | 194 KB | `dev/developer_guide/*` 全部 18 页 |
+| **合计** | **512** | **约 3.7 MB** | |
+
+> 逐页映射的完整机器可读清单见 `tools/mapping.json`（字段：`by_volume`）。
+> 成稿前逐页反查过一次：仅 `rados/operations/change-mon-elections` 未被分配，已补写进第 03 册第二十二章。
+> `rados/man/index` 是 man 页的索引页（0KB，仅 toctree），其内容由第 15 册承载。
+
+---
+
+## 四、配置项默认值的取值来源（重要）
+
+Ceph 文档的 `*-config-ref` 页用 `.. confval::` 指令引用配置项，**默认值、类型在 rst 源文里并不存在**，是在文档构建期由 Ceph 源码生成的。因此：
+
+- 第 02、03 册初稿中大量默认值被标为「文档未明确」；
+- 后续从源码 `src/common/options/*.yaml.in`（tag `v20.2.4`）取到权威默认值，共 **2052 个配置项**，已回填：
+
+| 分册 | 补全默认值处数 | 仍查不到 |
+|---|---:|---|
+| 02-RADOS-数据寻址与存储引擎 | 80 | 6（`crush-num-failure-domains`、`crush-device-class`、`crush-locality` 非配置项；`bluestore_block_path`/`_db_path`/`_wal_path` 在 yaml.in 中无 `default:` 字段） |
+| 03-RADOS-集群运维与配置 | 198 | 5（`osd_recovery_thread_timeout`、`sleep_interval`、`pool_ids`、`mgr/devicehealth/*_threshold` 为模块/命令参数）+ 17 项 yaml.in 中无 `default:` 字段（`fsid`、`mon_initial_members`、`public_network`、`cluster_addr`、`pid_file`、`chdir` 等） |
+
+凡回填处均已标注「（默认值取自 src/common/options/*.yaml.in @ v20.2.4）」，与文档原文来源区分开。
+
+---
+
+## 五、未纳入本次手册的官页面（33 页）及原因
+
+| 类别 | 页数 | 具体页面 | 原因 |
+|---|---:|---|---|
+| 编程 API 参考 | 12 | `rados/api/{index, librados, librados-intro, libradospp, libcephsqlite, python, objclass-sdk}`、`rbd/api/{index, librbdpy}`、`cephfs/api/{index, libcephfs-java, libcephfs-py}`、`api/{index, mon_command_api}` | 用户指定「API 不要」。另外第 07 册已覆盖 `librbd` Python 用法、`rbd/api/librbdpy` 的内容 |
+| 旧版本 release notes | 21 | `releases/{argonaut…squid}`（历代 changelog，约 4 MB） | 属历史变更记录而非学习材料；仅保留 `releases/index`（版本策略）与 `releases/general`，由第 00 册承载 |
+| **合计** | **33** | | |
+
+---
+
+## 六、各册「文档未明确项」统计
+
+下表为「文档未明确」在各册全文（含末尾清单）中的出现次数，可作为该册官方信息缺口的一个粗略指标——数值越高，说明该主题官方文档写得越不完整：
+
+| 分册 | 出现次数 | 分册 | 出现次数 |
+|---|---:|---|---:|
+| 03-RADOS-集群运维与配置 | 262 | 08-CephFS-文件存储篇 | 12 |
+| 02-RADOS-数据寻址与存储引擎 | 105 | 14-安全篇 | 11 |
+| 05-cephadm-部署与运维篇 | 91 | 01-架构篇 | 9 |
+| 12-RGW-安全与高级特性篇 | 132 | 19-开发者贡献指南篇 | 8 |
+| 13-监控告警与Dashboard篇 | 56 | 00-Ceph-总览与快速上手 | 7 |
+| 04-RADOS-排障篇 | 36 | 18-内部实现-组件工具与Crimson篇 | 7 |
+| 10-RGW-S3与Swift接口篇 | 33 | 15-命令速查手册 | 6 |
+| 17-内部实现-OSD与MDS篇 | 31 | 11-RGW-多站点与数据服务篇 | 8 |
+| 16-内部实现-核心机制篇 | 30 | 09-RGW-核心与运维篇 | 15 |
+| 07-RBD-块存储篇 | 22 | 06-ceph-volume-磁盘管理篇 | 19 |
+
+> 说明：计数包含该册末尾「## 文档未明确项」清单中的条目行，故略高于实际独立条目数。每册的完整清单请直接查看对应分册末尾章节——**这些是官方文档本身没写清楚、配生产前需要自行验证的点**。
+
+---
+
+## 七、官方文档自身的问题清单（撰稿过程中实测发现）
+
+以下问题均为阅读 Tentacle v20.2.4 源文时发现，本手册已在对应位置标注或按更权威口径修正：
+
+| # | 问题 | 出处 |
+|---|---|---|
+| 1 | `doc/releases/index.rst` 的 Active Releases 表缺 Tentacle，且 `releases/` 目录无 `tentacle.rst`、`releases.yml`，与站点渲染结果矛盾 | 00 册 |
+| 2 | `install/index.rst` 的 Windows 链接 `./windows-install` 断链 | 00 册 |
+| 3 | `start/quick-rbd.rst` 示意图仍使用已废弃的 `ceph-deploy` | 00 册 |
+| 4 | `beginners-guide` 称 manager 负责数据均衡，与 OSD/CRUSH 的实际职责冲突 | 00 册 |
+| 5 | cephadm 安装示例中的版本号仍写 `18.2.0`（未随版本更新） | 00 册 |
+| 6 | 术语表 `Ceph Monitor` 条目列了 manager map 却未列 PG/MDS map，与架构页「五张 map」不一致 | 01 册 |
+| 7 | `troubleshooting-pg.rst` 中 `incomplete`、`snaptrim` 两节在源文中为空白 | 04 册 |
+| 8 | `cephadm/install.rst` 中 `--registry-url` 参数源文不存在（实为 `--registry-json`） | 05 册 |
+| 9 | `cephadm/upgrade.rst` 未给出回滚步骤；mgr/cephadm 元数据备份还原无对应章节 | 05 册 |
+| 10 | `mon_warn_on_slow_ping_time` 初稿误写「1 秒 / 1000ms」，权威库为 `0`（禁用），已更正 | 03 册 |
+| 11 | `radosgw/lua-scripting.rst` 正文称内存上限 500K，与 `rgw_lua_max_memory_per_state` 默认 128000 不一致 | 12 册 |
+| 12 | `radosgw/vault.rst` 的 secret-id 获取命令与 role-id 重复；`STSLite.rst` 的 Keystone 密码/用户说明错位 | 12 册 |
+| 13 | IAM policy 与 bucket policy 的优先级，官方未给出裁决规则 | 12 册 |
+| 14 | `mgr/prometheus/*`、`mgr/dashboard/*`、`influx`、`localpool` 等模块级配置项不在 `*.yaml.in`，默认值无法二次校验 | 13 册 |
+| 15 | CVE-2021-3509、CVE-2021-3531 的影响版本与修复版本口径不自洽；CVE-2021-3524 无影响版本；CVE-2015-5245 严重性为空 | 14 册 |
+| 16 | **`man/8/ceph.rst` 全文本身就没有 `orch` / `telemetry` 章节**（仅第 1843 行 `-f/--format` 处提到 "yaml is only valid for orch commands"）；本手册该两节内容取自同仓库的 `mgr/orchestrator.rst`、`mgr/telemetry.rst`、`cephadm/*`，synopsis 系归纳所得，已全部用 `💡 补充` 标注。另 `rbdnamer` 二进制名有歧义 | 15 册 |
+| 21 | `dev/ceph_krb_auth.rst` 六节编号跳号（a/b/c 直接到 f，无 d/e）；v20.2.4 的 options 中 `auth_*_required` 合法值只写 `cephx`/`none`，未列 `gss`；限制与已知问题源文未写 | 16 册 |
+| 22 | `dev/osd_internals/erasure_coding/enhancements.rst` 的 Story 24 把 `MOSDEcSubOpSequence` 写成 `MODSEcSubOpSequence`，疑为笔误（已照录并标注）；新增消息的类定义/字段/默认值源文未给出 | 17 册 |
+| 23 | `mgr/smb.rst` 字段名为 `provider`（在 `cephfs` 对象内，旧稿曾误作 `share_vfs`，已按源文更正）；官方 usersgroups 的 `ref` 称指向 `ceph.smb.join.auth`，语义疑似应为 `ceph.smb.usersgroups`；storage 示例命令主机 `IBM-Ceph-1` 与输出 `node-10` 不一致 | 13 册 |
+| 17 | `dev/peering.rst` 的状态图为 SVG，源文无法提取；`health-reports.rst` 示意图缺失；`perf_histograms.rst` 示例称 9 个 history entry 但 JSON 只有 8 组 | 16 册 |
+| 18 | `dev/osd_internals/mclock_wpq_cmp_study.rst` 数据来自 Quincy 而非 Tentacle；EC 的三种 data flow 官方只列了两种 | 17 册 |
+| 19 | `dev/radosgw/s3_compliance.rst` 为草案且 commit 链接失效；`ceph-volume/zfs.rst` 的 compression 示例疑误写 `ceph.vdo=1`；`freebsd.rst` 的 `zpool add osd1 log` 疑应为 `cache` | 18 册 |
+| 20 | 官方无 `src/` 目录布局表；`Fixes:` trailer 规范、GDB 子命令、Sentry 章节在源文中缺失 | 19 册 |
+
+---
+
+## 八、交付物自检
+
+| 自检项 | 结果 |
+|---|---|
+| 抓取成功率 | 512/512，0 失败 |
+| 分册数量 | 21 册（00–19 正文 + 20 附录），无空册 |
+| 页面覆盖 | 512/512 官页面均有对应分册（逐页反查确认） |
+| 版本标注 | 每册文件头均标注 Tentacle v20.2.4 + 抓取日期 |
+| 来源标注 | 每册章节末尾标注 `> 引自：[页面](https://docs.ceph.com/en/tentacle/...)` |
+| 补充标注 | 非官方内容均标 `> 💡 补充：` |
+| 数值核查 | 配置项默认值已从源码 `yaml.in` 回填 278 处；各册撰稿人另做了关键数值 grep 复核 |
+| 截断补全 | 首轮因源文读取被截断/拦截而留白的 **4 处已全部补齐**（见下表） |
+| 原文留存 | `handbook-src/raw/` 保留 512 个 rst 源文，可逐条回溯 |
+
+### 首轮截断处的补全记录（2026-09-18）
+
+| 分册 | 补全内容 | 净增 |
+|---|---|---:|
+| 15-命令速查手册 | `ceph orch` 全量子命令表 + `ceph telemetry` 子命令与 7 个 `mgr/telemetry/*` 配置项（源文 man/8/ceph.rst 无此两章，内容取自同仓 `mgr/orchestrator.rst`、`mgr/telemetry.rst`、`cephadm/*`） | 约 1.5 万字符 |
+| 16-内部实现-核心机制篇 | Kerberos 认证：keytab 校验、KDC 搭建、kdc.conf/krb5.conf 配置、验证步骤、配置项速查表 | 约 1.0 万字符 |
+| 17-内部实现-OSD与MDS篇 | EC 增强提案 19.5 节复校（正文 19.5.1–19.5.16 原本完整），新增 19.5.17「新增消息/接口/标志速查」 | 约 0.33 万字符 |
+| 13-监控告警与Dashboard篇 | SMB 模块 8.15.4–8.15.11（五类资源完整字段、声明式全流程、客户端访问）+ 硬件监控 10.3–10.6（oob 带外凭据、storage/firmware 完整输出、注意事项） | 约 1.15 万字符 |
+
+> 复校结果也对首轮判断做了一处更正：第 15 册的 `orch`/`telemetry` 缺失**不是**源文截断，而是 `man/8/ceph.rst` 本来就没有这两章（见问题清单第 16 条）。