凭据管理系统一旦宕机，所有依赖动态取密的业务都会"断粮"。SMS 的部署不是"装起来能用"就行，而是要兼顾高可用、根密钥安全、信创合规、多场景接入。本文基于《安当 SMS 凭据管理系统部署最佳实践指南》梳理落地要点。

一、先看清整体架构

SMS 是典型的三层结构，所有接入场景都收敛到核心平台：

• ① 业务接入层：Jenkins 插件、Java Spring Boot Starter、Kubernetes（Agent/Sidecar）、黑盒应用的代理环境变量注入、LDAP、RabbitMQ；
• ② SMS 核心平台：统一托管、动态取密、权限控制、全程审计；
• ③ 凭据存储层：静态凭据（版本管理+轮换回退+四要素治理）与数据库动态凭据（根/子两层模型，TTL 续约回收，一应用一凭据）。

贯穿所有场景的六大核心设计原则：职责分离（业务只消费、SMS 托管）、运行时动态获取、绝不落盘绝不打印、最小权限、最小暴露最小输出、凭据以摘要形式验证而非明文回显。

二、三种部署方式怎么选

SMS 支持三种部署形态：

• 单机版：适合小规模环境快速验证；
• 集群版：主备高可用，适合生产环境，保证业务连续性；
• 定制化部署：按企业需求提供，所有方式均支持 HSM 硬件加密机接入。

生产环境强烈建议集群版：根密钥存储在 HSM 加密机中（硬件级密钥保护），配合主备容灾，避免单点故障导致凭据服务不可用。

三、Kubernetes 接入：Sidecar 内存注入

SMS 与 Kubernetes 的集成是 DevOps 场景的重点，统一架构原则有四条：

1. 身份统一：固定 ServiceAccount；SMS 按 namespace + serviceAccountName 绑定角色；测试/预发/生产用独立角色，避免权限串用；
2. 密钥管理统一：RSA 私钥通过 K8S Secret 管理，不写镜像/代码仓库；私钥 Secret 与业务负载同命名空间、命名统一；
3. 交付边界统一：平台侧负责 SMS 能力/注入组件/规范；集群管理员负责命名空间策略/Webhook/TLS/标签；业务团队负责 ServiceAccount/YAML/读取逻辑/验收；
4. 凭据不落盘：平台部署注入器基于 MutatingAdmissionWebhook 自动补齐容器/卷/挂载/私钥 Secret，Pod 启动时由 SMS 验证身份后动态下发凭据，支持 Sidecar 内存注入——凭据仅存在于容器内存，绝不落盘写入磁盘，从根本杜绝随镜像扩散。

四、边界与权限设计

• 环境隔离：开发/测试/预发/生产的凭据，其标签、值、审批、访问权限全部隔离，互不串用；
• 控制面与业务面物理分离：运行型服务不得长期持有管理型高权限凭据；
• 权限模型：优先创建专用业务账号 + 最小权限分发 + 生产消费分离；已有账号接管仅作存量迁移；
• 权限红线：禁止 .* 全通配、全量配置权限、管理员角色、生产消费共用账号、多系统共用同一业务账号。

五、信创与合规适配

SMS 已完成华为鲲鹏、麒麟等信创环境适配，依托通过国家密码局检测认证的 KSP 实现国密 SM2/SM4 合规；审计日志支持 Syslog 协议实时推送至 SIEM 平台，满足等保 2.0、ISO 27001、PCI DSS 要求，审计报告一键导出。

六、落地路径建议

先以静态凭据解决"明文散落+权限混乱"第一步 → 再按需引入动态凭据与自动轮换 → 最后打通 K8s/Jenkins 零明文 CI/CD 与 SIEM 审计。最终定调：让各接入方以标准、稳定、安全的方式成为 SMS 的动态凭据消费端——统一托管、统一治理、动态取密、更易轮换、更易审计。