Right now Mongo Atlas allows you to assign two types of roles to all the users: Organization and Project, and for each set it gives you some predefined roles.

The problem with this is you can't have any kind of granular control of what permission is assigned to each user. (e.g. to allow a user to create a trigger through Mongo Stitch it needs the Project Owner role).

This is a major setback as I'm giving my coworkers more access than needed.

A good solution would be to have something like the database access control in this part so we can create our own custom roles to assign to he users.

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,

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.

Hello,

I think it would be a good idea to have team management at project level.
We have many projects and members in our Atlas account.
I'm a organization owner. The people in my organization use the Altas service. I create
a project for them and give my colleagues the project owner authorizations.

Project owners can invite other members. This is good. But it's a little inconsistent that
they are not able to create groups or teams within their projects They have to manage the permissions for each member separately.

We can't use organization teams, because they are located at the organizational level. Therefore, only the owner of an organization can create teams.
And only the owner of an organization can add or remove members from a team.

Much like built-in roles have the ability to target all databases/any database, it would be ideal if collection actions could also target any database. Similarly to how, when adding collection actions to a custom role, if you leave the "collection" field blank, it applies to all collections in the specified DB, it would be great if you could leave the "database" field blank too (or add an "any database" option) and have the actions associated with the role be allowed on any database.

This feature gap creates unnecessary maintenance overhead for clusters with large numbers of databases. This is particularly impactful if databases are added/removed/migrated frequently, creating the need for frequent manual maintenance or some kind of API-based automation to keep the role updated so that the actions can be performed on all databases that currently exist on the cluster.

Currently, Atlas has a 15 minute interval where it checks access to remotely stored Customer Managed Encryption keys for the custom encryption at rest feature.

This value is not changeable, and it implies a problem: access to encryption keys can be lost for longer periods than 15 minutes without that implying that the key has been invalidated by the customer.

A perfect example of this was the recent Azure AD global outage that prevented all authentication to the Azure platform for about 3 hours (complete outage description: https://app.azure.com/h/SM79-F88/691d78). While the key used for one of our clusters was not invalidated nor the credentials rotated, the whole cluster went down just because the auth mechanism was failing. This impacted our customers and would have easily been mitigated if the time interval for key access checking would have been longer.

Hi MongoDB team,

as the organization owner I don't want that my organizational members (developers, project owners etc.) have access to the billing section. Currently every member (independent on the granted rights) has the rights to see the complete billing section and can see the whole invoice incl. the names of the projects. This isn't acceptable regarding compliance because we are working together with external companies and their colleagues shouldn't have the ability to see all invoices.

Please make the billing section of MongoDB Atlas available to handle multitenancy - so that only the organization owner can see the billing section with all invoices. It would be perfect if you could also add the posibility for the project owner to see their invoices only (and not the ones from the whole organization).

I have also created a ticket for this problem: case 00716265.

Thank you so much!

Have a nice day
Christian

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

It is often practical to Live Migrate from one Atlas cluster to another Atlas cluster (e.g. to create another staging environment if backups are not enabled on the source, or migrate a production/staging environment to another dedicated project with minimal downtime).

Currently, the Live Migrate modal requires connection details from the source cluster, including the hostname of the primary, port, etc. Validation will fail if there are typos/errors in these inputs.

It would be easier to have a point-and-click option to "Migrate from another Atlas cluster" -- it could be a drop-down menu with names of other Atlas clusters in the project/organization that could be selected. The required connection parameters could then be automatically populated based on the particular cluster. A temporary user with the required permissions could even be created and then removed after the migration is complete.

This could make it easier to start Live Migrations between Atlas clusters, and avoid the need for the user to locate and confirm specific source connection requirements.