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:

  • 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, consulte Inicio rápido: Agregar una aplicación empresarial.

  • Acceso a la clave Key Vault utilizando 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 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 Service Principal gestionado por Atlas debe tener permiso para realizar operaciones criptográficas en la clave específica del 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 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.

Configura la autenticación secreta EAR AKV

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

1. Cree un Principal de Servicio 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}/{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 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 continúa usando 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 a 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 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"