配置中心与密钥与证书

共 20 题
📑 题目列表 20 题
#
★★★

1. Spring Cloud Config Server 如何为客户端提供配置，即配置存储、读取与刷新机制是怎样的？

问题

请说明 Spring Cloud Config Server 作为配置中心，是如何存储、读取配置并支持客户端动态刷新的，其完整机制是怎样的？

考察点
  • 配置存储的 backend 与版本化方式
  • 客户端拉取配置的原理与路径解析
  • 配置刷新机制（refresh / bus / 原生）
答案

Spring Cloud Config Server 将配置存储在 Git（默认）、SVN 或本地文件系统中，通过 /{application}/{profile}/{label} 三要素定位配置，并支持按 label 实现版本化与回滚。客户端通过 spring-cloud-config-client 在启动时从 Server 拉取配置，Server 会解析 Git 仓库中的配置文件，将多个配置文件聚合为环境（Environment）返回给客户端。为支持运行时热更新，客户端可通过 @RefreshScope 注解标注需要刷新的 Bean，配合 /actuator/refresh 端点触发刷新；大规模场景下可借助 Spring Cloud Bus（RabbitMQ/Kafka）向所有实例广播刷新事件，实现一次触发全量刷新。原生刷新一般只影响标记了 @RefreshScope 的 Bean，不会重建整个应用上下文。

解析

理解该机制的核心在于区分"启动时加载"与"运行中刷新"两类场景：启动时只有单体配置 Server 地址即可；运行中刷新则依赖 RefreshScope 与 Bus 的配合。实践上要明确刷新对已建立的连接、线程池等非 RefreshScope 资源无效，需重启或自定义刷新逻辑。

示例代码
# 客户端启动时拉取配置：bootstrap.yml 中指定 Server 地址
# spring.cloud.config.uri=http://config-server:8888
# 触发单实例刷新（需引入 spring-boot-starter-actuator）
curl -X POST http://client-app/actuator/refresh
# 通过 Spring Cloud Bus 广播刷新
curl -X POST http://config-server/actuator/busrefresh
#
★★★

2. 多环境多命名空间治理与权限审计

问题

在多环境（开发/测试/生产）与多命名空间场景下，如何对配置中心进行环境治理、权限隔离与审计？

考察点
  • 环境与命名空间隔离模型
  • 基于角色的权限控制（RBAC）
  • 配置变更的审计追踪
答案

多环境治理的核心是环境的物理或逻辑隔离：生产环境应使用独立的配置中心实例或独立的命名空间，避免跨环境误改；同时通过命名空间（如 Nacos 的 namespace、Apollo 的 appId+cluster）做租户级/模块级隔离。权限上采用 RBAC，将"谁可以改哪个环境哪个命名空间"建模为角色与权限点，遵循最小权限原则，生产变更需更高权限并走审批流。审计方面记录每次配置变更的操作人、时间、前后值、来源 IP，形成不可篡改的审计日志，并与合规留存（如按法规保留一定周期）结合。定期对权限与配置做盘点，识别闲置账号与越权配置。

解析

多环境治理的关键是"隔离"与"流转"的平衡：既要保证环境间互不影响，又要方便配置随环境逐级晋升（如通过 GitOps 的 Promotion 流程）。权限审计的核心是"可追溯、可问责"，需保证审计日志与权限模型的联动。

#
★★★

3. 配置变更的审计日志与合规留存

问题

如何为配置变更建立审计日志，并满足合规留存的要求？

考察点
  • 审计日志的采集内容与时机
  • 防篡改与留存周期
  • 合规要求（如安全审计、等保）
答案

配置变更审计日志应记录四要素：谁（操作人/账号）、何时（时间戳）、做了什么（变更前后配置键值）、在哪（环境/命名空间/来源 IP），同时记录操作终端与审批单号。审计日志需具备防篡改能力，常见做法是写入只追加（append-only）的存储、使用 WAL/哈希链或接入独立的审计系统，并限制删除权限。留存周期需满足合规要求（如等保、ISO 27001 通常要求 6 个月以上，金融监管可能更长），因此需将热日志与冷归档分离，并定期导出一份不可变副本。审计日志还应支持查询与告警，例如敏感配置被修改、非常规时段的变更等应触发告警。

