【Rook / CSI】多租户与安全边界：Secret、加密与 network fencing

多租户存储上的事故，很少以「CRUSH 算错」开场，更多以 Secret 被哪个命名空间挂上、加密叠了几层、节点以为自己死了但客户端还在写 开场。Rook/CSI 把这些边界暴露成 K8s 对象：StorageClass 参数、Secret、CSI-Addons fencing、以及 OSD 与 PVC 两层加密开关。

本文是系列第 15 篇：钉信任边界与失败模式，不是 Helm values 百科，也不提供「复制即生产」的完整加密部署手册。操作旗标以 Rook v1.20 文档为准；落地前核对自己的 OperatorConfig/Driver 与发行版差异。

本文是「Rook / CSI：K8s 上的 Ceph 编排内核」系列第 15 篇（共 16 篇）。→ 系列目录

篇目	核心内容
第 14 篇 · 对照替代路径	云 CSI / Longhorn / 裸 Ceph
第 15 篇 · 多租户与安全	Secret / 加密 / fencing
第 16 篇 · 选型收束	排除树与开放问题

版本锚定：Rook v1.20.4；Ceph-CSI v3.17.0；CephFS fscrypt 要求 Linux 内核 ≥ 6.6（Rook CSI 文档）。

一、先画信任边界，再谈开关

租户命名空间：PVC、应用 Pod、（可选）租户侧加密 Secret
平台命名空间（常 rook-ceph）：Operator、CSI 插件、mon endpoint 配置、KMS ConfigMap
Ceph 集群：cephx 用户与 caps、OSD 磁盘、blocklist
节点内核：krbd / CephFS 客户端、LUKS、fscrypt

多租户的「隔离」在本系列里主要指：池/文件系统 caps、StorageClass 参数面、密钥存放位置、节点失联时的 blocklist。不是 NetworkPolicy 教程，也不是服务网格。

flowchart TD
  sc["StorageClass params"]
  sc --> secret["CSI Secrets + caps"]
  sc --> enc["PVC encryption LUKS/fscrypt"]
  sc --> pool["Pool / FS boundary"]
  node["Node out-of-service taint"]
  node --> fence["CSI-Addons fencing"]
  fence --> bl["Ceph client blocklist"]
  osdenc["OSD encryptedDevice"]
  osdenc --> warn["Double-tax if stacked\nwith PVC LUKS"]

二、CSI Secrets：谁能代表客户端说话

