There are use-cases where certain users or client IPs need to be given access restricted to only the Analytics node(s) . While it is possible to grant such users read-only permissions at the database/collection level, and have them use the ANALYTICS replica set tag in their connection string URI, it might still be possible for those users to connect to a Primary or a Secondary node (when not using the Analytics replica set tag) and run their query there.

Therefore, a feature that will either restrict specific users access to only the Analytics node(s) or a functionality that will restrict access from certain client IPs to only the Analytics node(s), will help in such use-cases.

Today when an Atlas cluster is deleted, all backups/snapshots of this cluster are deleted along with it.

This is especially an issue when working with automation tools like terraform, where a cluster can be deleted by accident easily.

In AWS Aurora Postgres, for example, there is an option to create a "final snapshot" before deleting the cluster.

If this option is enabled for a cluster, whenever a user triggers the deletion of the cluster (either manually, via API, or any other method), a final snapshot will be created, before the cluster is deleted.

This final snapshot is then available independently of the deleted cluster, so in case of accidental deletion, we can create a new cluster based on this snapshot.

This would be a huge security and safety improvement.

Hi,

I’m facing an issue about Snapshot Backup Policy creation/modification via Terraform ( FYI, I open a case to the support of MongoDB  https://support.mongodb.com/case/00668262). Let me explain :

When I want to create a MongoAtlas Cluster via terraform, I want to apply a custom Snahsphot Backup Policy with ONLY 2 items during the creation of the cluster :
N° Item Frequency type Frequency Retention
0 Daily 1 7 Days
1 Weekly 1 (Saturday) 4 weeks

However, during the creation of the mongo atlas cluster, I can see an error
Error: Error applying plan:

1 error occurred:

* module.cluster_contrib.module.dpjmongoatlas.module.tfmodule-gcp-mongo-atlas-cluster.mongodbatlas_cloud_provider_snapshot_backup_policy.snapshot_backup: 1 error occurred:

* mongodbatlas_cloud_provider_snapshot_backup_policy.snapshot_backup: error updating a Cloud Provider Snapshot Backup Policy: PATCH <a rel="nofollow noreferrer" href="https://cloud.mongodb.com/api/atlas/v1.0/groups/XXXXXXXXXXXXXXXXX/clusters/contrib/backup/schedule">https://cloud.mongodb.com/api/atlas/v1.0/groups/XXXXXXXXXXXXXXXXX/clusters/contrib/backup/schedule</a>: 400 (request &quot;Bad Request&quot;) The frequency type of a policy item must not be changed.

Indeed, during the creation of the MongoAtlas cluster, MongoAtlas apply the default Snapshot Backup Policy first (with 4 items hourly, daily, weekly, monthly) and after try to apply the custom snapshot backup policy I want (described in the terraform code). But, as we can see above, it seems impossible to change the frequency_type of an existing policy’s item…

To resume clearly with this spreadsheet :
N° Item Frequencytype of default policy Frequencytype of custom policy I want COMMENT
0 Hourly Daily KO (because The frequency type of a policy item must not be changed)

1 Daily Weekly KO (because The frequency type of a policy item must not be changed)

2 Weekly NOTHING
3 Monthly NOTHING

Can we purpose a evolution to have the possibilty to modify the frequency_type of an existing policy item via Terraform/API?

Regards,

When a customer wants to use their private LDAP server in Atlas, they currently need to either expose their name via public DNS or use an internal CA and an IP address. For some customers these scenarios are suboptimal since they want to keep their infrastructure details private, even at DNS layer.

The proposed solution is to use the Conditional DNS forwarders in all cloud providers supported by Atlas, so the requests to resolve a private DNS zone (specified by the customer) will be forwarded to the listed DNS servers across the VPC peering connection while all other (public) DNS requests will still be served by the Atlas DNS server.

https://cloud.google.com/dns/docs/overview#dns-peering
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-forwarding-outbound-queries.html
https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-name-resolution-for-vms-and-role-instances#name-resolution-that-uses-your-own-dns-server

We're currently using the Atlas Service Broker (https://github.com/mongodb/atlas-osb) which is built using the native Atlas REST APIs.

In the project creation, it creates the project using the POST /api/atlas/v1.0/groups endpoint via an API key. As a result, we have an unexpected user added as the project_owner of the project.

THis is due to:
IMPORTANT

To create a project using API Key credentials, you must specify an orgId. When you do, Atlas automatically selects the Owner of the specified organization with the earliest account creation date and time as the Project Owner for the newly created project.

The API should be expanded to allow for a user to be configured as the default project owner, or the project should not require a default project_owner at all when it is created via an API.