解析

合规留存的本质是"可证明"——不仅要有日志，还要能证明日志未被篡改、在需要时能被完整回溯。所以审计与配置变更动作应耦合（在变更时同步生成审计），而非事后补录。

#
★★

4. Apollo/Nacos/Consul/etcd 选型对比与适用场景

问题

请对比 Apollo、Nacos、Consul、etcd 作为配置中心/服务发现的选型差异与适用场景？

考察点
  • 各产品定位与核心能力
  • 配置管理 vs 服务发现 vs 存储
  • 生态与运维复杂度
答案

Apollo 定位为成熟的配置中心，支持配置的热发布、灰度发布、版本回滚、多环境多集群管理和完善的权限审计，适合对配置治理要求高的大型平台；Nacos 兼具配置管理与服务发现，支持动态配置与命名空间隔离，是 Spring Cloud Alibaba 生态的标配；Consul 强于服务发现与健康检查，内置 KV 也能做简单配置，但配置管理能力较弱；etcd 本质是分布式 KV 存储，是 Kubernetes 的底层存储，提供强一致性与 watch 机制，但配置管理能力需自行封装（无 UI、无灰度、无审计）。选型时需权衡：是否强依赖配置治理功能、是否已深度绑定某生态、数据一致性要求与运维成本。

解析

选型不是越强越好，而是看"治理能力"与"生态契合"：纯存储方案（etcd）灵活但需自建上层；Apollo 治理最强但较重；Nacos 在 Java 生态中平衡性好；Consul 适合服务发现为主的小团队。

#
★★

5. Argo CD 如何管理 Helm values 覆盖与参数化配置？

问题

在 GitOps 中，Argo CD 如何对 Helm chart 进行 values 覆盖与参数化配置管理？

考察点
  • Argo CD 的 Helm 集成方式
  • values 覆盖与参数覆盖
  • 环境差异化配置
答案

Argo CD 的 Application 配置中可指定 helm.values 直接内联 values、helm.valueFiles 引用仓库中的 values 文件，或通过 helm.parameters 以 key=value 形式覆盖单个参数。针对多环境差异，常用做法是目录化组织：每个环境一个 values 文件（如 values-dev.yaml、values-prod.yaml），通过 valueFiles 按环境选择，或用 valuesObject 传递结构化参数。Argo CD 还支持 helm.passCredentials 与私有仓库凭据注入。参数化配置的关键是"单一 truth 源"——所有变更均通过 Git 提交，Argo CD 依据 Git 中的声明持续同步，保证集群状态与 Git 一致。

解析

Argo CD 的 Helm 能力本质是"把渲染交给 Helm，把同步交给 Argo CD"，因此应把 values 的差异化收敛到 Git 中，避免在集群侧手工覆盖，从而保持 GitOps 的可审计与可回滚。参数覆盖顺序（高到低）：parameters > valuesObject > values（内联）> valueFiles。

#
★★

6. External Secrets Operator 如何把云厂商密钥同步为 K8s Secret，即 SecretStore 认证、ExternalSecret 的 remoteRef、refreshInterval 轮换与 force-sync 注解触发以及与 SealedSecret、SOPS 的适用边界？

问题

请说明 External Secrets Operator（ESO）如何把云厂商密钥同步为 Kubernetes Secret，包括 SecretStore 认证、ExternalSecret 的 remoteRef、refreshInterval 轮换与 force-sync 注解，以及与 SealedSecret、SOPS 的适用边界？

考察点
  • ESO 的架构与 SecretStore/ExternalSecret 概念
  • remoteRef 字段的作用与轮换机制
  • ESO 与 SealedSecret、SOPS 的定位差异
答案

