Gestione las claves de cliente con Azure Key Vault (autenticación sin secretos).

Requisitos previos

Para habilitar claves gestionadas por el cliente con AKV para un Proyecto de MongoDB, es necesario tener:

• Un clúster M10 o más grande.

• La cuenta de Azure y la llave de cifrado en su AKV.

  Para aprender cómo configurar estos componentes de Azure, consulta la Documentación de Azure.

  Atlas utiliza estos recursos al habilitar el cifrado en reposo para un clúster en el proyecto Atlas.

• Permisos en Azure para:

  • Registrar un Service Principal empresarial en tu tenant. Este requisito previo requiere permisos de Microsoft Entra ID para agregar o administrar aplicaciones empresariales, como Administrador de Aplicaciones, Administrador de Aplicaciones en la Nube o Administrador Global.

    Para obtener más información, consulta Inicio rápido: Añadir una aplicación empresarial.

  • Acceso a la clave Key Vault utilizando una de las siguientes opciones:

    • Azure RBAC (en el ámbito de Key Vault o de clave)

    • Políticas de acceso de Key Vault

• Acceso de Propietario de Proyecto en Atlas para el proyecto en el que deseas habilitar el Cifrado en reposo.

Considerations

Para usar una clave gestionada por el cliente almacenada en AKV para EAR, el Principal de Servicio gestionado por Atlas debe tener permiso para realizar operaciones criptográficas en la clave específica de Key Vault.

Los permisos clave requeridos incluyen:

• get

• encrypt

• decrypt

Debe delimitar los permisos lo más estrechamente posible y concederlos utilizando una de las siguientes opciones:

• Azure RBAC (en el ámbito de Key Vault o de clave)

• Políticas de acceso de Key Vault

Para obtener más información, consulta Inicio rápido: Añadir una aplicación empresarial.

Configurar la autenticación sin secretos de EAR AKV

Para configurar el cifrado en reposo (EAR) con autenticación sin secretos, debes:

1. Crear un Principal de servicio de Azure administrado por Atlas.

2. Otorga acceso de Principal de servicio a la clave de Key Vault.

3. Configura EAR para usar el Principal de servicio.

atlasAzureAppId: 9efedfcc-2eca-4b27-a613-0cad1e114cb7

az account show --query tenantId -o tsv

az ad sp list --filter "appId eq '9efedfcc-2eca-4b27-a613-0cad1e114cb7'"

az ad sp create --id 9efedfcc-2eca-4b27-a613-0cad1e114cb7

POST /api/atlas/v2/groups/{groupId}/cloudProviderAccess

{
  "providerName": "AZURE",
  "tenantId": "<azure-tenant-id>",
  "servicePrincipalId": "<service-principal-object-id>",
  "atlasAzureAppId": "9efedfcc-2eca-4b27-a613-0cad1e114cb7"
}

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"

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

https://{keyvault-name}.vault.azure.net/{object-type}/{object-name}

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"
  }
}

Migrar desde credenciales estáticas

Si tu proyecto ya utiliza credenciales estáticas (tenantId, clientId, secret), puedes migrar sin tiempo de inactividad del clúster.

1. Cree un Service Principal gestionado por Atlas.

2. Conceda permisos para Key Vault.

3. Actualizar la configuración EAR con el nuevo roleId.

Si la validación falla, Atlas sigue utilizando credenciales estáticas.

Si la validación es exitosa, Atlas remueve las credenciales estáticas almacenadas y el roleId se convierte en la fuente de verdad para la autenticación.

Si tu clúster utiliza Redes Privadas, Atlas valida el acceso al Key Vault de manera asíncrona desde los nodos de datos.

• La validación no se completa inmediatamente cuando se acepta la solicitud PATCH.

• Los nodos de datos validan el acceso al Key Vault después de aplicar la configuración.

Antes de aplicar el parche roleId, asegúrese de que todos los permisos de Key Vault estén configurados correctamente. Una configuración incorrecta del acceso puede ocasionar fallos de validación en los nodos de datos, lo que podría acabar por interrumpir las operaciones de EAR y llevar a la desconexión de los clústeres.

Antes de aplicar el parche a EAR, verifique que su Service Principal disponga de los permisos necesarios para Key Vault.

az role assignment list \
  --assignee "$SERVICE_PRINCIPAL_OBJECT_ID" \
  --scope "/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.KeyVault/vaults/$KEY_VAULT_NAME"

az keyvault show \
  --name "$KEY_VAULT_NAME" \
  --resource-group "$RESOURCE_GROUP" \
  --query "properties.accessPolicies"