Gerencie Chaves de consumidor com Azure Key Vault (Autenticação sem segredo)

Pré-requisitos

Para habilitar chaves gerenciadas pelo cliente com AKV para um projeto MongoDB , você deve ter:

• Um cluster M10 ou superior.

• A conta do Azure e a chave de criptografia em seu AKV.

  Para saber como configurar estes componentes do Azure, consulte a Documentação do Azure.

  O Atlas utiliza estes recursos ao habilitar encryption at rest para um cluster no projeto Atlas.

• Permissões no Azure para:

  • Registre um Enterprise Service Principal em seu locatário. Esse pré-requisito requer permissões do Microsoft Entra ID para adicionar ou gerenciar aplicativos corporativos, como administrador de aplicativos, administrador de aplicativos de nuvem ou administrador global.

    Para saber mais, consulte Início rápido: adicionar um aplicação empresarial .

  • Acesse a chave do Key Vault usando uma das seguintes opções:

    • Azure RBAC (no Key Vault ou no escopo da chave)

    • Políticas de acesso ao Key Vault

• Acesso de proprietário do projeto no Atlas para o projeto para o qual você deseja habilitar a encryption at rest.

Considerações

Para usar uma chave gerenciada pelo cliente armazenada no AKV for EAR, o Service Principal gerenciado pelo Atlas deve ter permissão para realizar operações criptográficas na chave específica do Key Vault.

As permissões de chave necessárias incluem:

• get

• encrypt

• decrypt

Você deve ter o escopo das permissões o mais restritivo possível e concedê-las usando uma das seguintes opções:

• Azure RBAC (no Key Vault ou no escopo da chave)

• Políticas de acesso ao Key Vault

Para saber mais, consulte Início rápido: adicionar um aplicação empresarial .

Configurar a autenticação sem segredo EAR AKV

Para configurar a Encryption at Rest (EAR) com autenticação sem segredo, você deve:

1. Crie um Azure Service Principal gerenciado pelo Atlas.

2. Conceda ao Service Principal acesso à sua chave do Key Vault.

3. Configure o EAR para usar o Service Principal.

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 de Credenciais Estáticas

Se o seu projeto já utilizar credenciais estáticas (tenantId, clientId, secret), você poderá migrar sem tempo de inatividade do cluster.

1. Crie um Service Principal gerenciado pelo Atlas.

2. Conceda permissões ao Key Vault.

3. Corrija a configuração do EAR com o novo roleId.

Se a validação falhar, o Atlas continuará usando credenciais estáticas.

Se a validação for bem-sucedida, o Atlas removerá as credenciais estáticas armazenadas e o roleId se tornará a fonte da verdade para a autenticação.

Se o cluster usar rede privada, o Atlas validará o acesso ao Key Vault de forma assíncrona a partir dos nós de dados.

• A validação não é concluída imediatamente quando a solicitação PATCH é aceita.

• Os nós de dados validam o acesso ao Key Vault depois que a configuração é aplicada.

Antes de corrigir o EAR com roleId, certifique-se de que todas as permissões do Key Vault estejam configuradas corretamente. O acesso mal configurado pode resultar em falhas de validação nos nós de dados, o que pode eventualmente interromper as operações do EAR e levar ao desligamento do cluster.

Antes de corrigir o EAR, verifique se o Service Principal tem as permissões necessárias do 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"