云原生存储容器编排运维【免费下载链接】rookStorage Orchestration for Kubernetes项目地址https://gitcode.com/gh_mirrors/roo/rook点击查看免费下载CephX 是 Ceph 集群内部身份认证的基础密钥keyring一旦泄露或长期不更新就会成为安全隐患。本指南围绕 Rook 官方设计文档 design/ceph/cephx-keyring-rotation.md 展开系统讲解 Rook 如何在不打断 Ceph 集群连接的前提下自动轮换 Ceph 守护进程密钥又如何通过keyGeneration等机制让用户在维护窗口内安全地轮换 CSI、CephClient 等非守护进程密钥。读完本文你将掌握 Rook CephX 密钥轮换的完整设计思路、CephCluster/CephClient上的配置字段语义、状态字段的解读方式以及源码层面 types.go 与 cephx.go 中的真实实现细节。为什么需要 CephX 密钥轮换Ceph 集群内部所有组件mon、mgr、osd、mds、rgw 等之间的通信都依赖 CephX 认证。Rook 创建 Ceph 集群时会为每个守护进程签发长期有效的密钥并存放于 Kubernetes Secret 中。这些密钥在集群生命周期内几乎不会更新一旦泄露或需要满足合规要求管理员只能手动处理风险高、易出错。Rook 的设计目标是守护进程密钥可以自动、透明地轮换且不会影响 Rook 控制之外的任何 Ceph 连接涉及外部客户端的密钥如 CSI、CephClient、镜像对等令牌由用户在维护窗口内主动触发轮换并且能够明确判断轮换何时完成不同的密钥类型支持独立触发避免一次轮换影响所有客户端的粗暴做法。密钥的两大分类从终端用户体验出发Rook 将密钥分为两类守护进程密钥daemon keys仅由 Ceph 集群内部使用Rook 可以自动轮换而不会破坏任何外部连接包括Admin 密钥client.adminmon、mgr、osd、mds、rgwnfs、log-rotator、crash-collectorrbdmirror 与 cephfsmirror 的内部非对等密钥非守护进程密钥non-daemon keys轮换可能影响非 Rook 控制的连接需要用户在维护窗口内协调操作CephClient 密钥RBD / CephFS 镜像对等令牌peer tokensCSI 密钥CSI 密钥是最特殊的非守护进程密钥轮换会直接影响所有挂载了 RBD / CephFS PVC 的应用 Pod管理员可能需要重启或 drain/undrain 所有相关节点才能让挂载从旧密钥切换到新密钥。因此 CSI 密钥只提供一次性轮换选项KeyGeneration且默认走重叠轮换流程见下文。轮换策略的接口设计设计文档提出了一个统一的轮换基接口keyRotationPolicy: Disabled | WithCephVersionUpgrade | KeyGeneration keyGeneration: int # used with KeyGeneration keepPriorKeyCount: int # only present to configure overlapping rotation字段语义如下字段取值说明keyRotationPolicyDisabled默认初始创建后不再轮换WithCephVersionUpgradeCeph 版本升级时轮换KeyGeneration当keyGeneration大于当前代际时轮换keyGeneration正整数仅在KeyGeneration策略下生效大于当前代际则触发轮换并把代际更新为该值小于等于当前代际则不轮换keepPriorKeyCount非负整数仅支持重叠轮换的组件可用指定保留多少个旧密钥关于keyGeneration有两个值得注意的设计点代际值不要求连续递增1 - 5同样合法但 CRD 校验禁止代际回退见下文源码分析设计文档曾考虑过once、always、按 Ceph 版本选择、按DATETIME选择等方案最终均被否决once需要额外记录首次观测时间才能避免每次 reconcile 重复触发always需要用户手动监控并取消配置容易出错按 Ceph 版本选择无法支持已在最新版本上按需轮换 CSI 密钥DATETIME在多密钥场景下难以准确追踪轮换时间。代际generation能清晰表达真实状态且接口简单因此被采纳。源码中的实际约束从当前仓库源码看CRD 层面对该接口做了一些收敛与校验定义于 pkg/apis/ceph.rook.io/v1/types.gotype CephxConfig struct { // kubebuilder:validation:Enum;Disabled;KeyGeneration KeyRotationPolicy CephxKeyRotationPolicy json:keyRotationPolicy,omitempty // kubebuilder:validation:Minimum0 // kubebuilder:validation:Maximum4294967295 // kubebuilder:validation:XValidation:messagekeyGeneration cannot be decreased,ruleself oldSelf KeyGeneration uint32 json:keyGeneration,omitempty // kubebuilder:validation:Enumaes;aes256k KeyType CephxKeyType json:keyType,omitempty // kubebuilder:validation:XValidation:messagekeyGeneration cannot be removed once set,rule!has(oldSelf.keyGeneration) || has(self.keyGeneration) }可以确认的几点当前 CRD 枚举只放行Disabled与KeyGeneration设计文档中的WithCephVersionUpgrade尚未在公开 API 中开放源码内部 cephx.go 已存在shouldRotateWithCephVersionUpdate辅助函数说明该路径已在实现层面预留keyGeneration一旦设置就不能删除、不能回退由 CEL 规则在 API 层强制额外引入了keyTypeaes/aes256k字段可指定 CephX 密钥加密类型当KeyRotationPolicy为Disabled时修改keyType不会触发轮换。CephCluster 上的配置守护进程密钥轮换守护进程密钥的轮换配置只出现在CephClusterCR 上任何子 CR如CephFilesystem自动继承对应 CephCluster 的配置。这样管理员可以按集群粒度选择性开启同时保持 API 简洁。Ceph 社区建议在每次 Ceph 版本更新时轮换因为此时 Rook 本来就会重启守护进程且管理员通常已有维护窗口对集群连通性与性能无额外影响。spec: # ... security: cephx: daemon: keyRotationPolicy: Disabled | WithCephVersionUpgrade | KeyGeneration keyGeneration: int # used with KeyGeneration csi: {} # discussed more later # (room for future spec.security.cephx options) # (room for future spec.security options) # ...Rook 曾考虑在 operator 级别用全局环境变量ROOK_ROTATE_DAEMON_CEPHX_KEYS_OLDER_THAN控制但全局配置无法在修改时触发各控制器 reconcile把配置挂在 CephCluster 上控制器就能在用户修改配置时获得 reconciliation 事件这是最终选择 CephCluster 字段的根本原因。可被自动轮换的守护进程密钥清单设计文档原文mon —— 所有 mon 共享同一个密钥mgrosdmdsrgwnfsrbdmirror —— 守护进程密钥自动轮换但对等令牌不会自动轮换cephfsmirror —— 与 rbdmirror 相同log-rotatorcrash-collector此外Rook 用来执行 Ceph 命令的 admin 密钥也会自动轮换且实现上必须保证 admin 密钥轮换不会阻塞其他密钥的轮换其专用流程见后文。重叠轮换Overlapping Rotation解决大规模节点迁移难题CSI 密钥轮换要求所有挂载了 PVC 的节点完成 drain/undrain或重启以把挂载从旧密钥切换到新密钥。但服务票据 TTL默认窗口约为2 * auth_service_ticket_ttl见后文通常只有几小时大型集群不可能在一次维护窗口内更新全部节点。为此 Rook 设计了重叠轮换Rook新建一个带新密钥的 Ceph client用户但不删除旧用户/旧密钥Rook 更新 CSI Secret 指向新用户新密钥此时进入迁移窗口新的 PVC 挂载使用新密钥旧的挂载继续使用旧密钥因为旧用户尚未销毁管理员完成所有节点更新后通过配置向 Rook 表明旧密钥不再需要Rook 再删除旧密钥自动探测留作未来练习。重叠轮换只针对CSI 密钥实现不会应用于CephClient资源——因为每个 CephClient 就是单一 client ID 及其密钥需要传播凭据的用户可以直接新建 CephClient → 传播新凭据 → 删除旧 CephClient来实现等价效果。未来 RBD/CephFS 镜像对等密钥也适合重叠轮换但当前对等用户名在 Ceph 侧是硬编码的暂无法实现。重叠轮换通过keepPriorKeyCount配置通常设为1保留 1 个旧密钥供应用迁移设为0表示迁移完成后立即删除旧密钥。源码中该字段在 types.go 中定义为CephXConfigWithPriorCount.KeepPriorKeyCountMaxuint8Minimum0、Maximum10并有一个重要语义它表示最多保留的旧密钥数量上限实际保留数以真实存在的密钥数为准例如配置为 2 但当前只有 1 个旧密钥就只保留 1 个。CSI 密钥轮换的实际执行位于 pkg/operator/ceph/csi/secrets.goRook 通过deleteOldKeyGen与KeepPriorKeyCountMax计算删除数量deleteCount 当前密钥数 - keepPriorCount - 1并把 CSI 用户名加上代际后缀baseName.keyGeneration见generateCsiUserIdWithGenerationSuffix从而支持同时存在多代密钥。状态报告用户如何判断轮换完成为了让用户确定轮换是否完成所有相关 CR 统一上报两个状态字段keyGeneration: int keyCephVersion: 20.2.0 # e.g.keyGenerationint最近一次成功 reconcile 的密钥代际。即使未开启轮换策略也会更新。密钥首次创建时代际为10表示初始 reconcile含密钥创建尚未完成或密钥早于本功能实现就已存在。keyCephVersionstring签发当前在用密钥的 Ceph 版本格式必须与CephCluster.status.version.version一致如20.2.0以便直接比较空字符串表示版本未知典型于 brownfield 存量集群。判断完成的标准WithCephVersionUpgrade场景status.keyCephVersion与部署镜像中的 Ceph 版本一致即完成KeyGeneration场景status.keyGeneration spec.keyGeneration即完成重叠轮换额外上报priorKeyCountint当前仍在生效的旧密钥数量。这些状态在所有 Rook 资源首次创建 CephX 密钥时就会写入即使未开启轮换用户也始终能知道密钥的版本与代际或通过缺失得知信息未知。源码中对应结构为 types.go 的CephxStatusKeyGeneration、KeyCephVersion、KeyType状态计算逻辑在 cephx.go 的UpdatedCephxStatus首次创建置代际1未轮换时保留旧状态尤其保留KeyCephVersion轮换后代际自增若KeyGeneration策略指定的目标代际更大则直接取目标值。另外为避免 bug 或状态丢失导致 Rook 对某个组件到底生成过多少代密钥失去跟踪设计文档建议把当前keyGeneration追加到 Ceph auth client 名称中这正是 CSI 用户名后缀的实现方式使 Rook 能随时列出密钥、确保只存在当前代与期望数量的历史代。轮换的通用工作流密钥轮换在每个 reconcile 控制器内部就近执行——凡是 Rook 创建/删除 Ceph 守护进程时会创建/删除密钥的地方轮换逻辑就在旁边。这样密钥轮换能立即引起守护进程重启从而在任何意外错误导致集群或子资源离线前尽早暴露问题。通用流程如下对某个 Rook CR 开始 reconcile读取当前 CR 的 spec status所有 reconcile 本就有运行 cmd-reporter job 探测待部署 Ceph 容器镜像中的版本cephImageVersion所有 reconcile 本就有对每个守护进程 Deployment获取其当前 CephX 密钥若密钥不存在则创建keyGeneration记为1keyCephVersion记为cephImageVersion检查 spec 配置决定是否轮换KeyGeneration策略spec.keyGeneration status.keyGeneration则轮换按 Ceph 版本策略cephImageVersion高于状态中的版本则轮换用最新内容更新存放密钥的 Secretreconcile 本就包含若创建/轮换了密钥必须保证守护进程重启Rook 在 Pod spec 上施加一个随每次密钥 Secret 更新而变化的 annotation强制 Pod 重启。该 annotation 不属于面向用户的 APIoperator 不会读取它做任何决策唯一目的就是密钥轮换必定触发重启若创建/轮换了密钥更新 cephx 状态keyGeneration取 spec 目标值keyCephVersion取cephImageVersion。判定是否轮换的核心函数是 cephx.go 的ShouldRotateCephxKeys。从源码可以确认两点关键前提Rook 依赖 Ceph 的ceph auth rotate命令其支持版本下限为CephAuthRotateSupportedVersion 19.2.3cephx.go运行中的 Ceph 版本低于此值时不轮换状态代际为0密钥尚未初始化时不轮换。CephCluster 上的轮换执行细节通用 CephCluster 流程CephCluster 守护进程均属 daemon 类reconcile 读取spec.security.cephx.daemon决定是否轮换需要轮换时依次处理admin 密钥Rook 创建的第一个密钥第一个轮换轮换后视子 reconcile 引用方式可能需要重启 operator 的 reconcile managermon 密钥需要特殊流程——先不轮换密钥地更新 mon Deployment再轮换密钥最后重启 mon Deployment 让它们拿到新密钥更新 CephCluster 状态中的 mon 信息mgr 密钥逐个 mgr 轮换并更新/重启对应 daemonosd 密钥OSD 没有关联的 keyring Secret必须确保所有 OSD Deployment 的 activate init container 拿到最新密钥并更新给 osd Pod。分 daemon 类型独立跟踪状态的意义在于避免 reconcile 中途重启后重复轮换前面已经轮换过的密钥。例如 OSD 更新耗时较长很可能在 OSD 更新中途需要重启 reconcile此时不需要再轮换 admin/mon/mgr 密钥。CephCluster 的完整状态示例spec: security: cephx: daemon: {} csi: {} rbdMirrorPeer: {} status: # ... cephx: admin: keyGeneration: 3 # e.g. keyCephVersion: 20.2.2 # e.g. mon: keyGeneration: 3 # e.g. keyCephVersion: 20.2.2 # e.g. mgr: keyGeneration: 3 # e.g. keyCephVersion: 20.2.2 # e.g. osd: keyGeneration: 3 # e.g. keyCephVersion: 20.2.2 # e.g. rbdMirrorPeer: # cluster-level RBD mirror peer key (client.rbd-mirror-peer) keyGeneration: 3 # e.g. keyCephVersion: 20.2.2 # e.g. crashCollector: keyGeneration: 3 # e.g. keyCephVersion: 20.2.2 # e.g. exporter: keyGeneration: 3 # e.g. keyCephVersion: 20.2.2 # e.g. csi: {} # discussed more below对应源码类型为 types.go 的ClusterCephxConfig它把配置分为四块allowedCiphers高级项设置auth_allowed_ciphers可影响集群可用性、daemon、rbdMirrorPeer轮换会更新镜像对等令牌影响已有对等连接、csi。admin 密钥轮换防砖机的专门设计admin 密钥轮换是整个设计中最危险的一步。当前rook-ceph-monSecret 中保存着权威的client.adminkeyringprimary admin keyring。虽然client.admin理论上可以自己轮换自己的密钥但轮换密钥与更新 Secret两步无法原子化若 reconcile 或 operator 在两步之间失败集群将无法恢复。为此 Rook 引入一个临时 admin 用户client.admin-rotator其唯一职责就是轮换主 admin keyring轮换完成后立即删除。它的凭据存放在独立的rook-ceph-admin-rotator-keyringSecret 中不往rook-ceph-mon里加临时字段避免复杂性与风险。轮换流程完整 10 步以client.admin身份ceph auth get-or-create client.admin-rotator授予 admin 权限创建/更新rook-ceph-admin-keyringSecret写入client.admin-rotator的 keyringROTATE 前检查以client.admin-rotator运行ceph auth ls确认其权限可用以client.admin-rotator身份ceph auth rotate client.admin以client.admin运行ceph auth ls确认其权限仍可用更新磁盘上的 ceph 配置文件写入新的client.adminkeyring更新rook-ceph-monSecret写入新的client.adminkeyring以client.admin身份ceph auth rm client.admin-rotatorCLEANUP删除rook-ceph-admin-keyringSecret更新CephCluster.status.cephx.admin。post-mon-startup 动作admin 密钥轮换应在 mon 更新之后进行。这一点在 Ceph 升级场景下尤为重要——若当前 Ceph 版本不支持ceph auth rotate而新版本支持必须先升级 mon 再轮换mon.密钥同理。触发条件为CephCluster.spec.security.cephx.daemon指示需要轮换。CephCluster 启动时的恢复流程如果轮换在ROTATE步骤之后失败、或 operator 在此后重启rook-ceph-monSecret 的data.keyring可能是错误信息新 reconcile 将无法执行任何 admin 操作集群砖化。因此 reconciler 必须在任何其他 admin 操作之前先恢复中断的 admin 轮换读取 Secret与现状相同从 Secretdata.keyring加载client.admin与现状相同若 Secretdata.rotatorKeyring存在说明此前轮换在中途失败需要恢复以client.admin运行ceph auth ls若成功且输出中不存在client.admin-rotator说明最后的 CLEANUP 步骤失败直接 GOTOCLEANUP否则即使auth ls失败轮换失败于ROTATE到CLEANUP之间从 Secretdata.rotatorKeyring加载client.admin-rotatorGOTOROTATE继续正常的 CephCluster reconcile。CSI 密钥轮换Ceph-CSI 的 Deployment若由 Rook 管理位于 operator 命名空间但密钥按 CephCluster 维度创建因此 CSI 轮换配置同样挂在CephCluster上。CSI 轮换要求管理员手动重启或 drain/undrain 节点Rook不提供自动轮换只实现一次性轮换并且为了容纳任意长的维护窗口CSI 使用重叠轮换spec: # ... security: cephx: daemon: {} # discussed above csi: keyRotationPolicy: Disabled | KeyGeneration keyGeneration: int # used with KeyGeneration keepPriorKeyCount: 1 # (room for future spec.security.cephx options) # (room for future spec.security options) # ...重要约束WithCephVersionUpgrade不支持用于 CSI 密钥——除非 Rook 能验证密钥轮换不会影响既有 PVC 挂载连通性否则对该值直接返回错误。CSI 轮换在 CephCluster reconcile 中完成Ceph-CSI 的 provisioner 与 node plugin 密钥使用CephCluster.spec.security.cephx.csi而非...daemon判定是否轮换轮换后更新状态kind: CephCluster # ... status: # ... cephx: # (status from CephCluster daemon rotations) csi: keyGeneration: 2 # e.g. keyCephVersion: 20.2.1 # e.g. priorKeyCount: 1 # e.g.实现层面CSI 密钥轮换的核心逻辑集中在 pkg/operator/ceph/csi/secrets.go先读取现有密钥并用ShouldRotateCephxKeys判定是否轮换随后生成带代际后缀的新用户名client.rbd.pool.keyGeneration形式先创建新密钥再按KeepPriorKeyCountMax清理旧代密钥最后把status.cephx.csi.priorKeyCount更新为实际保留的旧密钥数见getPriorKeyCount。CSI 相关的单元测试覆盖于 pkg/operator/ceph/csi 目录。非守护进程密钥轮换CephBlockPool / CephFilesystem / CephClient除 CephCluster 外以下 CR 也承载非守护进程密钥CephClient—— 创建的可任意使用的 client 有一个关联密钥CephBlockPool—— 为池生成镜像对等令牌peerCephFilesystem—— 为文件系统生成镜像对等令牌peer。CephBlockPool对等令牌跟随集群级 rbdMirrorPeerRBD 镜像对等令牌内的密钥在 Ceph 侧被硬编码为client.rbd-mirror-peer用户因此单个 RBD 镜像密钥在 CephCluster 级别轮换即上文status.cephx.rbdMirrorPeer但 CephBlockPool 仍需更新自身状态标识对等令牌已换成最新版本。CephBlockPool 控制器应在父级 CephCluster 的status.cephx.rbdMirrorPeer更新时触发 reconcile创建 bootstrap token 时把CephCluster.status.cephx.rbdMirrorPeer拷贝到自己的status.cephx.peerTokenkind: CephBlockPool # ... status: # ... cephx: peerToken: keyGeneration: 2 keyCephVersion: 20.2.2对应的源码类型为 types.go 的PeerTokenCephxStatuspeerToken字段内嵌标准CephxStatus。CephFilesystem mirror设计与rbdMirrorPeer/peerToken一致针对 CephFS 镜像设计做相应适配。CephClient最简单的一对一接口CephClient 只有一个密钥既可当守护进程密钥也可当对等令牌因此接口被简化为直接内嵌CephxConfig源码 types.go 的ClientSecuritySpec状态字段见CephClientStatus.Cephxkind: CephClient # ... spec: # ... security: cephx: keyRotationPolicy: Disabled | WithCephVersionUpgrade | KeyGeneration keyGeneration: int # used with KeyGeneration # (room for future spec.security options) # ... status: cephx: keyGeneration: 1 # e.g. keyCephVersion: 20.2.0 # e.g.未使用密钥的清理Ceph 会自动创建一些 Rook 并不使用的密钥。Ceph 团队表示未来会修改 Ceph 停止创建这些密钥在改动落地之前Rook 删除它们是安全的未使用密钥无需轮换直接删除client.bootstrap-rgwclient.bootstrap-rbdclient.bootstrap-mgrclient.bootstrap-mds依赖与 CephX 技术背景Rook 的密钥轮换依赖Ceph Tentaclev20新增的ceph auth rotate命令Ceph PR #58121。理解 CephX 的几个关键技术点对开发与排障至关重要Rook 铸造的 CephX 密钥只用于守护进程的初始连接Ceph 内部所有连接使用具有阶梯式过期时间的 service 密钥默认情况下service 密钥允许密钥轮换后至少 2 小时窗口供客户端更新共有 3 个 TTL 分别为 1 小时、2 小时、3 小时的 service 密钥即使第一个 TTL 即将到期到 3 小时 TTL 到期也仍有至少 2 小时Ceph 不允许同一 client/daemon 的 keyring 中存在多个密钥轮换时旧密钥被移除、新密钥直接替换没有双密钥并存的过渡期这正是重叠轮换通过新建用户而非双密钥实现的原因auth_service_ticket_ttl与auth_mon_ticket_ttl配置可缩短/延长上述窗口但生效不是即时的内部 service 密钥更新需要时间debug_auth30可输出最大级别的 CephX 调试日志是开发阶段的排障利器。与既有方案的对比Prior ArtKubernetes 静态加密密钥轮换K8s 文档中的做法由用户负责生成密钥而 Rook 负责生成 CephX 密钥因此该设计无法直接迁移IBM Credential Rotator Operator自动轮换应用密钥并随后重启应用 Pod通过PreviousResourceKeyID状态展示信息。由于 Ceph 密钥没有与轮换关联的 ID这与 Rook 自行跟踪密钥版本key version元数据的思路类似但不完全相同。源码阅读路线图如果想在仓库中继续深挖本设计的具体实现推荐按以下路径阅读pkg/apis/ceph.rook.io/v1/types.goClusterSecuritySpec、ClusterCephxConfig、CephXConfigWithPriorCount、CephxConfig等公开 API 类型pkg/apis/ceph.rook.io/v1/types.goCephxStatus状态结构pkg/operator/ceph/config/keyring/cephx.goShouldRotateCephxKeys、UpdatedCephxStatus及CephAuthRotateSupportedVersion19.2.3版本门槛pkg/operator/ceph/config/keyring/cephx_test.go 与 pkg/operator/ceph/cluster/mgr/mgr_test.go轮换判定与状态更新的单元测试pkg/operator/ceph/csi/secrets.goCSI 重叠轮换实现带代际后缀的用户名、旧密钥清理、priorKeyCount上报pkg/apis/ceph.rook.io/v1/types.goPeerTokenCephxStatus对等令牌状态。总结Rook 的 CephX 密钥轮换设计以守护进程密钥自动轮换、非守护进程密钥由用户按需触发为总原则用keyGeneration代际机制提供了幂等、可观测、防回退的轮换接口用重叠轮换解决了 CSI 密钥轮换与大规模节点维护窗口不匹配的工程难题并通过临时client.admin-rotator用户与完整的失败恢复流程把最危险的 admin 密钥轮换风险降到可控范围。配合status.keyGeneration与status.keyCephVersion两个状态字段管理员可以精确判断任何一次轮换是否完成从而在维护窗口内安全地协调应用侧密钥更新。赞分享云原生存储容器编排运维【免费下载链接】rookStorage Orchestration for Kubernetes项目地址https://gitcode.com/gh_mirrors/roo/rook点击查看免费下载相关推荐Rook CephX 密钥类型与密钥轮换实战指南从 AES 到 AES256K 与 CVE-2025-30156 修复Rook CephX 密钥类型与密钥轮换实战指南从 AES 到 AES256K 与 CVE 2025 30156 修复 Rook 作为 Kubernetes云原生存储容器编排运维Rook Ceph 密钥管理系统KMS接入与 OSD 加密密钥轮换实战指南Rook Ceph 密钥管理系统KMS接入与 OSD 加密密钥轮换实战指南 本指南以 Rook 官方文档为骨架系统讲解如何在 Rook 管理的 Ceph云原生存储容器编排运维Rook OSD 密钥加密密钥KEK轮换机制设计与实现深度解析Rook OSD 密钥加密密钥KEK轮换机制设计与实现深度解析 本指南以 Rook 设计文档 design/ceph/key encryption key云原生存储容器编排运维创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Rook CephX Keyring Rotation 设计解析：Ceph 密钥自动轮换的架构、配置与实战
云原生存储容器编排运维【免费下载链接】rookStorage Orchestration for Kubernetes项目地址https://gitcode.com/gh_mirrors/roo/rook点击查看免费下载CephX 是 Ceph 集群内部身份认证的基础密钥keyring一旦泄露或长期不更新就会成为安全隐患。本指南围绕 Rook 官方设计文档 design/ceph/cephx-keyring-rotation.md 展开系统讲解 Rook 如何在不打断 Ceph 集群连接的前提下自动轮换 Ceph 守护进程密钥又如何通过keyGeneration等机制让用户在维护窗口内安全地轮换 CSI、CephClient 等非守护进程密钥。读完本文你将掌握 Rook CephX 密钥轮换的完整设计思路、CephCluster/CephClient上的配置字段语义、状态字段的解读方式以及源码层面 types.go 与 cephx.go 中的真实实现细节。为什么需要 CephX 密钥轮换Ceph 集群内部所有组件mon、mgr、osd、mds、rgw 等之间的通信都依赖 CephX 认证。Rook 创建 Ceph 集群时会为每个守护进程签发长期有效的密钥并存放于 Kubernetes Secret 中。这些密钥在集群生命周期内几乎不会更新一旦泄露或需要满足合规要求管理员只能手动处理风险高、易出错。Rook 的设计目标是守护进程密钥可以自动、透明地轮换且不会影响 Rook 控制之外的任何 Ceph 连接涉及外部客户端的密钥如 CSI、CephClient、镜像对等令牌由用户在维护窗口内主动触发轮换并且能够明确判断轮换何时完成不同的密钥类型支持独立触发避免一次轮换影响所有客户端的粗暴做法。密钥的两大分类从终端用户体验出发Rook 将密钥分为两类守护进程密钥daemon keys仅由 Ceph 集群内部使用Rook 可以自动轮换而不会破坏任何外部连接包括Admin 密钥client.adminmon、mgr、osd、mds、rgwnfs、log-rotator、crash-collectorrbdmirror 与 cephfsmirror 的内部非对等密钥非守护进程密钥non-daemon keys轮换可能影响非 Rook 控制的连接需要用户在维护窗口内协调操作CephClient 密钥RBD / CephFS 镜像对等令牌peer tokensCSI 密钥CSI 密钥是最特殊的非守护进程密钥轮换会直接影响所有挂载了 RBD / CephFS PVC 的应用 Pod管理员可能需要重启或 drain/undrain 所有相关节点才能让挂载从旧密钥切换到新密钥。因此 CSI 密钥只提供一次性轮换选项KeyGeneration且默认走重叠轮换流程见下文。轮换策略的接口设计设计文档提出了一个统一的轮换基接口keyRotationPolicy: Disabled | WithCephVersionUpgrade | KeyGeneration keyGeneration: int # used with KeyGeneration keepPriorKeyCount: int # only present to configure overlapping rotation字段语义如下字段取值说明keyRotationPolicyDisabled默认初始创建后不再轮换WithCephVersionUpgradeCeph 版本升级时轮换KeyGeneration当keyGeneration大于当前代际时轮换keyGeneration正整数仅在KeyGeneration策略下生效大于当前代际则触发轮换并把代际更新为该值小于等于当前代际则不轮换keepPriorKeyCount非负整数仅支持重叠轮换的组件可用指定保留多少个旧密钥关于keyGeneration有两个值得注意的设计点代际值不要求连续递增1 - 5同样合法但 CRD 校验禁止代际回退见下文源码分析设计文档曾考虑过once、always、按 Ceph 版本选择、按DATETIME选择等方案最终均被否决once需要额外记录首次观测时间才能避免每次 reconcile 重复触发always需要用户手动监控并取消配置容易出错按 Ceph 版本选择无法支持已在最新版本上按需轮换 CSI 密钥DATETIME在多密钥场景下难以准确追踪轮换时间。代际generation能清晰表达真实状态且接口简单因此被采纳。源码中的实际约束从当前仓库源码看CRD 层面对该接口做了一些收敛与校验定义于 pkg/apis/ceph.rook.io/v1/types.gotype CephxConfig struct { // kubebuilder:validation:Enum;Disabled;KeyGeneration KeyRotationPolicy CephxKeyRotationPolicy json:keyRotationPolicy,omitempty // kubebuilder:validation:Minimum0 // kubebuilder:validation:Maximum4294967295 // kubebuilder:validation:XValidation:messagekeyGeneration cannot be decreased,ruleself oldSelf KeyGeneration uint32 json:keyGeneration,omitempty // kubebuilder:validation:Enumaes;aes256k KeyType CephxKeyType json:keyType,omitempty // kubebuilder:validation:XValidation:messagekeyGeneration cannot be removed once set,rule!has(oldSelf.keyGeneration) || has(self.keyGeneration) }可以确认的几点当前 CRD 枚举只放行Disabled与KeyGeneration设计文档中的WithCephVersionUpgrade尚未在公开 API 中开放源码内部 cephx.go 已存在shouldRotateWithCephVersionUpdate辅助函数说明该路径已在实现层面预留keyGeneration一旦设置就不能删除、不能回退由 CEL 规则在 API 层强制额外引入了keyTypeaes/aes256k字段可指定 CephX 密钥加密类型当KeyRotationPolicy为Disabled时修改keyType不会触发轮换。CephCluster 上的配置守护进程密钥轮换守护进程密钥的轮换配置只出现在CephClusterCR 上任何子 CR如CephFilesystem自动继承对应 CephCluster 的配置。这样管理员可以按集群粒度选择性开启同时保持 API 简洁。Ceph 社区建议在每次 Ceph 版本更新时轮换因为此时 Rook 本来就会重启守护进程且管理员通常已有维护窗口对集群连通性与性能无额外影响。spec: # ... security: cephx: daemon: keyRotationPolicy: Disabled | WithCephVersionUpgrade | KeyGeneration keyGeneration: int # used with KeyGeneration csi: {} # discussed more later # (room for future spec.security.cephx options) # (room for future spec.security options) # ...Rook 曾考虑在 operator 级别用全局环境变量ROOK_ROTATE_DAEMON_CEPHX_KEYS_OLDER_THAN控制但全局配置无法在修改时触发各控制器 reconcile把配置挂在 CephCluster 上控制器就能在用户修改配置时获得 reconciliation 事件这是最终选择 CephCluster 字段的根本原因。可被自动轮换的守护进程密钥清单设计文档原文mon —— 所有 mon 共享同一个密钥mgrosdmdsrgwnfsrbdmirror —— 守护进程密钥自动轮换但对等令牌不会自动轮换cephfsmirror —— 与 rbdmirror 相同log-rotatorcrash-collector此外Rook 用来执行 Ceph 命令的 admin 密钥也会自动轮换且实现上必须保证 admin 密钥轮换不会阻塞其他密钥的轮换其专用流程见后文。重叠轮换Overlapping Rotation解决大规模节点迁移难题CSI 密钥轮换要求所有挂载了 PVC 的节点完成 drain/undrain或重启以把挂载从旧密钥切换到新密钥。但服务票据 TTL默认窗口约为2 * auth_service_ticket_ttl见后文通常只有几小时大型集群不可能在一次维护窗口内更新全部节点。为此 Rook 设计了重叠轮换Rook新建一个带新密钥的 Ceph client用户但不删除旧用户/旧密钥Rook 更新 CSI Secret 指向新用户新密钥此时进入迁移窗口新的 PVC 挂载使用新密钥旧的挂载继续使用旧密钥因为旧用户尚未销毁管理员完成所有节点更新后通过配置向 Rook 表明旧密钥不再需要Rook 再删除旧密钥自动探测留作未来练习。重叠轮换只针对CSI 密钥实现不会应用于CephClient资源——因为每个 CephClient 就是单一 client ID 及其密钥需要传播凭据的用户可以直接新建 CephClient → 传播新凭据 → 删除旧 CephClient来实现等价效果。未来 RBD/CephFS 镜像对等密钥也适合重叠轮换但当前对等用户名在 Ceph 侧是硬编码的暂无法实现。重叠轮换通过keepPriorKeyCount配置通常设为1保留 1 个旧密钥供应用迁移设为0表示迁移完成后立即删除旧密钥。源码中该字段在 types.go 中定义为CephXConfigWithPriorCount.KeepPriorKeyCountMaxuint8Minimum0、Maximum10并有一个重要语义它表示最多保留的旧密钥数量上限实际保留数以真实存在的密钥数为准例如配置为 2 但当前只有 1 个旧密钥就只保留 1 个。CSI 密钥轮换的实际执行位于 pkg/operator/ceph/csi/secrets.goRook 通过deleteOldKeyGen与KeepPriorKeyCountMax计算删除数量deleteCount 当前密钥数 - keepPriorCount - 1并把 CSI 用户名加上代际后缀baseName.keyGeneration见generateCsiUserIdWithGenerationSuffix从而支持同时存在多代密钥。状态报告用户如何判断轮换完成为了让用户确定轮换是否完成所有相关 CR 统一上报两个状态字段keyGeneration: int keyCephVersion: 20.2.0 # e.g.keyGenerationint最近一次成功 reconcile 的密钥代际。即使未开启轮换策略也会更新。密钥首次创建时代际为10表示初始 reconcile含密钥创建尚未完成或密钥早于本功能实现就已存在。keyCephVersionstring签发当前在用密钥的 Ceph 版本格式必须与CephCluster.status.version.version一致如20.2.0以便直接比较空字符串表示版本未知典型于 brownfield 存量集群。判断完成的标准WithCephVersionUpgrade场景status.keyCephVersion与部署镜像中的 Ceph 版本一致即完成KeyGeneration场景status.keyGeneration spec.keyGeneration即完成重叠轮换额外上报priorKeyCountint当前仍在生效的旧密钥数量。这些状态在所有 Rook 资源首次创建 CephX 密钥时就会写入即使未开启轮换用户也始终能知道密钥的版本与代际或通过缺失得知信息未知。源码中对应结构为 types.go 的CephxStatusKeyGeneration、KeyCephVersion、KeyType状态计算逻辑在 cephx.go 的UpdatedCephxStatus首次创建置代际1未轮换时保留旧状态尤其保留KeyCephVersion轮换后代际自增若KeyGeneration策略指定的目标代际更大则直接取目标值。另外为避免 bug 或状态丢失导致 Rook 对某个组件到底生成过多少代密钥失去跟踪设计文档建议把当前keyGeneration追加到 Ceph auth client 名称中这正是 CSI 用户名后缀的实现方式使 Rook 能随时列出密钥、确保只存在当前代与期望数量的历史代。轮换的通用工作流密钥轮换在每个 reconcile 控制器内部就近执行——凡是 Rook 创建/删除 Ceph 守护进程时会创建/删除密钥的地方轮换逻辑就在旁边。这样密钥轮换能立即引起守护进程重启从而在任何意外错误导致集群或子资源离线前尽早暴露问题。通用流程如下对某个 Rook CR 开始 reconcile读取当前 CR 的 spec status所有 reconcile 本就有运行 cmd-reporter job 探测待部署 Ceph 容器镜像中的版本cephImageVersion所有 reconcile 本就有对每个守护进程 Deployment获取其当前 CephX 密钥若密钥不存在则创建keyGeneration记为1keyCephVersion记为cephImageVersion检查 spec 配置决定是否轮换KeyGeneration策略spec.keyGeneration status.keyGeneration则轮换按 Ceph 版本策略cephImageVersion高于状态中的版本则轮换用最新内容更新存放密钥的 Secretreconcile 本就包含若创建/轮换了密钥必须保证守护进程重启Rook 在 Pod spec 上施加一个随每次密钥 Secret 更新而变化的 annotation强制 Pod 重启。该 annotation 不属于面向用户的 APIoperator 不会读取它做任何决策唯一目的就是密钥轮换必定触发重启若创建/轮换了密钥更新 cephx 状态keyGeneration取 spec 目标值keyCephVersion取cephImageVersion。判定是否轮换的核心函数是 cephx.go 的ShouldRotateCephxKeys。从源码可以确认两点关键前提Rook 依赖 Ceph 的ceph auth rotate命令其支持版本下限为CephAuthRotateSupportedVersion 19.2.3cephx.go运行中的 Ceph 版本低于此值时不轮换状态代际为0密钥尚未初始化时不轮换。CephCluster 上的轮换执行细节通用 CephCluster 流程CephCluster 守护进程均属 daemon 类reconcile 读取spec.security.cephx.daemon决定是否轮换需要轮换时依次处理admin 密钥Rook 创建的第一个密钥第一个轮换轮换后视子 reconcile 引用方式可能需要重启 operator 的 reconcile managermon 密钥需要特殊流程——先不轮换密钥地更新 mon Deployment再轮换密钥最后重启 mon Deployment 让它们拿到新密钥更新 CephCluster 状态中的 mon 信息mgr 密钥逐个 mgr 轮换并更新/重启对应 daemonosd 密钥OSD 没有关联的 keyring Secret必须确保所有 OSD Deployment 的 activate init container 拿到最新密钥并更新给 osd Pod。分 daemon 类型独立跟踪状态的意义在于避免 reconcile 中途重启后重复轮换前面已经轮换过的密钥。例如 OSD 更新耗时较长很可能在 OSD 更新中途需要重启 reconcile此时不需要再轮换 admin/mon/mgr 密钥。CephCluster 的完整状态示例spec: security: cephx: daemon: {} csi: {} rbdMirrorPeer: {} status: # ... cephx: admin: keyGeneration: 3 # e.g. keyCephVersion: 20.2.2 # e.g. mon: keyGeneration: 3 # e.g. keyCephVersion: 20.2.2 # e.g. mgr: keyGeneration: 3 # e.g. keyCephVersion: 20.2.2 # e.g. osd: keyGeneration: 3 # e.g. keyCephVersion: 20.2.2 # e.g. rbdMirrorPeer: # cluster-level RBD mirror peer key (client.rbd-mirror-peer) keyGeneration: 3 # e.g. keyCephVersion: 20.2.2 # e.g. crashCollector: keyGeneration: 3 # e.g. keyCephVersion: 20.2.2 # e.g. exporter: keyGeneration: 3 # e.g. keyCephVersion: 20.2.2 # e.g. csi: {} # discussed more below对应源码类型为 types.go 的ClusterCephxConfig它把配置分为四块allowedCiphers高级项设置auth_allowed_ciphers可影响集群可用性、daemon、rbdMirrorPeer轮换会更新镜像对等令牌影响已有对等连接、csi。admin 密钥轮换防砖机的专门设计admin 密钥轮换是整个设计中最危险的一步。当前rook-ceph-monSecret 中保存着权威的client.adminkeyringprimary admin keyring。虽然client.admin理论上可以自己轮换自己的密钥但轮换密钥与更新 Secret两步无法原子化若 reconcile 或 operator 在两步之间失败集群将无法恢复。为此 Rook 引入一个临时 admin 用户client.admin-rotator其唯一职责就是轮换主 admin keyring轮换完成后立即删除。它的凭据存放在独立的rook-ceph-admin-rotator-keyringSecret 中不往rook-ceph-mon里加临时字段避免复杂性与风险。轮换流程完整 10 步以client.admin身份ceph auth get-or-create client.admin-rotator授予 admin 权限创建/更新rook-ceph-admin-keyringSecret写入client.admin-rotator的 keyringROTATE 前检查以client.admin-rotator运行ceph auth ls确认其权限可用以client.admin-rotator身份ceph auth rotate client.admin以client.admin运行ceph auth ls确认其权限仍可用更新磁盘上的 ceph 配置文件写入新的client.adminkeyring更新rook-ceph-monSecret写入新的client.adminkeyring以client.admin身份ceph auth rm client.admin-rotatorCLEANUP删除rook-ceph-admin-keyringSecret更新CephCluster.status.cephx.admin。post-mon-startup 动作admin 密钥轮换应在 mon 更新之后进行。这一点在 Ceph 升级场景下尤为重要——若当前 Ceph 版本不支持ceph auth rotate而新版本支持必须先升级 mon 再轮换mon.密钥同理。触发条件为CephCluster.spec.security.cephx.daemon指示需要轮换。CephCluster 启动时的恢复流程如果轮换在ROTATE步骤之后失败、或 operator 在此后重启rook-ceph-monSecret 的data.keyring可能是错误信息新 reconcile 将无法执行任何 admin 操作集群砖化。因此 reconciler 必须在任何其他 admin 操作之前先恢复中断的 admin 轮换读取 Secret与现状相同从 Secretdata.keyring加载client.admin与现状相同若 Secretdata.rotatorKeyring存在说明此前轮换在中途失败需要恢复以client.admin运行ceph auth ls若成功且输出中不存在client.admin-rotator说明最后的 CLEANUP 步骤失败直接 GOTOCLEANUP否则即使auth ls失败轮换失败于ROTATE到CLEANUP之间从 Secretdata.rotatorKeyring加载client.admin-rotatorGOTOROTATE继续正常的 CephCluster reconcile。CSI 密钥轮换Ceph-CSI 的 Deployment若由 Rook 管理位于 operator 命名空间但密钥按 CephCluster 维度创建因此 CSI 轮换配置同样挂在CephCluster上。CSI 轮换要求管理员手动重启或 drain/undrain 节点Rook不提供自动轮换只实现一次性轮换并且为了容纳任意长的维护窗口CSI 使用重叠轮换spec: # ... security: cephx: daemon: {} # discussed above csi: keyRotationPolicy: Disabled | KeyGeneration keyGeneration: int # used with KeyGeneration keepPriorKeyCount: 1 # (room for future spec.security.cephx options) # (room for future spec.security options) # ...重要约束WithCephVersionUpgrade不支持用于 CSI 密钥——除非 Rook 能验证密钥轮换不会影响既有 PVC 挂载连通性否则对该值直接返回错误。CSI 轮换在 CephCluster reconcile 中完成Ceph-CSI 的 provisioner 与 node plugin 密钥使用CephCluster.spec.security.cephx.csi而非...daemon判定是否轮换轮换后更新状态kind: CephCluster # ... status: # ... cephx: # (status from CephCluster daemon rotations) csi: keyGeneration: 2 # e.g. keyCephVersion: 20.2.1 # e.g. priorKeyCount: 1 # e.g.实现层面CSI 密钥轮换的核心逻辑集中在 pkg/operator/ceph/csi/secrets.go先读取现有密钥并用ShouldRotateCephxKeys判定是否轮换随后生成带代际后缀的新用户名client.rbd.pool.keyGeneration形式先创建新密钥再按KeepPriorKeyCountMax清理旧代密钥最后把status.cephx.csi.priorKeyCount更新为实际保留的旧密钥数见getPriorKeyCount。CSI 相关的单元测试覆盖于 pkg/operator/ceph/csi 目录。非守护进程密钥轮换CephBlockPool / CephFilesystem / CephClient除 CephCluster 外以下 CR 也承载非守护进程密钥CephClient—— 创建的可任意使用的 client 有一个关联密钥CephBlockPool—— 为池生成镜像对等令牌peerCephFilesystem—— 为文件系统生成镜像对等令牌peer。CephBlockPool对等令牌跟随集群级 rbdMirrorPeerRBD 镜像对等令牌内的密钥在 Ceph 侧被硬编码为client.rbd-mirror-peer用户因此单个 RBD 镜像密钥在 CephCluster 级别轮换即上文status.cephx.rbdMirrorPeer但 CephBlockPool 仍需更新自身状态标识对等令牌已换成最新版本。CephBlockPool 控制器应在父级 CephCluster 的status.cephx.rbdMirrorPeer更新时触发 reconcile创建 bootstrap token 时把CephCluster.status.cephx.rbdMirrorPeer拷贝到自己的status.cephx.peerTokenkind: CephBlockPool # ... status: # ... cephx: peerToken: keyGeneration: 2 keyCephVersion: 20.2.2对应的源码类型为 types.go 的PeerTokenCephxStatuspeerToken字段内嵌标准CephxStatus。CephFilesystem mirror设计与rbdMirrorPeer/peerToken一致针对 CephFS 镜像设计做相应适配。CephClient最简单的一对一接口CephClient 只有一个密钥既可当守护进程密钥也可当对等令牌因此接口被简化为直接内嵌CephxConfig源码 types.go 的ClientSecuritySpec状态字段见CephClientStatus.Cephxkind: CephClient # ... spec: # ... security: cephx: keyRotationPolicy: Disabled | WithCephVersionUpgrade | KeyGeneration keyGeneration: int # used with KeyGeneration # (room for future spec.security options) # ... status: cephx: keyGeneration: 1 # e.g. keyCephVersion: 20.2.0 # e.g.未使用密钥的清理Ceph 会自动创建一些 Rook 并不使用的密钥。Ceph 团队表示未来会修改 Ceph 停止创建这些密钥在改动落地之前Rook 删除它们是安全的未使用密钥无需轮换直接删除client.bootstrap-rgwclient.bootstrap-rbdclient.bootstrap-mgrclient.bootstrap-mds依赖与 CephX 技术背景Rook 的密钥轮换依赖Ceph Tentaclev20新增的ceph auth rotate命令Ceph PR #58121。理解 CephX 的几个关键技术点对开发与排障至关重要Rook 铸造的 CephX 密钥只用于守护进程的初始连接Ceph 内部所有连接使用具有阶梯式过期时间的 service 密钥默认情况下service 密钥允许密钥轮换后至少 2 小时窗口供客户端更新共有 3 个 TTL 分别为 1 小时、2 小时、3 小时的 service 密钥即使第一个 TTL 即将到期到 3 小时 TTL 到期也仍有至少 2 小时Ceph 不允许同一 client/daemon 的 keyring 中存在多个密钥轮换时旧密钥被移除、新密钥直接替换没有双密钥并存的过渡期这正是重叠轮换通过新建用户而非双密钥实现的原因auth_service_ticket_ttl与auth_mon_ticket_ttl配置可缩短/延长上述窗口但生效不是即时的内部 service 密钥更新需要时间debug_auth30可输出最大级别的 CephX 调试日志是开发阶段的排障利器。与既有方案的对比Prior ArtKubernetes 静态加密密钥轮换K8s 文档中的做法由用户负责生成密钥而 Rook 负责生成 CephX 密钥因此该设计无法直接迁移IBM Credential Rotator Operator自动轮换应用密钥并随后重启应用 Pod通过PreviousResourceKeyID状态展示信息。由于 Ceph 密钥没有与轮换关联的 ID这与 Rook 自行跟踪密钥版本key version元数据的思路类似但不完全相同。源码阅读路线图如果想在仓库中继续深挖本设计的具体实现推荐按以下路径阅读pkg/apis/ceph.rook.io/v1/types.goClusterSecuritySpec、ClusterCephxConfig、CephXConfigWithPriorCount、CephxConfig等公开 API 类型pkg/apis/ceph.rook.io/v1/types.goCephxStatus状态结构pkg/operator/ceph/config/keyring/cephx.goShouldRotateCephxKeys、UpdatedCephxStatus及CephAuthRotateSupportedVersion19.2.3版本门槛pkg/operator/ceph/config/keyring/cephx_test.go 与 pkg/operator/ceph/cluster/mgr/mgr_test.go轮换判定与状态更新的单元测试pkg/operator/ceph/csi/secrets.goCSI 重叠轮换实现带代际后缀的用户名、旧密钥清理、priorKeyCount上报pkg/apis/ceph.rook.io/v1/types.goPeerTokenCephxStatus对等令牌状态。总结Rook 的 CephX 密钥轮换设计以守护进程密钥自动轮换、非守护进程密钥由用户按需触发为总原则用keyGeneration代际机制提供了幂等、可观测、防回退的轮换接口用重叠轮换解决了 CSI 密钥轮换与大规模节点维护窗口不匹配的工程难题并通过临时client.admin-rotator用户与完整的失败恢复流程把最危险的 admin 密钥轮换风险降到可控范围。配合status.keyGeneration与status.keyCephVersion两个状态字段管理员可以精确判断任何一次轮换是否完成从而在维护窗口内安全地协调应用侧密钥更新。赞分享云原生存储容器编排运维【免费下载链接】rookStorage Orchestration for Kubernetes项目地址https://gitcode.com/gh_mirrors/roo/rook点击查看免费下载相关推荐Rook CephX 密钥类型与密钥轮换实战指南从 AES 到 AES256K 与 CVE-2025-30156 修复Rook CephX 密钥类型与密钥轮换实战指南从 AES 到 AES256K 与 CVE 2025 30156 修复 Rook 作为 Kubernetes云原生存储容器编排运维Rook Ceph 密钥管理系统KMS接入与 OSD 加密密钥轮换实战指南Rook Ceph 密钥管理系统KMS接入与 OSD 加密密钥轮换实战指南 本指南以 Rook 官方文档为骨架系统讲解如何在 Rook 管理的 Ceph云原生存储容器编排运维Rook OSD 密钥加密密钥KEK轮换机制设计与实现深度解析Rook OSD 密钥加密密钥KEK轮换机制设计与实现深度解析 本指南以 Rook 设计文档 design/ceph/key encryption key云原生存储容器编排运维创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考