Administrar claves de clientes con Azure Key Vault (Autenticación sin secretos)

Requisitos previos

Para habilitar claves administradas por el cliente con AKV para un proyecto MongoDB, debe tener:

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

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

  Para obtener información sobre cómo configurar estos componentes de Azure, consulte 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:

  • Registre una entidad de servicio empresarial en su inquilino. Este requisito requiere permisos de ID de Microsoft Entra 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, consulte Inicio rápido: Agregar una aplicación empresarial.

  • Acceda a la clave de Key Vault mediante una de las siguientes opciones:

    • Azure RBAC (en el almacén de claves o en el ámbito de la clave)

    • Políticas de acceso a Key Vault

• Acceso de propietario del proyecto en Atlas para el proyecto para el que desea habilitar el cifrado en reposo.

Considerations

Para utilizar una clave administrada por el cliente almacenada en AKV para EAR, el principal de servicio administrado por Atlas debe tener permiso para realizar operaciones criptográficas en la clave de Key Vault específica.

Los permisos clave necesarios incluyen:

• get

• encrypt

• decrypt

Debe limitar los permisos lo más posible y otorgarlos mediante una de las siguientes opciones:

• Azure RBAC (en el almacén de claves o en el ámbito de la clave)

• Políticas de acceso a Key Vault

Para obtener más información, consulte Inicio rápido: Agregar 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, debe:

1. Cree una entidad de servicio de Azure administrada por Atlas.

2. Otorgue al principal de servicio acceso a su clave de Key Vault.

3. Configurar EAR para utilizar la entidad 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}/{object-version}

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 su proyecto ya usa credenciales estáticas (tenantId, clientId, secret), puede migrar sin tiempo de inactividad del clúster.

1. Cree una entidad de servicio administrada por Atlas.

2. Otorgar permisos a Key Vault.

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

Si la validación falla, Atlas continúa usando credenciales estáticas.

Si la validación tiene éxito, Atlas elimina las credenciales estáticas almacenadas y roleId se convierte en la fuente de verdad para la autenticación.

Si su clúster utiliza redes privadas, Atlas valida el acceso a Key Vault de forma asincrónica 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 a Key Vault después de aplicar la configuración.

Antes de aplicar el parche roleId a EAR, asegúrese de que todos los permisos de Key Vault estén configurados correctamente. Un acceso mal configurado puede provocar fallos de validación en los nodos de datos, lo que podría interrumpir las operaciones de EAR y provocar el cierre del clúster.

Antes de aplicar un parche a EAR, verifique que su entidad de servicio tenga los permisos de Key Vault necesarios.

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"