Limitations
beta
Client-Side Field Level Encryption is available as a beta. The contentsof this page may change during the beta period.
Read and Write Operation Support
The mongod
only stores encrypted BinData
and applies any aggregation expression or query operatorspecifying an encrypted field against the BinData
value. While theexpression or operator may support BinData
fields, the resultingvalue may be incorrect or unexpected when compared to issuing that sameexpression or operator against the decrypted value. The mongod
throws an error if the expression or operator does not supportBinData
values.
For example, consider a deterministically encrypted integer Salary
.A query filters for documents where Salary
is greater than100000
. The application explicitly (manually) encrypts the queryvalue using deterministic encryption prior to issuing the query. Themongod
compares the encrypted BinData
value of 100000
tothe encrypted BinData
values stored in each document. While theoperation returns successfully, the comparison of the BinData
valuesmay return a different result than the comparison of the decryptedinteger values.
Automatic client-side field level encryption rejects read or writeoperations which would return incorrect or unexpected results whenissued against an encrypted field. For complete documentation, seeRead/Write Support with Automatic Field Level Encryption.Applications performing explicit (manual) encryption may reference thelinked page as guidance for issuing read/write operations againstencrypted fields.
Views
Queries against views on collectionscontaining client-side field level encrypted values may returnunexpected or incorrect results if either the underlying viewaggregation pipeline or the query references encrypted fields. Ifcreating a view on a collection containing client-side field levelencrypted values, avoid operating on encrypted fields to mitigate therisk of unexpected or incorrect results.
While 4.2-compatible drivers configured for automatic client-side fieldlevel encryption have validation forunsupported read and write operations, the underlying support librarycannot introspect the view catalog to identify a given collection as aview. Applications therefore cannot rely on the automatic field levelencryption validation to prevent unsupported queries against views oncollections with encrypted fields.
For applications using explicit (manual) encryption to query a view on acollection containing encrypted values, consider constructing the queryusing only query operators with known normal behavior when issued against encrypted fields.
Collation
Client-side field level encryption does not respect user-specifiedcollations or collection default collations. Field level encryption obscures the field valueand prevents normal collation behavior. Collation-sensitive queriesagainst encrypted fields may return unexpected or incorrect results.
While 4.2-compatible drivers configured for automatic client-side fieldlevel encryption have validation forunsupported read and write operations, the underlying support librarycannot introspect the collection catalog to identify the defaultcollation. Applications therefore cannot rely on the automatic fieldlevel encryption validation to prevent querying on encrypted fields withcollation defaults.
Unique Indexes
Unique indexescannot guaranteeuniqueness if the index key specifies any randomly encrypted fields.
Fields encrypted using the randomalgorithm always produce a different encrypted value given a specificinput. The server considers each encrypted value unique even though thedecrypted value itself is not unique. The collection can thereforecontain multiple documents with duplicate decrypted values for a fieldwith an index-enforced unique constraint.
While 4.2-compatible drivers configured for automatic client-side fieldlevel encryption have validation forunsupported read and write operations, the underlying support librarycannot introspect the index catalog to identify a given field as unique.Applications therefore cannot rely on the automatic field levelencryption validation to prevent unique constraint violations onrandomly-encrypted fields.
Shard Key
Specifying a shard key on encrypted fields _or_encrypting fields of an existing shard key may result in unexpected orincorrect sharding behavior.
While 4.2-compatible drivers configured for automatic client-side fieldlevel encryption have validation forunsupported read and write operations, the underlying support librarycannot introspect the sharding catalog metadata to identify shard keyfields. Applications therefore cannot rely on the automatic field levelencryption validation to prevent encryption of shard key fields.
Read/Write Query Support
Automatic client-side field level encryption supports a subset ofcommands, query operators, update operators, aggregation stages, andaggregation expressions. For complete documentation, seeRead/Write Support with Automatic Field Level Encryption.