注意
Atlas支持使用带有静态加密 (EAR) 的Azure Key Vault ( AKV ) 进行无密钥身份验证。使用此模型，您无需向Atlas提供长期静态凭证（租户ID、客户端ID和客户端密钥）。相反，您可以在Azure租户中授权 Atlas 20托管的Azure服务主体，然后Atlas使用Azure Active Directory ( Azure AD) 颁发的短期 OAuth. 访问权限令牌向 AKV 进行身份验证。
这种方法：
无需在Atlas中创建、存储和轮换客户端密钥。
使用Azure RBAC 或 Key Vault访问权限策略在Azure中完全集中访问权限控制。
保留集群和应用程序的现有 EAR 行为。仅身份验证机制发生变化
Secretless EAR 依赖Azure AD 和Azure Key Vault作为安全边界。 Atlas不存储可重用的客户托管密钥，而是在运行时使用Azure颁发的令牌。访问是使用最小权限原则执行的，您可以删除Azure权限以立即撤销这些权限。
Atlas使用直接角色分配给 Atlas 托管的服务主体，以实现更简单、安全的身份验证模型。
先决条件
要为MongoDB项目启用使用 AKV 的客户托管密钥，您必须具备：
M10 或更大的集群。
Azure帐户，以及 AKV 中的加密密钥。
要学习；了解如何配置这些Azure组件，请参阅 Azure文档。
Atlas 在为 Atlas 项目中的集群启用静态加密时使用这些资源。
Azure中的以下权限：
在租户中注册企业服务主体。此先决条件需要Microsoft Entra ID权限才能添加或管理企业应用程序，例如应用程序管理员、云应用程序管理员或全局管理员。
使用以下选项之一访问 Key Vault 密钥：
Atlas中要启用静态加密的项目的“项目所有者”访问权限。
Considerations
要使用存储在 AKV for EAR 中的客户托管密钥，Atlas 托管的服务主体必须有权对特定 Key Vault 密钥执行加密操作。
所需的关键权限包括：
getencryptdecrypt
您应尽可能缩小权限范围，并使用以下选项之一授予权限：
设置 EAR AKV 无密码身份验证
要使用无密钥身份验证配置静态加密 (EAR)，您必须：
创建 Atlas 托管的Azure服务主体。
授予服务主体对 Key Vault 密钥的访问权限。
配置 EAR 以使用服务主体。
创建 Atlas 托管的Azure服务主体
在租户中为 Atlas 拥有的Azure应用程序创建Azure服务主体，并使用 Cloud Provider Access API将其注册到Atlas 。roleId Atlas返回启用EAR 时使用的 。
Atlas使用以下Azure应用程序标识：
atlasAzureAppId: 9efedfcc-2eca-4b27-a613-0cad1e114cb7
向Atlas注册服务主体。
端点：
POST /api/atlas/v2/groups/{groupId}/cloudProviderAccess
请求正文示例：
{ "providerName": "AZURE", "tenantId": "<azure-tenant-id>", "servicePrincipalId": "<service-principal-object-id>", "atlasAzureAppId": "9efedfcc-2eca-4b27-a613-0cad1e114cb7" }
Atlas预配和管理服务主体，并返回id 值，这是配置roleId EAR 时所需的 。
授予 AKV 权限
授权 Atlas 托管的服务主体对用于 EAR 的 Key Vault 密钥执行加密操作。
您可以使用Azure RBAC 或 Key Vault访问权限策略授予访问权限。
使用Azure RBAC 授予访问权限
要使用Azure RBAC 授予访问权限，请执行以下操作：
分配读取者角色，以便Atlas可以读取密钥保管库元数据。
运行以下命令：
az role assignment create \ --assignee-object-id "$SERVICE_PRINCIPAL_OBJECT_ID" \ --assignee-principal-type ServicePrincipal \ --role "Reader" \ --scope "/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.KeyVault/vaults/$KEY_VAULT_NAME"
分配加密角色，例如 Key Vault 加密用户。
运行以下命令：
az role assignment create \ --assignee-object-id "$SERVICE_PRINCIPAL_OBJECT_ID" \ --assignee-principal-type ServicePrincipal \ --role "Key Vault Crypto User" \ --scope "/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.KeyVault/vaults/$KEY_VAULT_NAME"
注意
您还可以使用自定义角色，只要它授予等效的密钥权限。
使用密钥保管库访问策略授予访问权限
如果您的密钥保管库使用了访问权限策略，运行以下命令直接授予密钥权限：
az keyvault set-policy \ --subscription "$SUBSCRIPTION_ID" \ --resource-group "$RESOURCE_GROUP" \ --name "$KEY_VAULT_NAME" \ --object-id "$SERVICE_PRINCIPAL_OBJECT_ID" \ --key-permissions get encrypt decrypt wrapKey unwrapKey
配置静态加密以使用无密钥身份验证
在Azure中注册并授权服务主体后，使用 roleIdCloud Provider Access API返回的 更新EAR 配置。
在Atlas中，转到项目的Advanced 页面。
如果尚未显示，请从导航栏上的 Organizations 菜单中选择包含项目的组织。
如果尚未显示，请从导航栏的 Projects 菜单中选择您的项目。
在侧边栏中，单击 Security 标题下的 Database & Network Access。
在侧边栏中，单击 Advanced。
显示“高级”页面。
配置身份验证方法。
Atlas支持两种 AKV身份验证方法：
服务主体（推荐）：使用 Atlas 托管的特定于您的项目的服务主体对 AKV 进行身份验证（此处介绍无密钥身份验证）。
静态档案：提供客户管理的凭证。要学习；了解详情，请参阅通过公共网络使用Azure Key Vault管理客户数密钥或通过私有端点使用Azure Key Vault管理客户数密钥。
输入Encryption Key 。
密钥标识符 | 输入在密钥库中创建的密钥的完整 URL。 重要提示：密钥标识符必须以完整的Azure通用格式提供： |
（可选）配置与 AKV 的私有端点连接。
要学习；了解更多信息，请参阅为项目启用和设置私有端点连接
验证网络设置。
如果使用Atlas Administration API配置Atlas使用Azure Private Link与AKV通信，以确保Atlas和 Key Vault 之间的所有流量都通过Azure的专用网络接口进行，则Atlas会将Require Private Networking状态设置为Active 。 如果状态为Inactive ，并且您希望Atlas使用 AKV 的私有端点连接，则可以选择完成 为项目启用和设置私有端点连接 的步骤。
端点：
PATCH /api/atlas/v2/groups/{groupId}/encryptionAtRest
请求正文示例：
{ "azureKeyVault": { "enabled": true, "roleId": "<atlas-managed-roleId>", "subscriptionID": "<subscription-id>", "resourceGroupName": "<resource-group>", "keyVaultName": "<key-vault-name>", "keyIdentifier": "https://<vault>.vault.azure.net/keys/<key>/<version>", "azureEnvironment": "AZURE" } }
在此更新后， Atlas使用短期Azure AD 令牌而不是静态凭证对 AKV 进行身份验证。
从静态档案迁移
如果您的项目已使用静态凭证（tenantId、clientId、secret），则无需集群即可迁移。
创建 Atlas 托管的服务主体。
授予密钥保管库权限。
使用新的
roleId修补 EAR 配置。
如果验证失败， Atlas会继续使用静态凭证。
如果验证成功， Atlas会删除存储的静态凭证，并且 roleId 成为身份验证的可信来源。
如果您的集群使用专用网络， Atlas会从数据节点异步验证“密钥保管库”访问权限。
接受
PATCH请求时，不会立即完成验证。应用配置后，数据节点会验证 Key Vault访问权限。
在使用 roleId 修补 EAR 之前，请确保所有密钥保管库权限均已正确配置。访问权限权限配置错误可能导致数据节点验证失败，最终可能扰乱 EAR 操作并导致集群关闭。
在修补 EAR 之前，请验证您的服务主体是否具有所需的密钥保管库权限。
验证Azure RBAC 角色分配
运行以下命令：
az role assignment list \ --assignee "$SERVICE_PRINCIPAL_OBJECT_ID" \ --scope "/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.KeyVault/vaults/$KEY_VAULT_NAME"
确认分配的角色授予密钥权限，例如 get、encrypt 和 decrypt。
验证密钥保管库访问策略
运行以下命令：
az keyvault show \ --name "$KEY_VAULT_NAME" \ --resource-group "$RESOURCE_GROUP" \ --query "properties.accessPolicies"
确认服务主体已列出并包含所需的密钥权限。