Azure Key Vault によるカスタマーキーの管理（シークレット認証）

前提条件

MongoDBプロジェクトで AKV を使用してカスタマー マネージド キーを有効にするには、以下が必要です。

• M10 以上のクラスター。

• Azureアカウントと、AKV 内の暗号化のキー。

  これらのAzureコンポーネントの構成方法については、Azure のドキュメントを参照してください。

  Atlas は、Atlas プロジェクト内のクラスターの保管時の暗号化を有効にするときにこれらのリソースを使用します。

• Azureでの権限:

  • テナントにエンタープライズサービスプリンシパルを登録します。この前提条件には、エンタープライズアプリケーションを追加または管理できる Microsoft Entra ID ロールが必要です。次の組み込みロールによってこの許可が付与されます。

    • アプリケーション開発者 (最小特権)

    • アプリケーション管理者

    • クラウド アプリケーション 管理者

    • ハイブリッド ID 管理者

    • グローバル管理者

    詳細については、クイック スタート: エンタープライズアプリケーションの追加 を参照してください。

  • 次のいずれかのオプションを使用して、Key Vault キーにアクセスします。

    • Azure RBAC （Key Vault またはキーの範囲）

    • Key Vault アクセス ポリシー

• 保管時の暗号化を有効にするプロジェクトの、Atlas のプロジェクト所有者アクセス。

Considerations

EAR に AKV に保存されている カスタマー マネージド キー を使用するには、Atlas が管理するサービス プリンシパルに、特定のキーヴォールト キーに対して暗号化操作を実行する権限が必要です。

必要なキー権限には、次のものが含まれます。

• get

• encrypt

• decrypt

権限の範囲をできるだけ狭くして、次のいずれかのオプションを使用して付与する必要があります。

• Azure RBAC （Key Vault またはキーの範囲）

• Key Vault アクセス ポリシー

詳細については、クイック スタート: エンタープライズアプリケーションの追加 を参照してください。

EAR AKV シークレット認証を設定する

シークレット認証を使用して保管時の暗号化（EAR）を構成するには、以下を実行する必要があります。

1. Atlas がマネージドAzureサービス プリンシパルを作成します。

2. サービス プリンシパルにキーヴォールト キーへのアクセス権を付与します。

3. サービス プリンシパルを使用するように EAR を構成します。

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

静的認証情報からの移行

プロジェクトですでに静的認証情報（tenantId、clientId、secret）を使用している場合は、クラスターのダウンタイムなしで移行できます。

1. Atlas がマネージドサービス Principal を作成します。

2. キーヴォールトの権限を付与します。

3. 新しい roleId で EAR 構成をパッチします。

検証に失敗した場合、Atlas は静的認証情報を使用し続けます。

検証に成功すると、Atlas は保存された静的認証情報を削除し、roleId が認証の真実のソースになります。

クラスターがプライベートネットワークを使用する場合、Atlas はデータ ノードから非同期に Key Vault アクセスを検証します。

• PATCHリクエストが受け入れられた後、検証はすぐに完了しません。

• データ ノードは、構成が適用された後に Key Vault アクセスを検証します。

roleId で EAR にパッチを適用する前に、すべてのキーヴォールト権限が正しく構成されていることを確認してください。アクセスの設定に誤りがあると、データ ノードの検証が失敗し、最終的に EAR 操作が中断され、クラスターがシャットダウンする可能性があります。

EAR パッチを適用する前に、サービス プリンシパルに必要なキーヴォールト権限があることを確認してください。

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"