ESO 由 SecretStore（定义后端密钥源与认证方式，如 AWS Secrets Manager、GCP Secret Manager、Vault）和 ExternalSecret（声明要同步的密钥、remoteRef 指定远端 key/version/property）组成。Controller 根据 refreshInterval 定期拉取远端密钥并写入命名空间内的 Secret，实现自动轮换；当需要立即同步时，可在 ExternalSecret 上加 force-sync 注解触发立即同步。SealedSecret 与 SOPS 是"静态加密"方案：把密钥在 Git 中以加密形式存储，落库/落 Git 时解密，适合无法直连云密钥服务的离线场景；而 ESO 是"动态拉取"方案，密钥不在 Git 中，运行时从云上获取。适用边界：ESO 适合云原生且密钥需频繁轮换的场景，SealedSecret/SOPS 适合 GitOps 中密钥需随仓库版本化的场景。

解析

核心区别是"密钥存储位置"：ESO 的密钥只存在于云端，K8s 中的 Secret 是动态副本；SealedSecret/SOPS 把加密后的密钥存在 Git 中。选择取决于对密钥生命周期、轮换自动化与离线可用性的要求。

示例代码
# ExternalSecret 示例：从 AWS Secrets Manager 拉取密钥
# apiVersion: external-secrets.io/v1beta1
# kind: ExternalSecret
# spec:
#   refreshInterval: 1h
#   secretStoreRef: { name: aws-store, kind: SecretStore }
#   target: { name: app-secret }
#   data:
#   - secretKey: password
#     remoteRef: { key: myapp/db, property: password }
# 手动触发立即同步
kubectl annotate externalsecret app-secret force-sync=true
#
★★

7. GitOps 模式下配置变更的完整流程，即从 Git 提交、评审到集群同步生效？

问题

请描述 GitOps 模式下配置变更从 Git 提交、评审到集群同步生效的完整闭环流程？

考察点
  • GitOps 的声明式与拉取模型
  • 变更评审与审批
  • 集群同步与漂移检测
答案

GitOps 的完整流程为：开发者修改配置清单（Helm values、Kustomize、YAML）并提交到 Git 仓库 → 通过 PR/MR 进行代码评审与 CI 校验（如 helm template、kubeconform 校验、secret 扫描）→ 合并到主干触发部署 → GitOps 控制器（Argo CD/Flux）持续监听 Git 仓库，检测到描述状态与集群实际状态不一致时执行同步 → 生效后通过 health 检查与状态回写确认。控制器还会持续做漂移检测，若集群状态被人为篡改则自动回滚到 Git 声明状态。变更可随时通过 revert 到任一 Git 提交实现回滚，保证整个变更过程可审计、可追溯。

解析

与 CICD 的 push 模型不同，GitOps 强调"集群状态以 Git 为唯一 truth"，同步由控制器在集群内主动拉取完成，这使得权限更收敛、可追溯性更强。评审与 CI 校验是质量门禁，同步是结果保障，漂移检测是持续纠偏。

#
★★

8. etcd raft 运维、容量与 compaction 管理

问题

如何对 etcd 集群进行运维管理，包括 raft 状态、容量规划与 compaction（压缩）管理？

考察点
  • raft 一致性成员与 leader 管理
  • 容量评估与磁盘要求
  • compaction 与 defrag 的关系
答案

etcd 运维需关注 raft 成员健康（leader 选举、跟随者同步、成员数建议奇数 3/5，容忍一半以下故障）、依赖磁盘 IO 与 fsync 持久化（WAL 顺序写）。容量管理上，etcd 默认限制 2GB 存储，需通过 --quota-backend-bytes 调整，并监控存储余量。历史版本会累积导致存储膨胀，需通过 etcdctl compact 压缩历史版本，再配合 etcdctl defrag 对物理空间做碎片整理（compact 只回收逻辑版本，defrag 才回收实际磁盘空间）。实践上应结合定期 compact + defrag，并监控 etcd_server_has_been_leader、etcd_mvcc_db_total_size_in_use 等指标，避免空间不足导致集群进入只读模式。

解析

运维要点是区分"逻辑版本回收"（compact）与"物理空间回收"（defrag）：compact 释放历史版本，defrag 才释放磁盘。容量规划需考虑 key 数量、watch 数量与历史版本保留，并预留 burst 空间。

