凭据管系统建好了，真正的挑战是"怎么接进各种业务"。不同技术栈、不同改造意愿，接入方式天差地别。安当 SMS 提供六种典型接入场景，本文逐一拆解定位、配置要点与最佳实践，并给出选型决策逻辑。
一、六种场景总览
| 场景 | 核心机制 | 技术要点 |
|---|---|---|
| 🔧 Jenkins 插件 | 构建时动态取密 | 全局配置 + 远端定位；withCredentials 块 |
| ☕ Spring Boot | 启动时自动解密注入 | SMS{}占位标记；application.yml |
| ☸️ Kubernetes | ServiceAccount 身份获取 | init/sidecar 模式；bundle.json 文件 |
| 📦 代理注入 | 黑盒应用启动前注入 | sms-cli + 启动脚本；环境变量注入 |
| 👤 LDAP | 专用技术账号托管 | 目录服务密码轮转；生产30天/测试7天 |
| 🐰 RabbitMQ | 最小权限分发 | 仅发布/仅消费；禁止.*通配 |
二、Jenkins：职责分离，分层配置
- 定位：Jenkins 负责构建执行，SMS 负责凭据托管，职责分离。
- 配置分层：全局配置只放 SMS 连接与认证参数（Base URL / Domain / App ID / App Secret / 客户端私钥 PEM / TLS 校验 / 超时 / 签名时间偏移）；单条 Jenkins 动态凭据只放远端定位信息（Jenkins ID / Description / SMS Label / SMS Version / 凭据类型）。
- 凭据设计：一条 Jenkins 凭据对应一条 SMS 远端凭据（一个
label + version），便于审计/定位/控权/轮换。命名规范（稳定可读可复用）：mysql-prod-app、ldap-test-admin、rabbitmq-prod-publisher；禁止 UUID 当长期业务 ID。 - Pipeline：先做"注入验证"再做"业务验证"；不回显明文，不依赖日志脱敏；同一 Stage 内同一
withCredentials块完成相关操作。
三、Spring Boot：业务代码"零改造"
application.yml中用SMS{...}标记敏感配置（不落盘明文），启动时自动解密注入 Spring Environment，业务代码零改造；可选运行期轮转刷新。
ksp:sms:enabled:trueurl:https://<ksp-sms-host>domain:1appKey:${KSP_SMS_APP_KEY}# 仅来自环境变量/启动参数/外部密钥系统appSecret:${KSP_SMS_APP_SECRET}version:""cipherPrefix:"SMS{"jsonKey:"value"spring:datasource:username:SMS{mysql00:username}password:SMS{mysql00:password}- 解密失败策略（生产前评审达成一致）：强安全/强一致场景
fail-fast（解密失败直接终止启动），避免"带密文运行"；兼容场景允许启动但必须告警。 - 运行期轮转刷新：
refresh.enabled=true+leadTimeSeconds: 300；Hikari 连接池热更新（更新用户名/密码并逐步淘汰旧连接，validateOnRotate=true避免切到无效凭据，hikariEnabled: true）。 - 安全强制：
appKey/appSecret只允许环境变量注入，默认值应为空且启动时校验必填；排障日志仅打印命中/key/错误码。
四、Kubernetes：显式注入 vs 自动注入
| 方案 | 实现 | 适用场景 |
|---|---|---|
| 显式注入 | 业务在 Helm/ Pod YAML 显式加入sms-agent（init 模式拉一次 / sidecar 模式持续刷新） | 首次 PoC、单业务试点、不希望新增 Webhook |
| 自动注入 | 平台部署注入器，基于 MutatingAdmissionWebhook 自动补齐容器/卷/挂载/私钥 Secret | 多业务多命名空间、平台化治理、批量推广 |
统一架构原则：身份统一（固定 ServiceAccount，按namespace + serviceAccountName绑定角色）；凭据消费统一（业务优先从/sms/secrets读取bundle.json）；密钥管理统一（RSA 私钥通过 K8S Secret 管理，不写镜像/代码仓库）；交付边界统一（平台侧负责能力/注入组件，集群管理员负责策略/Webhook，业务团队负责读取逻辑/验收）。静态凭据用 init 模式，动态凭据用 sidecar 模式。
推荐"三步走"：先单业务验证登录/取密/解密/文件输出 → 再验证文件读取与动态重载 → 最后推广到统一模板或自动注入模式。
五、代理注入：黑盒应用不改造
通过启动代理（sms-cli+ 启动脚本）在进程启动前注入敏感参数，适合无法改造的黑盒应用。交付包含app.jar、sms-cli、sms-launcher.sh、.sms-cache.enc（加密缓存灾备回退）。
- 安全要点：禁止命令行参数传明文密码，改用环境变量或临时文件（用后删除）；禁止默认模式打印明文到 stdout/stderr。
- 缓存回退：
cache.enabled: true时 live 拉取失败读本地加密缓存（AES-GCM，禁明文落盘）；缓存密钥SMS_CACHE_KEY由客户侧定义并环境变量注入（建议 ≥32 字符强随机串）；缓存必须有 TTL（如 10 分钟）。
六、LDAP 与 RabbitMQ：专用账号 + 最小权限
- LDAP：优先创建专用技术账号 + 平台托管密码生命周期；每系统/每环境/每类用途独立账号；根凭据必须用客户侧专用服务账号（仅查用户/改密码/读组信息），不得用目录超级管理员。统一开启密码轮转，生产 30 天、测试 7 天；账号纳入平台后改密必须统一通过平台，禁止绕开平台人工改密。
- RabbitMQ：生产者/消费者/测试/生产均独立，命名
系统名_用途_环境（如order_publish_prod）。权限四项参数：vhost/configure_regex/write_regex/read_regex。标准仅两类——仅发布 / 仅消费；configure_regex默认必须为空。
权限红线（禁止）：.*全通配权限；全量配置权限；管理员角色；生产消费共用同一账号；多系统共用同一业务账号。验收以实际消息行为为准（仅发布账号可发指定 Exchange 不可消费目标 Queue），业务账号能否登录管理 UI不作为验收标准。
七、小结
选型一句话：能改代码用 SDK/Starter，改不动用代理注入，编排环境用 K8s 注入器，中间件/目录服务用专用账号最小权限托管。无论哪种，记住三条铁律：凭据不落盘、不回显、生产不关 TLS 校验。
关键词：凭据管理 / 密钥管理 / 接入场景 / 最小权限 / Spring Boot / 等保合规 / 安当SMS / Kubernetes