Sync: add kubernetes observability notes

2026-04-24 11:35:04 +08:00
parent ca96e409be
commit 989ec86c77
23 changed files with 1350 additions and 9 deletions
--- a/wiki/concepts/BEATS.md
+++ b/wiki/concepts/BEATS.md
@@ -0,0 +1,59 @@
+---
+title: "BEATS"
+type: concept
+tags: [DevOps, Observability, Logging, OpenSource]
+sources: [ctp-topic-54-esm-saas-log-analytics]
+last_updated: 2026-04-25
+---
+
+# BEATS
+
+**BEATS** 是 Elastic 公司开发的轻量级开源日志与指标数据采集代理家族，属于 ELK Stack 的数据采集层。名称来自 "Beats" 系列工具（Filebeat、Metricbeat、Packetbeat 等）。
+
+## Core Concept
+
+*"The application collects your log, it's called the BEATS."* — Jackie
+
+BEATS 代理部署在应用侧，轻量级运行，持续将日志数据推送至 Logstash 或 Elasticsearch/OpenSearch。
+
+## Member Tools
+
+| Tool | Purpose |
+|------|---------|
+| **Filebeat** | 日志文件采集（最常用），支持容器环境（Kubernetes DaemonSet） |
+| **Metricbeat** | 系统和服务指标采集 |
+| **Packetbeat** | 网络数据包分析 |
+| **Heartbeat** | 站点可用性探测 |
+| **Auditbeat** | Linux 审计框架数据 |
+| **Journalbeat** | systemd journal 采集 |
+
+## Use in ELK Architecture
+
+```
+应用层 (Application VPC)
+    └── Filebeat (容器/DaemonSet) → 持续采集日志文件
+              ↓
+日志层 (Logging VPC)
+    └── Logstash → 解析和转换字段
+              ↓
+    └── Elasticsearch/OpenSearch → 存储
+              ↓
+    └── Kibana → 可视化
+```
+
+## Key Claims
+
+- Filebeat 是在 Kubernetes 容器环境中部署日志采集的首选方案
+- BEATS 代理轻量、低资源占用，适合在每个应用节点部署
+- Filebeat 支持多行日志合并（如 Java Stack Trace）和多种日志格式解析
+
+## Related Concepts
+
+- [[ELK-Stack]]：BEATS 是 ELK 栈的采集层
+- [[Logstash]]：BEATS 采集的数据通常先推送至 Logstash 进行处理
+- [[OpenSearch]]：Filebeat 可直接推送至 OpenSearch，无需 Logstash
+- [[Centralized-Logging]]：BEATS 是集中式日志采集的重要组件
+
+## Sources
+
+- [[ctp-topic-54-esm-saas-log-analytics]]
--- a/wiki/concepts/CIS-Benchmark.md
+++ b/wiki/concepts/CIS-Benchmark.md
@@ -0,0 +1,71 @@
+---
+title: "CIS Benchmark"
+type: concept
+tags:
+  - Security
+  - Compliance
+  - Hardening
+  - Standards
+sources:
+  - public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w
+last_updated: 2026-04-24
+---
+
+# CIS Benchmark
+
+CIS Benchmark（Center for Internet Security Benchmark）是全球最具权威的 IT 基础设施安全加固指南，由非营利组织 CIS（Center for Internet Security）维护，涵盖操作系统、数据库、Web 服务器、容器平台等数百种技术的安全配置标准。
+
+## 核心特点
+
+- **社区驱动**：基于全球安全专家的共识实践，经多轮评审和测试
+- **中立性**：独立于厂商，为任何组织提供客观的安全配置建议
+- **分级设计**：Level 1（基础安全，适合大多数环境）和 Level 2（深度防御，适合高安全要求环境）
+- **广泛覆盖**：涵盖 100+ 技术类别，包括 Linux、Windows、macOS、AWS、GCP、Azure、Kubernetes、Docker 等
+
+## 典型检查项示例（Linux）
+
+| 类别 | Level | 检查项 |
+|------|-------|--------|
+| 初始设置 | 1 | 确认是否禁用不必要的服务（如 telnet、rsh） |
+| 服务配置 | 1 | 配置 SSH 禁用 root 登录和密码认证 |
+| 日志配置 | 1 | 启用审计日志并配置适当的日志轮转 |
+| 文件系统 | 2 | 配置 `/tmp` 目录为 noexec、nosuid、nodev |
+| 访问控制 | 1 | 配置 PAM 强制密码复杂度 |
+| 网络配置 | 2 | 配置防火墙规则限制入站流量 |
+
+## 在 Bottlerocket 中的支持
+
+Bottlerocket OS 提供专用的 CIS Benchmark 安全加固指南：
+- 预配置的 SE Linux 策略覆盖大部分容器相关检查项
+- 只读根文件系统和 dm-verity 自动满足多项文件系统完整性要求
+- 分区设计满足审计日志分离存储要求
+- 最佳实践：使用 CIS Benchmark 自动化工具（如 CIS-CAT）定期扫描 Bottlerocket 节点合规性
+
+## 认证与合规
+
+CIS Benchmark 是多项安全合规框架的重要组成部分：
+
+| 合规框架 | 与 CIS Benchmark 的关系 |
+|---------|------------------------|
+| PCI-DSS | 引用 CIS Benchmarks 作为技术控制要求 |
+| SOC 2 | 推荐 CIS Benchmarks 作为安全配置基线 |
+| ISO 27001 | 参考 CIS Benchmarks 满足访问控制要求 |
+| NIST CSF | CIS Benchmarks 映射到 NIST Cybersecurity Framework |
+| FedRAMP | 使用 CIS Benchmarks 作为云服务安全基线 |
+
+## 工具支持
+
+- **CIS-CAT Pro**：官方自动化评估工具，支持扫描并生成合规报告
+- **InSpec**：Chef 的合规性即代码框架，有 CIS Benchmark 配置文件
+- **OpenSCAP**：开源 CVE/配置扫描工具，有 CIS Benchmark 配置文件
+- **kube-bench**：Kubernetes CIS Benchmark 自动化评估工具
+
+## 与其他安全标准的对比
+
+| 标准 | 侧重点 | 适用范围 |
+|------|--------|---------|
+| CIS Benchmark | 安全配置最佳实践 | 操作系统、应用、云服务 |
+| NIST SP 800-53 | 联邦信息安全控制 | 美国政府机构 |
+| ISO 27001/27002 | 信息安全管理体系 | 所有组织 |
+| DISA STIG | 国防部安全技术实施指南 | 美国国防部系统 |
+| SOC 2 Trust Criteria | 服务组织控制 | SaaS/云服务提供商 |
--- a/wiki/concepts/ELK-Stack.md
+++ b/wiki/concepts/ELK-Stack.md
@@ -0,0 +1,60 @@
+---
+title: "ELK Stack"
+type: concept
+tags: [DevOps, Observability, Logging, OpenSource, AWS]
+sources: [ctp-topic-54-esm-saas-log-analytics]
+last_updated: 2026-04-25
+---
+
+# ELK Stack
+
+**ELK Stack** 是由 Elasticsearch、Logstash 和 Kibana 三个开源组件组成的日志分析与全文检索技术栈，是企业级日志分析的业界标准方案。
+
+## Components
+
+| Component | Role | Description |
+|-----------|------|-------------|
+| **Elasticsearch** | 存储与检索引擎 | 分布式全文搜索和分析引擎，负责存储和查询日志数据 |
+| **Logstash** | 数据处理管道 | 采集、解析和转换日志字段，为每列数据赋予语义 |
+| **Kibana** | 可视化前端 | 日志文件可视化和分析的用户界面 |
+| **BEATS** | 轻量级采集代理 | 部署在应用侧的日志采集器家族（Filebeat/Metricbeat 等） |
+
+## Architecture
+
+```
+应用层 (Application VPC)
+    └── Filebeat (容器/DaemonSet) → 持续采集日志
+              ↓
+日志层 (Logging VPC)
+    └── Logstash → 解析日志字段
+              ↓
+    └── (Redis Buffer, 可选) → 防止 Logstash 过载
+              ↓
+    └── Elasticsearch / OpenSearch → 存储索引
+              ↓
+    └── Kibana → 可视化查询
+```
+
+## OpenSearch (AWS Fork)
+
+**OpenSearch** 是 Elasticsearch 7.10.2 的开源分支，由 AWS 主导维护，提供与 Elasticsearch 兼容的 API，作为 AWS 托管服务（Amazon OpenSearch Service）提供。ELK 栈中 Elasticsearch 可被 OpenSearch 无缝替代。
+
+## Related Concepts
+
+- [[Centralized-Logging]]：集中式日志管理的总体概念，ELK 是其核心实现技术
+- [[Cloud-Monitoring]]：可观测性三支柱（指标/日志/链路追踪）之一
+- [[OpenSearch]]：ELK 中 Elasticsearch 的 AWS 托管替代
+- [[Kibana]]：ELK 栈的可视化层
+- [[BEATS]]：ELK 栈的轻量级日志采集代理
+
+## Key Claims
+
+- ELK 栈是开源日志分析的标准方案，架构成熟、生态丰富
+- Filebeat 常用作 Kubernetes 容器环境下的日志采集器（DaemonSet 部署）
+- Logstash 作为处理管道，可解析 JSON/Nginx/Apache 等多格式日志
+- OpenSearch 是 Elasticsearch 的开源分支，AWS 提供托管服务（OpenSearch Service）
+- VPC 间日志传输走私有网络，不经过互联网
+
+## Sources
+
+- [[ctp-topic-54-esm-saas-log-analytics]]
--- a/wiki/concepts/Immutable-Root-Filesystem.md
+++ b/wiki/concepts/Immutable-Root-Filesystem.md
@@ -0,0 +1,52 @@
+---
+title: "Immutable Root Filesystem"
+type: concept
+tags:
+  - Security
+  - Linux
+  - Container OS
+sources:
+  - public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w
+last_updated: 2026-04-24
+---
+
+# Immutable Root Filesystem
+
+只读根文件系统是一种操作系统安全加固技术，通过将根文件系统挂载为只读，确保操作系统核心文件在运行时无法被修改。任何运行时变更必须通过镜像更新机制完成，从而消除因意外或恶意修改导致的系统不可用风险。
+
+## 核心原理
+
+根文件系统在启动后被挂载为只读（read-only），即使拥有 root 权限也无法直接写入 `/` 目录下的文件。需要修改系统配置时，必须：
+1. 重新构建包含更新内容的 OS 镜像
+2. 通过安全的更新机制（如 A/B 分区切换）部署新镜像
+3. 重启系统以激活变更
+
+## 典型实现
+
+| 技术 | 实现方式 |
+|------|---------|
+| dm-verity | 通过加密哈希树验证根文件系统块设备完整性，篡改被检测 |
+| OverlayFS | 在只读底层之上叠加可写层，但底层不变 |
+| OSTree | Git-like 分层镜像系统，支持原子升级和回滚 |
+| A/B 分区 | 双分区设计，在线下载新镜像到非活动分区，重启切换 |
+
+## 在 Bottlerocket 中的实现
+
+Bottlerocket OS 默认启用只读根文件系统：
+- 根分区通过 dm-verity 加密验证，任何篡改被检测
+- `/etc` 目录作为 tmpfs（临时文件系统），运行时可写但重启清空
+- 所有持久配置通过 API 或 userdata 注入，不直接修改根文件系统
+
+## 安全价值
+
+- **防篡改**：恶意软件无法修改系统关键文件
+- **一致性保证**：每次启动系统状态可预测
+- **最小化攻击面**：无需运行时包管理器，降低漏洞暴露
+- **原子更新**：通过镜像级更新确保系统要么完全更新，要么保持原状
+
+## 适用场景
+
+- 容器宿主操作系统（Bottlerocket、Flatcar Container Linux、CoreOS）
+- 嵌入式安全系统
+- 无法物理访问的远程服务器
+- 需要严格合规（如 PCI-DSS、FIPS）的基础设施
--- a/wiki/concepts/OpenTelemetry.md
+++ b/wiki/concepts/OpenTelemetry.md
@@ -0,0 +1,90 @@
+---
+title: "OpenTelemetry"
+type: concept
+tags: [DevOps, Observability, Cloud-Native, CNCF, AWS]
+sources: [public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113, ctp-topic-67-cloud-native-observability-using-opentelemetry]
+last_updated: 2026-04-27
+---
+
+# OpenTelemetry
+
+**OpenTelemetry**（OTel）是云原生计算基金会（CNCF）的可观测性框架，提供跨语言的统一遥测数据采集标准，涵盖 Traces（链路追踪）、Metrics（指标）和 Logs（日志）三种信号。
+
+## Core Components
+
+| Component | Role | Description |
+|-----------|------|-------------|
+| **OTLP Protocol** | 标准化传输 | OpenTelemetry Protocol，遥测数据的标准化传输格式 |
+| **Language SDKs** | 应用集成 | 11 种语言提供统一 SDK（Java/Python/Go/Node.js/.NET 等） |
+| **Collector** | 数据处理管道 | 标准化和转换遥测数据，包含 Receivers/Processors/Exporters/Extensions |
+| **Auto-Instrumentation** | 零侵入注入 | 自动检测应用语言并注入遥测代码，无需修改业务代码 |
+
+## Three Signals Model（三信号模型）
+
+可观测性依赖三种互补的遥测信号：
+
+| Signal | 用途 | 特点 |
+|--------|------|------|
+| **Metrics** | 聚合统计 | CPU/内存/请求率等数值指标，适合告警和趋势分析 |
+| **Logs** | 根因定位 | 离散的事件记录，包含时间戳和上下文，用于问题排查 |
+| **Traces** | 全链路追踪 | 单一请求在分布式系统中的完整路径，每个 trace 包含多个 span |
+
+## OpenTelemetry Collector Architecture
+
+```
+Receivers（接收器）→ Processors（处理器）→ Exporters（导出器）
+     ↑                                              ↓
+  Extensions（扩展）                         目标后端（OpenSearch/Grafana/CloudWatch 等）
+```
+
+- **Receivers**：接收数据（AWS-specific 或开源标准）
+- **Processors**：过滤和转换数据
+- **Exporters**：导出至后端（AWS Native / Open Source / Third-party）
+- **Extensions**：辅助功能（SIGV 授权、健康检查）
+
+## AWS Distribution for OpenTelemetry
+
+AWS 提供的 OpenTelemetry 统一发行版，在 CNCF OpenTelemetry 基础上增加了 AWS 集成：
+
+- **统一代理**：同时收集 Traces/Metrics/Logs，无需分别部署多种 Agent
+- **EKS Operator**：自动检测应用语言并创建预配置 Collector，实现零侵入式自动注入
+- **Pod 级 IAM**：通过 Pod Identity Associations 实现 Pod 级权限控制，无需修改 ServiceAccount
+- **日志支持**：最新版本支持日志采集，完善了可观测性三信号覆盖
+- **Managed Collector for Prometheus**：无服务器、无代理的 Prometheus 指标自动发现和抓取
+
+## EKS Integration Pipeline
+
+典型 EKS 环境下的端到端可观测性管道：
+
+```
+应用容器 (Auto-Instrumented by OTel SDK)
+    ↓
+Fluent Bit (DaemonSet) → 采集容器日志
+    ↓ (端口 55681)
+OpenTelemetry Collector (Sidecar/Deployment)
+    ↓ (OTLP)
+Amazon OpenSearch Service / CloudWatch / Prometheus / Grafana
+```
+
+## Key Claims
+
+- OpenTelemetry 是 CNCF 毕业项目，提供 vendor-agnostic（厂商无关）的统一可观测性方案
+- 解决了微服务架构下不同组件使用不同 SDK 和工具的碎片化问题
+- OTLP 是 OpenTelemetry 的标准化数据传输协议，所有主流可观测性后端均支持
+- AWS Distribution for OpenTelemetry 简化了 AWS 环境（尤其是 EKS）的部署复杂度
+- 自动注入（Auto-Instrumentation）实现零侵入式集成，无需修改业务代码
+
+## Related Concepts
+
+- [[ELK-Stack]]：OpenTelemetry 常与 OpenSearch/Elasticsearch 配合作为日志后端
+- [[Cloud-Monitoring]]：可观测性是云监控的核心组成部分
+- [[Amazon-EKS]]：OpenTelemetry 在 AWS EKS 环境下的典型部署场景
+- [[Fluent-Bit]]：EKS 环境中常用的日志采集器，与 OpenTelemetry 配合使用
+- [[Grafana]]：OpenTelemetry 常用的可视化后端
+- [[Prometheus]]：OpenTelemetry Metrics 的常用后端
+- [[Observability（可观测性）]]：OpenTelemetry 服务的核心目标
+
+## Sources
+
+- [[public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113]]
+- [[ctp-topic-67-cloud-native-observability-using-opentelemetry]]
--- a/wiki/concepts/Partition-Updates.md
+++ b/wiki/concepts/Partition-Updates.md
@@ -0,0 +1,70 @@
+---
+title: "Partition Updates"
+type: concept
+tags:
+  - Operating System
+  - Updates
+  - Reliability
+  - A/B Testing
+sources:
+  - public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w
+last_updated: 2026-04-24
+---
+
+# Partition Updates（分区镜像更新）
+
+分区镜像更新是一种操作系统原子更新策略，通过 A/B 双分区设计，在线下载新版本镜像到非活动分区，重启后切换激活，确保更新过程的原子性和系统一致性。
+
+## 核心设计
+
+```
+┌─────────────────────────────────────────────┐
+│  磁盘布局                                    │
+│  ┌──────────┐  ┌──────────┐  ┌──────────┐  │
+│  │ 分区 A   │  │ 分区 B   │  │ Data Vol │  │
+│  │ (活动)   │  │ (备用)   │  │ (数据卷)  │  │
+│  │ OS v1.0  │  │ OS v1.1  │  │ 容器镜像  │  │
+│  │ 正在运行 │  │ 空闲     │  │ 持久数据  │  │
+│  └──────────┘  └──────────┘  └──────────┘  │
+└─────────────────────────────────────────────┘
+```
+
+**更新流程：**
+1. 下载新版本镜像到备用分区（分区 B）
+2. 验证镜像完整性（哈希校验 + 签名验证）
+3. 更新引导配置，指向新分区
+4. 重启系统
+5. 固件/引导加载程序从新分区启动
+6. 新分区变为活动分区，旧分区变为备用分区
+
+## 优势
+
+- **原子性**：更新要么完全成功，要么系统回退到原状态，不存在"半更新"状态
+- **回滚能力**：如果新版本启动失败，可手动或自动回滚到旧分区
+- **零停机更新**：无需停止正在运行的工作负载即可下载和准备新版本
+- **一致性保证**：切换前已完成新镜像验证，确保启动后的系统状态可预测
+- **适用于关键系统**：电信、金融、工业控制系统等不能容忍更新失败的业务
+
+## 与传统包管理更新的对比
+
+| 维度 | 包管理更新（apt/yum） | 分区镜像更新（A/B） |
+|------|---------------------|-------------------|
+| 原子性 | 非原子（可能中断于中途） | 原子（全部成功或全部失败） |
+| 回滚 | 依赖包管理器功能，通常复杂 | 简单（切换回旧分区即可） |
+| 根文件系统一致性 | 难以保证 | 完整镜像替换，一致性保证 |
+| 适用场景 | 通用 Linux 服务器 | 容器宿主、嵌入式系统 |
+| 存储开销 | 无额外开销 | 需要双倍存储空间 |
+
+## 在 Bottlerocket 中的实现
+
+Bottlerocket OS 采用分区镜像更新机制：
+- 根分区分为 A、B 两组，每组包含 `root_a`/`root_b` 逻辑分区
+- Data Volume（数据卷）独立于根分区，存储容器镜像和应用数据，更新不受影响
+- Data Volume 支持快照预填充（snapshot pre-population），可在构建时就注入容器镜像，加快首次启动
+- 通过 Bottlerocket API 查看当前活动分区版本和待激活版本
+
+## 相关技术
+
+- [[OSTree]]：基于 Git 的操作系统更新系统，类似的原子升级理念
+- [[Immutable-Root-Filesystem]]：分区更新的最终目标——确保根文件系统一致性
+- [[dm-verity]]：与分区更新配合，验证新分区的完整性
--- a/wiki/concepts/SE-Linux-Enforcing.md
+++ b/wiki/concepts/SE-Linux-Enforcing.md
@@ -0,0 +1,74 @@
+---
+title: "SE Linux Enforcing Mode"
+type: concept
+tags:
+  - Security
+  - Linux
+  - MAC
+  - Access Control
+sources:
+  - public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w
+last_updated: 2026-04-24
+---
+
+# SE Linux Enforcing Mode
+
+SE Linux（Security-Enhanced Linux）是美国国家安全局（NSA）开发的 Linux 内核安全模块，通过强制访问控制（MAC，Mandatory Access Control）机制，在传统的自主访问控制（DAC，Discretionary Access Control）之上增加了一层细粒度的安全策略。
+
+## DAC vs MAC
+
+| 维度 | DAC（传统 Linux 权限） | MAC（SE Linux） |
+|------|----------------------|----------------|
+| 控制方式 | 所有者自主决定 | 系统统一策略强制执行 |
+| 粒度 | 用户/组/其他 + rwx | 主体标签 + 客体标签 + 策略规则 |
+| 绕过风险 | root 可修改任何权限 | 即使 root 也受策略约束 |
+| 配置难度 | 简单（chmod/chown） | 复杂（需要策略编写） |
+
+## 关键概念
+
+- **主体（Subject）**：进程，通常具有特定的安全上下文（如 `system_u:system_r:container_file_t`）
+- **客体（Object）**：文件、目录、端口、进程等系统资源
+- **安全上下文（Security Context）**：格式为 `user:role:type[:level]` 的标签字符串
+- **策略规则（Policy Rules）**：定义哪些主体可以对哪些客体执行哪些操作的规则集合
+- **Enforcing 模式**：强制执行策略，违反策略的操作被拒绝并记录
+- **Permissive 模式**：仅记录违反策略的操作，不实际阻止
+
+## Bottlerocket 中的 SE Linux
+
+Bottlerocket OS 默认启用 SE Linux enforcing 模式：
+- **容器隔离**：每个容器运行在独立的安全上下文中，防止容器逃逸后影响宿主机或其他容器
+- **最小权限原则**：即使容器内获得 root 权限，其操作仍受 SE Linux 策略限制
+- **与容器运行时集成**：containerd、docker 等容器运行时通过 SE Linux 标签隔离不同容器的工作负载
+
+## 常见 SE Linux 标签
+
+| 标签 | 用途 |
+|------|------|
+| `unconfined_t` | 不受限制的进程 |
+| `container_file_t` | 容器管理的文件（如 volume 挂载点） |
+| `svirt_sandbox_file_t` | SELinux 虚拟沙箱文件标签 |
+| `admin_t` | 系统管理员类型 |
+
+## 与其他安全机制的协同
+
+- **与 AppArmor**：AppArmor 是 SE Linux 的替代方案，Ubuntu 默认使用 AppArmor
+- **与 seccomp**：seccomp 限制进程可调用的系统调用，SE Linux 控制对系统对象的访问
+- **与 capabilities**：Linux capabilities 将 root 特权拆分为多个独立能力，SE Linux 在此基础上进一步限制能力的使用场景
+
+## 故障排查
+
+SE Linux  enforcing 模式下，常见故障表现为"Permission denied"即使文件权限看起来正确：
+
+```bash
+# 查看文件的安全上下文
+ls -Z /path/to/file
+
+# 查看进程的 SE Linux 上下文
+ps -Z
+
+# 临时切换为 Permissive 模式（调试用）
+setenforce 0
+
+# 查看 SE Linux 拒绝日志
+ausearch -m avc -ts recent
+```
--- a/wiki/concepts/dm-verity.md
+++ b/wiki/concepts/dm-verity.md
@@ -0,0 +1,67 @@
+---
+title: "dm-verity"
+type: concept
+tags:
+  - Security
+  - Linux Kernel
+  - Integrity
+sources:
+  - public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w
+last_updated: 2026-04-24
+---
+
+# dm-verity (Device Mapper Verity)
+
+dm-verity 是 Linux 内核的块设备完整性验证机制，通过在块设备层面计算并验证加密哈希树（cryptographic hash tree），确保根文件系统的任何未授权篡改都能被立即检测。
+
+## 工作原理
+
+```
+块设备（底层）
+    ↓
+[哈希树计算层]
+    ↓
+根哈希（Root Hash，存储在可信位置）
+    ↓
+与预期值对比 → 一致 = 验证通过 | 不一致 = 检测到篡改
+```
+
+1. **哈希树构建**：文件系统的每个块（通常 4KB）计算 SHA-256 或其他哈希值，形成树状结构
+2. **根哈希存储**：最顶层哈希（Root Hash）存储在可信位置（如 TPM、引导加载程序验证后的内存区域）
+3. **块设备访问拦截**：每次读取块设备时，dm-verity 内核模块实时计算路径哈希并与预期值比对
+4. **透明验证**：验证过程对上层应用完全透明，性能开销通常 < 5%
+
+## 在 Bottlerocket 中的应用
+
+Bottlerocket OS 在构建时为根分区生成 dm-verity 哈希树：
+- 根文件系统镜像在构建时生成根哈希
+- 引导加载程序在启动时验证根哈希
+- dm-verity 模块在运行时验证每个块设备读取操作
+- 任何对根文件系统块的篡改都会导致 I/O 错误或验证失败
+
+## 与其他技术的对比
+
+| 技术 | 作用 | 层级 |
+|------|------|------|
+| dm-verity | 块设备完整性验证（防篡改） | 块设备层 |
+| dm-crypt | 块设备加密（防窃取） | 块设备层 |
+| IMA/EVM | 文件级完整性度量 | 文件系统层 |
+| Secure Boot | 引导加载程序验证 | 固件层 |
+
+## 安全价值
+
+- **运行时防篡改检测**：即使攻击者获得 root 权限，也无法在不触发验证失败的情况下修改系统文件
+- **完整性保证**：确保启动后的系统与构建时的镜像完全一致
+- **信任链建立**：与 Secure Boot 结合，构建从固件到应用层的完整信任链
+
+## 局限性
+
+- **不防窃取**：dm-verity 不加密数据（配合 dm-crypt 使用可同时实现完整性和保密性）
+- **只读保护**：无法防止拒绝服务攻击（通过损坏块设备导致验证失败）
+- **验证失败处理**：检测到篡改后的行为取决于配置，可能是返回 EIO 错误或让系统崩溃
+
+## 相关技术
+
+- [[Immutable-Root-Filesystem]]：只读根文件系统的整体策略
+- [[Secure-Boot]]：引导阶段的固件验证
+- [[TPM]]（Trusted Platform Module）：用于安全存储根哈希的可信硬件