示例代码
# 查看当前存储大小与 compaction 状态
etcdctl endpoint status --write-out=table
# 压缩到指定 revision
etcdctl compact 12345
# 对单个节点做碎片整理（需逐个执行）
etcdctl defrag --endpoints=http://127.0.0.1:2379
#
★★

9. 腾讯云 Secrets Manager 如何实现凭证管理？

问题

请说明腾讯云 Secrets Manager（凭据管理系统）如何实现服务的凭证管理？

考察点
  • 凭据的创建与版本管理
  • 凭据的动态轮换
  • 与云资源/应用集成
答案

腾讯云 Secrets Manager（SSM）支持创建明文或加密凭据，将密钥明文加密存储于内置 KMS 中，并提供版本管理（每次更新生成新版本，可指定版本号）。它支持动态轮换，通过自定义轮换函数周期性地更新凭据（如数据库密码），并可与 RDS 等数据库集成实现整库密码轮换。应用侧通过 SDK 或 API 获取凭据，或在 VPC 内通过 Endpoint 访问，避免明文落配置文件。SDK 侧做了缓存与异常处理，凭据获取失败时可回退到本地缓存以避免应用中断。权限通过 CAM 控制，可做到按账号/资源粒度授权。

解析

云厂商 Secrets Manager 的价值在于"托管"与"集中"：加密存储、版本化、自动轮换、细粒度权限，应用只需调用 API 获取，从而把密钥从代码和配置中剥离出来。

#
★★

10. 配置中心的高可用部署与跨地域复制

问题

如何实现配置中心的高可用部署与跨地域复制？

考察点
  • 配置中心 HA 架构
  • 跨地域数据同步
  • 容灾与切换
答案

配置中心 HA 需要至少三副本部署，数据库层使用主从或多可用区。跨地域复制通常采用"主地域写、从地域读"或双写多活：主地域配置中心负责写，通过消息/异步同步或数据库复制将配置数据同步到从地域，从地域提供只读与本地缓存服务，保证本地读写延迟低且单点故障时其他地域可继续服务。跨地域同步要考虑数据一致性与冲突，配置变化不大可采用就近缓存 + 定期同步。容灾切换时，客户端需支持多地址配置中心列表，故障时自动切换。对配置中心本身的不可用，客户端应保留本地缓存与默认值实现兜底。

解析

跨地域复制的关键是"读写分离 + 就近缓存 + 自动切换"：控制跨地域同步成本，同时保证本地可用性与最终一致性。配置中心 HA 不能只依赖单点，要结合客户端兜底形成完整韧性。

#
★★

11. 配置灰度发布与一键回滚的实现（版本化/监听/回滚点）怎么做，发布影响面如何控制？

问题

如何实现配置的灰度发布与一键回滚，包括版本化、监听与回滚点机制，以及如何控制发布影响面？

考察点
  • 配置版本化与灰度发布
  • 一键回滚与回滚点
  • 影响面控制与灰度策略
答案

配置灰度发布的核心是对配置做版本化管理，每次发布生成新版本号，支持多版本并行。灰度策略包括：按机器/实例灰度（先灰度一小批实例，观察无误后再全量）、按命名空间/环境灰度（先测试后生产）、按客户端版本/比例灰度（如 10% 流量）。配置中心提供监听机制，客户端通过 long-polling 或 websocket 感知配置变更。回滚时通过"回滚点"直接切换到历史版本，由于版本化管理，可立即回滚到任意已发布版本而不需要重新构造。影响面控制上，灰度前先做变更影响评估（列出受影响的服务与配置），配合审计日志与告警，灰度期间监控错误率与延迟，异常则触发快速回滚。

解析

灰度发布与回滚的前提是"版本化 + 可定位 + 可回退"：版本化让每次变更可追溯，回滚点让回退立刻可执行，灰度比例控制影响面。与代码发布类似，配置发布也应纳入 CI 门禁与监控。

#
★★

12. 配置热更新一致性与推送失败兜底

