Update node-exporter to v1.11.1, fcct to butane

2026-10-21 10:16:38 +00:00 · 2026-04-25 14:58:40 +00:00
parent 77a537df54
commit 8093b198ce
19 changed files with 8 additions and 28 deletions
@@ -9,7 +9,6 @@
 默认情况下，Docker 容器对系统资源的使用是没有限制的：一个容器理论上可以使用宿主机所有的 CPU 计算能力、吃光所有的内存、耗尽所有的系统 PID。

 想象一下以下场景：
-
 - 一个恶意用户向你暴露在公网的应用发起海量并发请求。
 - 应用程序逻辑中存在内存泄漏漏洞。
 - 黑客在入侵容器后，在里面运行了挖矿木马程序。
@@ -81,7 +81,6 @@ $ docker version
 在企业环境中，对 Docker 守护进程的访问控制往往不仅限于文件系统权限，还需要更细粒度的授权策略。**Authorization Plugin** 机制允许在 API 层级对请求进行拦截和审批。

 常见的授权插件包括：
-
 - **OPA/Conftest**：开放策略引擎，支持声明式策略定义。
 - **Prisma Cloud（Twistlock）**：商业容器安全平台。
 - 自定义脚本：根据请求内容（镜像、命令、用户等）做出允许/拒绝决定。
@@ -9,14 +9,12 @@
 在默认情况下，即便一个容器是在以 `root` 用户运行，Docker 也只为其内核授予了所有可用能力中的 **一小部分“白名单”能力**。

 常见的 Linux Capabilities 包含：
-
 - `CAP_CHOWN`: 修改文件所有者。
 - `CAP_NET_BIND_SERVICE`: 绑定特权端口（即 1024 以下的端口）。
 - `CAP_NET_ADMIN`: 网络管理的最高权限（例如调整路由配置，设置防火墙规则等）。
 - `CAP_SYS_ADMIN`: 被誉为“Linux 内核的特权网管”，允许各种高危操作（挂载磁盘、访问敏感设备等）。

 为了在 **“最小特权原则”** 的指导下加强安全，Docker 默认 **移除了** 大量可能导致容器大范围破坏宿主机的能力，例如：
-
 * 完全禁止了任何通过 `CAP_SYS_ADMIN` 进行的核心挂载或设备操作。
 * 禁止修改内核模块。
 * 禁止直接访问硬件套接字。
@@ -43,7 +43,6 @@ chmod: /etc/passwd: Operation not permitted
 传统的 Linux 模型遵循 DAC（自主访问控制），这意味着如果一个文件被赋予了全员读写权限（`777`），普通隔离下任何人便都能修改。但 **MAC（强制访问控制）** 技术，诸如 `AppArmor` (常用于 Ubuntu/Debian) 或 `SELinux` (常用于 CentOS/RHEL)，可以制定比“文件所有权”更宏观且优先的策略控制模块。

 在开启了上述机制的机器上：
-
 - **AppArmor**: Docker 为所有启动的应用加载了一个默认的 `docker-default` 模板文件，如果你的某些异常写行为（比如往特殊的内核心脏目录写入配置）不在 AppArmor 许可列表之上，即使拥有物理 Root，写入同样失败。
 - **SELinux**: 所有的 Docker 操作强制附加特殊上下文标识标签。就算把主机的 `/` 绑定给了黑客的某服务，黑客对不属于 Docker 可见的标签的文件进行读写尝试亦会被阻止。

@@ -530,7 +530,6 @@ push:
 **Q: 扫描报告中有过时的 CVE，如何处理？**

 A: 某些 CVE 可能已经被修复但数据库未更新，可以：
-
 - 手动验证安全补丁是否已应用
 - 使用工具的忽略列表功能（如 Trivy 的 `.trivyignore`）
 - 定期更新扫描工具和漏洞数据库
@@ -538,7 +537,6 @@ A: 某些 CVE 可能已经被修复但数据库未更新，可以：
 **Q: 如何平衡镜像大小和安全性？**

 A:
-
 - 使用多阶段构建减少最终镜像大小
 - 使用精简基础镜像（Alpine、Distroless）
 - 定期更新依赖而不是一味求小
@@ -547,7 +545,6 @@ A:
 **Q: 如何管理和轮换签名密钥？**

 A:
-
 - 在密钥管理系统（如 HashiCorp Vault）中存储密钥
 - 定期轮换密钥（建议每 90 天）
 - 使用 Keyless 签名消除密钥管理复杂性