如何为多租户应用实现本地/Dev/Prod多环境的密钥管理

核心原则是不修改tenant_id本身，通过「环境标识+资源分层」实现隔离，完全兼容现有tenant_id用于Azure API调用的逻辑

1. 凭证层适配（兼容AWS SecretsManager现有逻辑） #

• 调整SecretsManager的密钥命名规则为：{环境标识}/{tenant_id}，环境标识对应dev/test/staging/prod等不同环境
• 代码层面新增全局环境变量APP_ENV，启动时自动注入，获取凭证时自动拼接前缀：secret_name = f"{os.getenv('APP_ENV')}/{tenant_id}"
• 原有生产环境的密钥可以做别名映射，不需要批量迁移，不影响线上业务

2. 数据库层适配（解决跨环境连接冲突） #

• 每个环境单独部署一套数据库集群，同tenant_id在不同环境的数据库实例完全隔离，数据互不干扰
• 本地开发环境如果需要访问预发DocumentDB，统一通过环境内部的API网关做代理，不要直接用SSH隧道：在预发环境部署一个轻量数据库代理服务，本地配置预发环境的代理端点即可，不需要修改代码里的连接逻辑，避免端点URL不匹配的问题
• 测试环境可以用兼容DocumentDB协议的本地仿真工具跑，不需要连接云端预发资源

3. 运行时路由适配（完全兼容Azure GraphQL API调用） #

• 代码层面的tenant_id始终使用原始的Azure Tenant ID，不需要做任何映射/修改，调用Azure GraphQL API时直接透传，保证接口可用性
• 只有在访问内部基础设施（数据库、缓存、对象存储等租户专属资源）时，才会自动拼接全局环境变量做资源定位，完全不影响第三方接口的调用逻辑

4. 可选的兜底兼容方案 #

如果暂时不想修改SecretsManager的命名规则，可以单独给不同环境部署独立的SecretsManager实例，每个实例内部还是用tenant_id作为密钥名，通过IAM权限控制不同环境的服务只能访问对应环境的SecretsManager实例，代码层面不需要做任何修改，只需要调整不同环境的服务角色权限即可。

内容的提问来源于stack exchange，提问作者rvwsd