问题

配置热更新时如何保证一致性，以及推送失败时如何兜底？

考察点
  • 热更新的一致性保证
  • 推送失败与客户端兜底
  • 最终一致与补偿
答案

配置热更新一致性通常采用"最终一致"模型：服务端发布新配置后，通过长连接/推送通知客户端，客户端拉取新配置并应用。一致性挑战在于：多实例可能在不同时刻收到更新，导致短时间内实例间配置不一致；为此可引入版本号，客户端只接受比当前更新的版本，避免旧配置覆盖新配置。推送失败时，客户端应保留本地缓存配置作为兜底，不能因拉取失败而用空配置或导致服务不可用；同时配置中心应记录未送达的客户端，稍后重推或由客户端定期轮询补偿。对关键配置，可在客户端启动时校验缓存有效性，并保留"最近一次成功配置"作为降级值。

解析

热更新的一致性是"尽力而为 + 版本裁决 + 兜底降级"：用版本号防止乱序覆盖，用本地缓存兜底推送失败，用定期轮询补偿偶然丢失。关键在于"配置错误不能导致应用不可用"，兜底优先级高于严格的实时一致性。

#
★★

13. 配置与密钥分离的工程原则，即为什么密钥不能进配置中心明文存储以及配置中心加密钥管理服务（KMS/ESO）的分层设计？

问题

请说明"配置与密钥分离"的工程原则：为什么密钥不能明文进配置中心，以及配置中心 + 密钥管理服务（KMS/ESO）的分层设计？

考察点
  • 密钥明文进配置中心的危害
  • 配置中心与 KMS/ESO 的分层
  • 密钥引用与运行时解析
答案

密钥明文进配置中心的主要风险是：配置中心访问面广、有审计不严与备份泄露风险，明文密钥会扩大泄露面；且密钥与配置生命周期不同，密钥需要轮换，放在配置中心难以自动化。因此遵循"配置与密钥分离"：配置中心只存非敏感配置，密钥存放在专门的密钥管理服务（KMS、云 Secrets Manager、ESO 后端）中。分层设计上，配置中心中的敏感字段用"引用占位符"（如 ${secret:db/password}），应用运行时由密钥服务解析并注入，或由 ESO 把密钥同步为 K8s Secret 供应用挂载。密钥本身加密存储于 KMS，加解密通过 KMS 密钥加密（envelope encryption）实现，配置中心不接触明文密钥。

解析

该原则的核心是"最小暴露 + 生命周期分离"：把密钥从"广谱访问的配置"中剥离，收窄到专门的密钥管理，配合轮换与加密，大幅降低泄露风险。配置中心只负责"非敏感 + 需频繁变更"的配置。

#
★★

14. 配置的 Schema 校验与变更门禁中如何在配置发布前校验格式、类型与引用完整性以防止"格式对但语义错"的变更？

问题

如何在配置发布前进行 Schema 校验与变更门禁，校验格式、类型与引用完整性，防止"格式对但语义错"的变更？

考察点
  • 配置 Schema 定义与校验
  • 引用完整性与语义校验
  • 变更门禁与 CI 集成
答案

为防止"格式对但语义错"，需为配置定义 Schema（JSON Schema、YAML Schema 或自定义 DSL），在发布前校验字段类型、必填项、取值范围与枚举。仅做语法校验不够，还需做引用完整性校验：检查配置中引用的服务、资源、密钥是否存在，检查占位符引用是否有效，检查跨配置的关键依赖。将校验接入 CI 门禁，在配置提交/合并前强制执行，失败则阻断发布。针对语义错误，可增加"预检/试运行"：在测试环境用新配置启动应用做 smoke test，或校验配置与代码版本兼容性。对高危配置变更，可要求人工审批或灰度观察。

解析

核心是"把能自动化的校验前置到发布门禁"：Schema 校验解决格式/类型，引用校验解决依赖完整性，试运行解决语义正确性。三者叠加才能把"格式对但语义错"的变更拦截在发布前。

#
★★

