Ability to create database users limited to specific clusters
We have a single project set up for our application, and multiple clusters under that project. Right now, it's impossible to create database users who only have access to certain clusters - the only configurable option is "database name".
The issue is that some of the clusters have the same "database name" but I don't want them to be able to access a database in a specific cluster, though I do want them to access a database with the same name in a different cluster.
Any plans to implement this?
Folks I’m excited to share that database users scoped to particular sets of clusters (and Data Lakes) in an Atlas project is now live in Atlas!
– It is now possible to create database users with privileges scoped to a specific set of clusters or Atlas Data Lakes in an Atlas project.
– Existing users’ privileges can be edited to reduce their scope to a specific set of clusters or Atlas Data Lakes
– All authentication mechanisms (SCRAM, X.509, LDAP, AWS IAM) may be used in conjunction with this ability
Thanks for your patience: this was a long-time coming!
Thank you for the feature.
How can I give read permission for a specific cluster and read&write to a different cluster in the same project?
Restrict db user per Cluster:
We would like to check if a db user can be restricted to a specific cluster.
Currently we have a single project with few clusters and we would like to restrict the current db user to access only the one of the clusters.
Please note that our request is based on NOT splitting the above current single project to separate projects (which each project has its own cluster).
@andrew Checking in as well - mLab is set to be depreciated and we want to shift more to Atlas.
Any update on this Andrew? This is desperately needed.
Daniel Na commented
Same, desperately need this.
Looking for this, are you have any ETA?
Looking forward to this!
We 100% agree and are planning to deliver the ability for database users to be mapped to sets of clusters within a Project (rather than all or nothing) later this year. This remains a number of months out.
Same here. Our projects represents our different environments. Each containing multiple clusters. We also think that adding more projects to limit database access seems like the wrong solution.
This would be a highly appreciated feature in our opinion.
Andrius Skerla commented
Same issue. This is major disadvantage of Atlas for us.
We have the same issue. Adding more projects to limit database access seems like the wrong solution. With each project, you have to manage VPC peers, LDAP auth, alert settings, routing, etc. Because database users are defined at the project level, it makes sense to be able to limit access by cluster name. Otherwise you're taking a step back from running base MongoDB.
We hear you loud and clear on this one. In the interests of transparency, we've gone back and forth over time on whether Projects are the right model in general and that has delayed our finding a solution to this problem.
However we are quite committed to Projects as offering a very nice level of abstraction that can be super convenient in most cases and therefore are quite confident that the way to go is to add in the flexibility you're requesting here. (It makes perfect sense to use Projects to group items at the network and control plane level but not have to have them grouped at the data plane access level).
I was going to suggest the "use different database namespaces in different clusters" workaround but totally understand that for you that's annoying and more importantly untenable due to different clusters using the same DB name (very understandable).
Because this is a core change to our offering, it's not something we're going to be able to introduce in the near term, but something we know we need to. I'm sorry we don't have a solution to this sooner.
The current solution is to create different projects for each cluster I don't want to overlap, the problem with this is that it requires adding people/teams to each new project in Atlas.