Ops Manager currently allows the ability to rotate audit logs based on the threshold settings in the Update MongoDB Log Settings modal but audit.logs do not compress/delete as the mongodb.logs do from the same modal. We would like the ability to either toggle compression/deletion of audit.log in that modal or a separate modal. We think a separate modal would be better since audit.logs may be used for security forensics and require a longer retention period.

Support all MongoDB configurations in Kubernetes CRD so that it is possible to deploy a fine-tuned cluster with Kubernetes resources

Backups normaly protect from accidental deletion of a database. In a devOps environment it can happen that a MDB resource gets deleted by a Kubernetes deployment. At the moment, Ops Manager then deactivates the backup and deletes all snapshots. We would like to have the snapshots stored as long as their retention limit tells or at least until the project itself is deleted in Ops Manager.

So that, if a developer detects the mistake and re-deploys the MDB resource(s), someone or even himself can restore the database(s) from the backups.

Many customers require that the MMS automation agent has a valid x509 for TLS communications with Ops Manager. With the Kubernetes Operator this is not currently possible so these customers cannot use the Operator to deploy MongoDB instances within their environments.

This feature would improve the security of communications between agents and the Ops Manager and meet the security requirements of many of our customers who cannot move to services like Atlas.

Problem Statement,
What is the problem? MongoDB Agent (Automation Module) attempts to auth with __system (SCRAM) user when security.clusterAuthMode is set to x509.

Why is this a problem? MongoDB Server process logs are flooded by unnecessary noise from such MongoDB Agent (Automation Module) failed auth attempts.

Example,
{"t":{"$date":"2021-05-10T11:08:02.115+0000"},"s":"I", "c":"ACCESS", "id":20249, "ctx":"conn115","msg":"Authentication failed","attr":{"mechanism":"SCRAM-SHA-1","principalName":"__system","authenticationDatabase":"local","client":"10.10.10.10:46765","result":"AuthenticationFailed: ###"}}

Proposal,
* Don't attempt to auth with __system (SCRAM) user when security.clusterAuthMode is set to x509 in MongoDB Server

PodSecurityPolicies are a way to enhance security in a k8s cluster.

Currently the Kubernetes Operator and the Helm Chart does not offer a way to integrate PSPs. If an administrator wants to enforce PSPs for the cluster where the MongoDB Kubernetes Operator is deployed, he would need to do this manually which leads to additional manual steps (e.g. editing the Operator role to allow "use" "psp").

Please introduce a way to secure the MongoDB Management (Ops Manager, Operator) and Workload (MongoDB custom resources) with PSPs in the Kubernetes Operator / Helm ecosystem.

As the SSL Options are deprecated since MongoDB v4.2 but Ops Manager Automation still utilizes SSL options in the automation configuration for MongoDB v4.2. It will be best that Ops Manager v4.2+ will utilize TLS options in the Automation Config of their managed MongoDB v4.2 deployments.

Currently, Ops Manager does not provide support to SCRAM-SHA-256 authentication mechanism when connecting to the Backing Database.
This is because the version of MongoDB Java Driver which is in use by Ops Manager 4.2.0 is 3.6.4.
SCRAM-SHA-256 is supported by the Java Driver from the version 3.8.

Add K8S namespace as a tag in Ops Manager project so it is easier to identify what project belongs in what namespace

Currently there is a time lag between the Ops Manager version releases and the availability of K8S images to be used with the MongoDB Kubernetes Operator.

It would be nice if they are released at the same time.

When a user imports a cluster into a project with the same name, it causes issues like breaking backups of pre-existing clusters.

Checking the replica set name against the names of other replica set names will prevent having to terminate backups and remove and re-import clusters, starting over.

Currently there is no way in Kubernetes operator to configure how long automation/backup/monitoring agent logs should be stored. they can easily occupy all space in pod.

Deploy MongoDB Ops Manager in Kubernetes with Operator that will allow MongoDB Clusters to be run and managed from Kubernetes platform entirely

Support SCRAM authentication for MongoDB Users

OpsManager database password is exposed as environment variable.

OMPROPmongo_mongoUri holds credentials of the OpsManager Database.

OpsManager Pod should not have credentials in environment variables but store and retrieve from a k8s secret.

Currently in MongoDB Kubernetes Operator 1.4.2 the pods are run under a specific service user named "mongodb-enterprise-database-pods".

It would be nice to be able to specify a custom service user name to be able to comply to specific enterprise user definition rules.

Allow custom Annotations on MongoDB CR so it would be easier to label multiple clusters

Support UBI as a base image for OpenShift deployemnts

Add capability to add Taints and Tolerations to K8S Operator pod spec for different types of pods