15. 密钥轮换的自动化流程中双版本共存（active/previous）、客户端缓存失效与轮换失败回滚如何设计以及轮换窗口如何与审计配合？

问题

如何设计密钥轮换的自动化流程，包括双版本共存（active/previous）、客户端缓存失效与轮换失败回滚，以及轮换窗口如何与审计配合？

考察点
  • 双版本共存与平滑轮换
  • 客户端缓存失效策略
  • 失败回滚与审计配合
答案

自动化密钥轮换采用"双版本共存"策略：轮换时先生成新版本密钥（previous/active 并存），不立即废弃旧版本，而是让新旧版本在一段时间内同时有效，客户端在解密时优先用新版本，失败则回退到旧版本，保证服务在轮换期间不中断。客户端缓存失效方面，密钥服务应支持版本下发，客户端缓存新旧两个版本，并在轮换完成后一段宽限期后清理旧版本，避免缓存中残留旧密钥导致解密失败。轮换失败时，若新密钥在验证期内无法正常使用，可回滚到旧版本继续服务，并保留新密钥供排查。轮换窗口（何时轮换、宽限期多长）应与审计配合：轮换窗口内记录每次轮换的触发、成功/失败、新旧版本，并设置审计告警，确保轮换过程可追溯、失败可及时发现。

解析

平滑轮换的要点是"先共存、后切换、宽限期清理、失败回滚"：双版本共存保证兼容性，宽限期让所有客户端迁移完成，失败回滚保证可用性，审计配合保证可问责。核心是"轮换是常态，不能造成停机"。

#
★★

16. 配置中心的故障演练中配置中心不可用时客户端的本地缓存/默认值兜底如何验证以及推送链路中断对运行中应用的影响？

问题

如何开展配置中心故障演练，验证配置中心不可用时客户端的本地缓存/默认值兜底，以及推送链路中断对运行中应用的影响？

考察点
  • 故障演练的设计与场景
  • 本地缓存/默认值兜底验证
  • 推送链路中断的影响评估
答案

配置中心故障演练需设计完整场景：停掉配置中心服务或切断网络，验证客户端在无法拉到新配置时，是否仍能基于本地缓存或默认值继续运行，而不是崩溃或使用空配置。演练要验证三个层面：启动阶段（应用启动时配置中心不可用，能否用缓存/默认值启动）、运行阶段（运行中推送中断，已加载配置是否继续生效）、恢复阶段（配置中心恢复后客户端能否自动重新连接并同步最新配置）。同时要评估推送链路中断的真实影响：运行中的应用一般不受影响（配置已加载），但新启动实例、配置更新、以及依赖配置变更的滚动发布会受影响。演练后应记录观察指标、形成改进清单（如增强缓存、调整超时、增加重试）。

解析

故障演练的价值是把"配置中心不可用"的兜底能力从"设计上存在"验证为"实际可用"。通过演练暴露缓存不生效、超时设置不当、依赖配置中心才能启动等真实问题，推动改进。

#
★

17. AWS KMS 如何管理密钥，即密钥创建、轮换、授权与加解密调用流程？

问题

请说明 AWS KMS 如何管理密钥，包括密钥创建、轮换、授权与加解密调用流程？

考察点
  • KMS 密钥类型与创建
  • 自动/手动轮换
  • 授权与加解密调用
答案

AWS KMS 管理对称密钥（CMK）与非对称密钥对。创建时选择 key type（对称/非对称）、origin（AWS KMS 或外部），并配置 key policy 定义谁可以管理、谁可以使用。轮换方面，AWS KMS 支持自动轮换（每年默认，可配置）与手动轮换，自动轮换会生成新 backing key，但 key ID 不变，旧密钥用于解密历史数据。加解密调用流程为：数据加密时调用 Encrypt 用 CMK 加密小数据，或使用 GenerateDataKey 生成数据密钥（DEK）实现 envelope encryption——用 DEK 加密大数据，再用 CMK 加密 DEK。授权通过 key policy（resource 级）与 IAM policy 结合，遵循最小权限。解密时用同一 CMK 解密 DEK，再用 DEK 解密数据。