Ceph-CSI 经 StorageClass 注解引用 Secret（供给、节点、扩容等路径各有 csi.storage.k8s.io/*-secret-* 字段；具体键名以所用 StorageClass 模板为准）。Secret 内是 cephx 用户与 key，不是「K8s 登录令牌」的同义词。

机制要点

• caps 决定爆炸半径：节点插件 Secret 的 caps 若过宽，任意能调度到该节点且能读到映射卷的工作负载，间接享受该 caps。多租户应用「一集群一 admin key」是反模式。
  
• Secret 所在命名空间是平台策略问题：常见做法是平台命名空间存放供给用 Secret，节点用 Secret 由 CSI 框架按 SC 注解拉取——租户不应能随意改 SC 指向的 Secret 名。
  
• 轴六同源：mon endpoint 与 key 漂移会表现为全集群或单 SC 供给失败（第 13 篇），在安全视角上等于「信任锚过期」。

多租户最小边界（原则，非菜谱）

不展开 Vault 路由表或每位租户的 Helm chart——那些属于平台实施手册。本文只要求：ADR 写明 Secret 的命名空间归属与 caps 粒度。

三、PVC 加密：RBD LUKS 与 CephFS fscrypt

Rook v1.20 Ceph CSI Drivers 写明：Ceph-CSI 支持对 PVC 加密——RBD 用 LUKS，CephFS 用 fscrypt；并通过 encrypted: "true" 与 encryptionKMSID 等 StorageClass 参数启用。KMS 配置落在平台侧 ConfigMap（文档示例名 rook-ceph-csi-kms-config），并需打开加密相关 Operator 配置（文档中的 CSI_ENABLE_ENCRYPTION 路径；v1.20 亦应对照 CSI Operator 等价项）。

RBD + LUKS

• 加密发生在 CSI 节点路径：对映射后的设备做 LUKS，Ceph 集群侧看到的是加密后的 RBD 对象字节。
  
• rbd info 不会用 image feature 位告诉你「这是 LUKS 卷」——验证要在节点块层看加密映射（运维手册级，本篇不伪造 lsblk 输出）。
  
• 密钥来源可以是 Kubernetes Secret 元数据模式或外部 KMS；生产倾向 KMS，以免密钥与 etcd 同命运。

CephFS + fscrypt

• 依赖 Linux fscrypt，Rook 文档要求 内核 ≥ 6.6。低于该版本不要假装「SC 打开就行」。
  
• 不是所有 KMS 都与 fscrypt 兼容：文档说明——能直接提供密钥材料（如 Vault）或能提供明文口令（如 Kubernetes Secrets）的类别才一般可用。选错 KMS 类型会在供给/挂载期失败，而不是静默明文。

与多租户的关系

同一 Ceph 集群上可用不同 StorageClass 挂不同 encryptionKMSID，从而实现「加密租户 / 非加密租户」分界——这是 SC 边界，不是 RADOS 另起集群。未加密 SC 与加密 SC 背后的 pool 是否共用，属于威胁模型选择：共用则平台仍能在 OSD 层看见密文；分隔则运维成本更高。

四、OSD 加密与「双税」警告

Rook 支持在 storageClassDeviceSets 等路径上对 OSD 设备做 dm-crypt/LUKS（encryptedDevice / 相关 security 段；密钥可进 KMS，见 Key Management 文档）。这与 PVC 加密是不同层：

Rook CSI 文档原句级警告：

Using both RBD PVC encryption and OSD encryption at the same time will lead to double encryption and may reduce read/write performance.

工程结论：

• 默认不要双开当「更深安全」——先付 CPU/延迟税，威胁模型却可能没变（攻击者若已在节点持有卷密钥，双加密帮不上忙）。
  
• 可选组合应写进 ADR：谁防物理盗盘、谁防平台管理员、谁防租户横向，再选一层为主。
  
• 双税若被合规逼着打开，把它当成已知性能税，不要在排障时当「Ceph 变慢莫名其妙」。

本篇不给「推荐永远开 OSD 加密」的口号；那是合规与编制问题。

五、Network fencing：节点 out-of-service → client blocklist

问题

节点网络分区或 kubelet 假死时，K8s 可能在别处重建 Pod 并再次 NodePublish，而旧节点上的 Ceph 客户端仍认为自己持有卷。对 RBD（尤其未正确单挂）与 CephFS，这是数据损坏路径。

机制（Rook 文档）

Network fencing 在节点带有 node.kubernetes.io/out-of-service taint 时，自动把对应 Ceph client blocklist；taint 清除且冷却期过后再移除 blocklist。支持 RBD 与 CephFS。该能力依赖 CSI-Addons 控制器与 sidecar（默认不启用；需部署 CSI-Addons 并在 OperatorConfig/Driver 上打开相关旗标，文档示例含 deployCsiAddons 等）。

手工应急路径（节点永久丢失）在 CSI Common Issues 的 Node Loss 节：强制删卡死 Pod、必要时在 toolbox ceph osd blocklist add/rm——与自动 fencing 是同一 Ceph 原语的不同触发器。

多租户含义

开放张力：fencing 缩短脑裂窗口，但错误 taint 会造成「误杀」客户端。ADR 应写清 taint 的唯一写入者与冷却参数来源。

六、StorageClass 作为多租户边界（非 Helm 菜谱）

把多租户收敛成 SC 维度时，最少区分：

平台模式（原则）：Cluster 管理员拥有 SC 与 SnapshotClass；租户命名空间只绑定允许的 SC 名（经门禁、策略引擎或简单 RBAC）。
自助模式：租户可建 SC——则必须假设他们能指向任何可见 Secret；威胁模型完全不同，本系列默认不推荐在未另建策略引擎时采用。

CephFS RWX 多写是共享文件系统语义，不是「自动租户隔离」。多租户若共享同一 subvolume，隔离要回到 POSIX 权限/树配额/独立 subvolume——见第 8 篇与 ceph/13，不要指望 SC 名字魔法。

七、安全相关排障入口

审计时要能回答的四句话

安全评审不必先看 Helm values，先逼问四句是否有书面答案：

1. 谁能创建或编辑 StorageClass？ 若是租户，默认假设 Secret 劫持可行。
   
2. 节点插件持有的 cephx 用户 caps 覆盖哪些池？ 过宽则节点沦陷 ≈ 多租户数据沦陷。
   
3. 静态加密防的是盗盘、防的是平台管理员，还是防的是租户横向？ 答案决定 OSD 层还是 PVC 层，以及是否允许双税。
   
4. 节点假死时谁负责打 out-of-service，fencing 是否启用？ 未启用则数据库类 RWO 卷的脑裂风险必须写进残留风险，而不是口头「K8s 会处理好」。

四句答不全，加密开关开得再齐也只是装饰。

快照与多租户外流

VolumeSnapshot 是另一条数据外流通道：能创建快照类并在可写命名空间恢复卷的主体，等于能复制卷内容。平台若只锁 PVC 创建、不锁 SnapshotClass 绑定，多租户隔离在「只读他人桶」叙事下并不成立。处理原则与 SC 相同——快照类由平台拥有，租户只引用允许的类名；细节语义仍见第 9 篇，本节省略菜谱。

八、谱系、争论与开放问题

谱系

卷加密与 fencing 不来自 Ceph 2006 论文核心，而来自云原生威胁模型：密钥与控制面同驻 etcd、节点故障由 K8s 声明、CSI 负责把块/文件挂进 Pod。LUKS/fscrypt 是 Linux 既有原语；Ceph-CSI 负责在 NodeStage/Publish 路径调用它们；CSI-Addons 把 K8s taint 接到 Ceph blocklist。学术谱系上，这是「存储系统安全边界上移到编排层」的工程化，而不是新的放置算法。

争论：默认开 PVC 加密是否值得

A 侧（合规优先）：静态数据加密是底线，密钥进 KMS，租户 SC 全开 encrypted=true。
B 侧（机制优先）：在已控物理机房 + 强 cephx caps 下，PVC 加密主要防「平台管理员/节点可读明文」；对纯磁盘盗窃，OSD 加密更直接——且应避免双税。
裁决必须写威胁模型，禁止用「业界都开」代替。

开放问题

1. fencing 冷却与应用 RTO 的可测边界：给定数据库 PVC，从打上 out-of-service 到新节点可写的时间分布如何？冷却参数是否应成为 SLO 输入？
   
2. fscrypt + 多 KMS 类型在 CephFS 上的兼容矩阵能否在不降为菜谱的前提下做成「可机器检查」的准入？入口：Ceph-CSI 加密文档与内核 fscrypt 版本。

参考资料

官方文档（A 级）

• Rook v1.20 — Ceph CSI Drivers（PVC 加密、双税警告、network fencing、CSI-Addons）
• Rook — Key Management System（OSD 加密密钥）
• Rook v1.20 — CSI Common Issues · Node Loss
• Ceph-CSI — RBD/CephFS encryption 文档（上游 docs/，与 v3.17.0 对齐）

站内对照

• 本系列第 8、9、13 篇
• CephFS / MDS（ceph/13）

→ 上一篇：对照替代路径 · 系列目录 · 下一篇：选型收束