إنتقل إلى المحتوى الرئيسي
ينطبق على:
DuoKey Cockpit v2MongoDB (Atlas or self-hosted)Client-side field-level encryption

Overview​

MongoDB Client-Side Field-Level Encryption (CSFLE) encrypts selected document fields in the driver, before the write ever reaches the MongoDB server, and decrypts them on read — the server never sees plaintext for those fields, and fields encrypted this way are opaque to queries: MongoDB can store and return the ciphertext, but cannot filter, sort, or index on it.

Each encrypted field is protected by a per-field Data Encryption Key (DEK), stored in a MongoDB collection called the key vault collection. Those DEKs are themselves wrapped by a Customer Master Key (CMK) sourced from a KMS provider. This app's role is that KMS provider: DuoKey custodies the CMK and hands the driver the reference it needs to create and unwrap DEKs.

MongoDB CSFLE — where encryption happens
Applicationwrites / reads document fields
plaintext field
MongoDB driverautomatic encryption layer
ciphertext only
MongoDB serverdata collection + key vault collection
MongoDB driver
unwrap request (KMS provider)
DuoKey vaultholds the CMK wrapping every DEK

Only the driver process ever sees plaintext for an encrypted field; MongoDB itself stores and returns ciphertext only.

PropertyValue
Encryption modelClient-side field-level encryption — opaque, non-queryable ciphertext
Key custodyDuoKey vault key wraps the DEKs stored in the MongoDB key vault collection
OnboardingGuided multi-step wizard
Proof statusDeployment/config generation real; self-test currently simulated — see below
Read this before relying on the self-test

The self-test and health-check endpoints for this integration currently return simulated, hardcoded results rather than performing a live round-trip against a running MongoDB deployment. The app record, the linked vault key, and the generated configuration are real; the pass/fail signal from the self-test is not yet backed by a live encrypt/decrypt call.

Configuration​

FieldPurpose
mongodb_uriMongoDB connection URI (`mongodb://` or `mongodb+srv://`) — supports Atlas and self-hosted deployments.
databaseTarget database.
key_vault_namespaceNamespace (`database.collection`) MongoDB uses to store encrypted data keys. Defaults to `encryption.__keyVault`.
kms_providerKMS provider type the driver uses to reach the master key: `kmip` (DuoKey, recommended), `aws`, `azure`, `gcp`, or `local` (development only).
encryption_schemaJSON schema declaring which fields to encrypt and how (deterministic or randomized).
linked_key_idThe DuoKey vault key acting as the master key wrapping the DEKs.

Onboarding via the wizard​

1

MongoDB connection

Enter the connection URI and target database.

2

KMS provider

Select the KMS provider — KMIP is recommended for DuoKey-backed deployments.

3

Encryption schema

Define which fields to encrypt and their algorithm (deterministic enables equality matching on ciphertext; random does not).

4

Key vault

Configure the key vault namespace where MongoDB stores the encrypted data keys.

5

Vault & key

Select the DuoKey vault and master key wrapping the data keys.

6

Review & deploy

Review the summary and get driver configuration snippets for Node.js, Python, Java, and Go.

Deterministic vs. randomized encryption

A deterministic-encrypted field always produces the same ciphertext for the same plaintext, so the driver can query it for exact equality — at the cost of leaking which documents share a value. A randomized-encrypted field never repeats ciphertext and cannot be queried at all. If you need to query a field on more than exact equality (ranges, for example), CSFLE cannot do it — see MongoDB Queryable Encryption.

How a CSFLE write flows​

Encrypting one field, end to end
1. Application writes a documentone field is marked for encryption in the schema
automatic encryption intercepts the write
2. Driver looks up the field's DEKreads the wrapped Data Encryption Key from the key vault collection
unwrap request
3. DuoKey unwraps the DEKusing the CMK this app custodies
DEK now usable client-side
4. Driver encrypts the fielddeterministic or randomized, per the encryption schema
ciphertext only
5. MongoDB stores the ciphertextserver never sees plaintext for this field

Steps 2–4 all happen inside the driver process — MongoDB itself is only ever handed ciphertext.

Health and self-test​

CheckWhat it reportsLive probe today
HealthMongoDB reachability, key vault accessibilityNo — returns a fixed healthy status envelope
Self-testMongoDB connection, key vault access, field encrypt/decrypt round-trip, KMS provider reachabilityNo — all four checks return a hardcoded pass
Verify independently before relying on it

Until the self-test drives a live MongoDB session, confirm field encryption is genuinely active by inspecting a raw document (via the shell, bypassing the encrypted client) and checking that the target fields are BSON binary ciphertext, not plaintext.