Support for EKS Service Account Credentials in MONGODB-AWS

It would be great to be able to authenticate to MongoDB using EKS service accounts.

Currently, the order in which Drivers MUST search for credentials is:
Credentials passed through the URI
Environment variables
ECS endpoint if and only if AWS_CONTAINER_CREDENTIALS_RELATIVE_URI is set.
EC2 endpoint
(https://pymongo.readthedocs.io/en/stable/examples/authentication.html#mongodb-aws)

It is possible use the AWS_ROLE_ARN and AWS_WEB_IDENTITY_TOKEN_FILE environment variables injected into the pod by EKS to assume the service account role and get temporary security credentials, which could then be passed to the uri as described in AssumeRole (https://pymongo.readthedocs.io/en/stable/examples/authentication.html#assumerole).

The boto client for sts provides a assume_role_with_web_identity method that accepts role_arn and web_identity_token as parameter that can be used to obtain temporary credentials.

Rather than having to add extra boiler plate code to applications, is this something that could be supported natively by the drivers?

So the order the drivers would search for credentials might then look like the following:
Credentials passed through the URI
Environment variables
ECS endpoint if and only if AWS_CONTAINER_CREDENTIALS_RELATIVE_URI is set.
Assume EKS Service acccount role to get temporary credentials if and only if AWS_ROLE_ARN and AWS_WEB_IDENTITY_TOKEN_FILE are set
EC2 endpoint

Automatic CSFLE - To generate and manage the Customer Master key, can we add more KMS providers like Hashicorp Vault. KMS providers currently supported are only: Amazon Web Services KMS and Locally Managed Keyfile.

To work with Hashicorp Vault, it seems, we need to choose Locally Managed Keyfile as the KMS provider. This means that the Master key will be fetched from Vault in memory and then used in the code to encrypt/decrypt the DEK (Data Encryption Key). Ideally, the decryption of DEK should happen in the vault itself as a best practice, and master key should not be brought out of Vault.

Using only AWS KMS is a limitation. Using Locally Managed Keyfile to read key from
another KMS and then use in application is not secure.

Can more KMS providers be supported in a more secure way?

Thanks

Hi,

We are currently using a pattern where we use a find(query).limit(x) and a count(query) with $near to find x results and display the overall count. Using this pattern, we are able to pass the same query to find and count. However that count method was removed in SCALA-517 and replaced by estimatedDocumentCount and countDocuments. The problem is that countDocuments will not work with $near. There is a workaround to use $geowithin with $center/$centerSphere, however this doesn't return the results sorted as $near did. We would like to have the option to pass the same query to count as we do to our find, even if there are risks associated as there was with count, an estimatedDocumentCount or unSafeCount, if you will, that accepts the same filter as our query.

Please modify your drivers so our java applications can encrypt and decrypt from the mainframe (zOS) UNIX environment. This missing feature is a road-block to our migration to Atlas.

We have multiple Java applications that run on an IBM mainframe. Those applications read and write into MongoDB collections, like inserting Mainframe data into MongoDB collections. The mongo-crypt driver for CSFLE does not work on the Mainframe UNIX environment.

Company policy states we have to encrypt all PHI/PII data prior to inserting the data into Atlas.

I had opened a support ticket with MongoDB and the final reply was you do not support zOS and to put in this request. (Case number 00802484)

Here is the error message I shared with MongoDB:
Exception in thread "main" java.lang.UnsatisfiedLinkError: Native library (com/sun/jna/z/os-s390/libjnidispatch.so) not found in resource path (Ýfile:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/,
file:/ST/usr/lpp/java/IBM/J8.0/lib/, file:/ST/usr/lpp/java/IBM/J8.0/lib/ext/,
file:/ST/usr/lpp/java/json/org.json-20120521.jar,
file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/CDRMigrateAccumsToAtlas.jar,
file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/bson-4.2.3.jar,
file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/jna-5.6.0.jar,
file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/json-20160810.jar,
file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/logback-classic-1.2.3.jar,
file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/logback-core-1.2.3.jar,
file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/mongodb-crypt-1.2.0.jar,
file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/mongodb-driver-core-4.2.3.jar,
file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/mongodb-driver-sync-4.2.3.jar,
file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/recordio.jar,
file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/slf4j-api-1.7.6.jar,
file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/vault-java-driver-5.1.0.jar,
file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/*.mar¨)
at com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(Native.java:1032)
at com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:988)
at com.sun.jna.Native.<clinit>(Native.java:195)

We would like to suggest a feature improvement where connection parameters can be dynamically changed so that no restart of client application infrastructure is needed.

Currently, when changing connection configuration, this usually requires the restart of a considerable number of pods or containers with the unavoidable consequence of a sudden surge in connection attempts.

Our request specifically would be to provide a way for drivers to read both connection string and connection parameters information from a source that can be easily managed and that's not necessarily embedded in the code, and

Drivers should also detect when this configuration has changed and gradually refresh connections to reflect the new configuration. Ideally there would be ways of forcing the driver to be more aggressive or more gradual, which should accommodate for emergency situations or tuning scenarios that are not urgent. This is the part that would avoid any client infrastructure restart, and avoid sudden surges in connection attempts.