MongoDB 4.2 服务器不处理 KMS 配置，kmsProviders 是驱动层参数，仅由客户端驱动（如 mongosh 或应用驱动）在连接时解析并调用云厂商 SDK 获取 CMK，mongod 完全不识别该配置项。
MongoDB 4.2 不支持直接通过驱动或 mongosh 配置 Amazon KMS 或 Azure Key Vault 作为密钥管理服务（KMS）提供商——它只支持客户端字段级加密（CSFLE），而 CSFLE 的 KMS 集成必须由应用层驱动完成，数据库本身不“配置”KMS。
为什么 MongoDB 4.2 里找不到 kmsProviders 配置项
MongoDB 4.2 的服务器端（mongod）完全不解析或处理 KMS 凭据。所谓“使用 KMS 加密”，实际发生在应用连接发起时：驱动（如 Node.js 的 mongodb 包、Python 的 pymongo）在建立连接时接收 kmsProviders 对象，用它调用 AWS/GCP/Azure 的 SDK 获取客户主密钥（CMK），再用 CMK 加密数据加密密钥（DEK）。服务器只看到已加密的 BinData 字段，不参与密钥生命周期。
- 你在
mongosh里执行KeyVault.createKey()时传的kmsProviders是传给驱动的，不是存进数据库的配置 -
mongod.conf中没有kms、keyVault或类似字段；启用加密存储引擎（ESE）是另一套机制，和 CSFLE 无关 - Atlas 控制台里的 “Encryption at Rest using your Key Management” 开关，底层调用的是 Atlas 管理 API，不是 MongoDB 4.2 本身的特性
KeyVault.createKey() 调用失败的常见原因
这个方法在 mongosh 中创建 DEK 并用 CMK 加密它，失败几乎总是因 KMS 凭据或网络问题导致，而非 MongoDB 版本限制：
- 没在连接字符串中启用自动加密：
autoEncryption选项未开启，或kmsProviders对象缺失/格式错误（例如aws下漏了accessKeyId和secretAccessKey） - Azure 场景下，
kmsProviders.azure.keyVaultEndpoint必须是完整 URL（如https://myvault.vault.azure.net/），末尾斜杠不能少；keyVersion若显式指定，必须与 Azure Portal 中显示的版本号完全一致（含短横线） - AWS 场景下，
aws.masterKey中的region必须和 KMS 密钥所在区域严格匹配（如us-east-1≠us-east-2） - 本地运行时未配置对应云厂商 CLI 凭据（
~/.aws/credentials或AZURE_CLIENT_ID环境变量缺失）
真正需要你动手配的地方只有应用连接层
以 Node.js 为例，关键不是改 MongoDB，而是构造正确的连接选项：
const client = new MongoClient(uri, {
autoEncryption: {
keyVaultNamespace: "encryption.__keyVault",
kmsProviders: {
aws: {
accessKeyId: process.env.AWS_ACCESS_KEY_ID,
secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY
},
azure: {
clientId: process.env.AZURE_CLIENT_ID,
clientSecret: process.env.AZURE_CLIENT_SECRET,
tenantId: process.env.AZURE_TENANT_ID,
keyVaultEndpoint: process.env.AZURE_KEY_VAULT_ENDPOINT
}
}
}
});
-
keyVaultNamespace必须指向一个真实存在的集合（通常是encryption.__keyVault），且该集合需有正确 schema（由驱动自动创建或手动初始化） - 同一应用中不能混用多个 KMS 类型（比如同时填
aws和azure）除非明确需要多租户密钥隔离，否则会增加调试复杂度 - 如果使用 Atlas，
uri必须包含?tls=true，否则 KMS 调用可能因证书校验失败静默中断
容易被忽略的权限与部署约束
即使代码写对，环境权限不到位也会卡在最后一步：
- Azure 场景下，注册的应用（App Registration）必须被授予 Key Vault 的
Key Vault Crypto User角色，仅Reader不够；且 Key Vault 的访问策略需启用 “Allow access from Azure services”（或明确添加你的 Atlas VPC 的 IP 段） - AWS 场景下，IAM policy 必须显式允许
kms:Decrypt和kms:GenerateDataKey，仅kms:DescribeKey无法创建 DEK - Flex 集群或 M0/M2 免费版 Atlas 集群不支持 CSFLE，启用后连接会直接报错
ClientSideFieldLevelEncryptionError: Auto encryption is not supported on this deployment - 所有操作必须在项目拥有
Project Owner权限的账号下进行；Organization Owner 需先把自己加为 Project Owner，否则KeyVault.createKey()会返回 403
真正卡点往往不在代码语法，而在 KMS 凭据作用域、网络可达性、以及 Atlas 集群规格是否隐式禁用了加密能力——这些地方没日志、不报具体错误，只能逐层验证。