解析

KMS 的核心价值是"密钥不落应用侧"（CMK 不出 KMS），应用通过 envelope encryption 使用数据密钥，兼顾安全与性能。授权与审计是 KMS 的强项，可记录每次加解密调用。

#
★

18. GCP Secret Manager 如何管理凭证，即密钥版本、访问控制与轮换机制？

问题

请说明 GCP Secret Manager 如何管理凭证，包括密钥版本、访问控制与轮换机制？

考察点
  • Secret 与版本管理
  • IAM 访问控制
  • 轮换与调度
答案

GCP Secret Manager 以 Secret 为单元，每个 Secret 包含多个版本（version），添加新版本时指定 payload，可设置 enabled/disabled/destroyed 状态，应用通常引用"最新版本"或指定版本。访问控制通过 IAM 实现，为 secretmanager.secretAccessor 角色授予特定 Secret 或版本级权限，支持 - 通配符表示所有版本。轮换机制上，GCP 可通过 Secret Manager 的轮换功能搭配 Cloud Scheduler/Cloud Functions 定时调用 API 生成新版本并禁用旧版本，也可与 GKE 等集成。访问通过 API、SDK 或 gcloud 命令，应用侧可缓存凭据并定期刷新。

解析

GCP Secret Manager 的模型是"Secret-版本-访问控制"三层：版本化支持轮换与回滚，IAM 做细粒度授权，轮换通过调度任务实现。版本置为 destroyed 前有延长期以保护误删。

#
★

19. 华为云 CSMS 如何管理凭证，即凭据创建、版本管理与应用集成方式？

问题

请说明华为云凭据管理服务（CSMS）如何管理凭证，包括凭据创建、版本管理与应用集成方式？

考察点
  • CSMS 凭据模型与创建
  • 版本管理
  • 应用集成方式
答案

华为云 CSMS（凭据管理服务）基于数据加密服务（KMS）加密存储凭据，支持创建文本、二进制等类型凭据，并可与数据库密码轮换集成。版本管理上，每次更新凭据生成新版本，可通过版本号引用，支持凭据版本的回滚与禁用。应用集成方式：通过华为云 SDK/API 获取凭据，或在弹性云服务器/CCE 中通过 Metadata 或环境注入方式获取；也支持与数据库账号密码轮换联动，实现凭据自动更新。访问控制通过 IAM 策略实现，权限细化到某条凭据。凭据中心化管理便于统一轮换与审计。

解析

云厂商 CSMS 的共性价值是"加密存储 + 版本化 + 自动轮换 + 细粒度授权"，华为云 CSMS 在这些能力上与 AWS/GCP 类似，但集成生态侧重华为云（ECS/CCE/RDS）。

#
★

20. 配置变更的审计与盘点中谁在何时改了什么配置如何留痕以及敏感配置的访问告警与定期配置漂移检测？

问题

如何对配置变更进行审计与盘点，包括谁在何时改了什么配置的留痕、敏感配置访问告警与定期配置漂移检测？

考察点
  • 配置变更留痕与审计
  • 敏感配置访问告警
  • 配置漂移检测
答案

配置变更的留痕：配置中心在每次变更时记录操作人、时间、变更前后值、来源 IP 与审批单号，形成审计日志并支持查询。敏感配置的访问告警：对密钥、密码等敏感配置，记录访问行为，设置访问告警规则（如下班时间访问、异常 IP、高频率访问），触发告警并通知安全团队。配置漂移检测：定期对比配置中心的"期望配置"与集群实际运行配置，识别被手工修改或计划外变更的"漂移"配置，通过配置中心自带能力或 GitOps 控制器（如 Argo CD 的 drift detection）自动回滚到期望状态。定期盘点还包括：清理无用配置、检查权限有效性、识别敏感配置是否被明文外泄。

解析

审计与盘点的核心是"可追溯 + 可告警 + 可纠偏"：留痕让变更可追溯，敏感访问告警让泄露可及时发现，漂移检测让配置持续符合预期。三者的数据基础是完整、不可篡改的审计日志。