Granular Permissions
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.

-
Roger commented
When defining Custom Roles it should be possible to use placeholders / patterns (regex ?!?) in the "Database" or "Collection" field. This would allow to setup more fine grained rules and allow to reduce the count of rules to be defined.
-
Ole Gunnar commented
I need to employees in operations team access to download backups while still limiting other access rights
-
Amit commented
On Mongo Atlas we are looking to restrict the user permission in specific cluster within project.
-
Ola commented
I would like to vote this request, since I hear that from the field that customer would like to have more possibilities to allow/restrict access per particular user/group also for CHARTS specific
-
Vladimir commented
We are looking for this feature that will allow our teams to access to the Atlas Query Profiler without also granting at least read-only access to the Data Explorer.
-
Simon commented
We have many teams with different databases they are managing on a cluster.
Right now, to create Search indexes, they have the permission at the project-level and thus can create/delete Search indexes in ALL databases; not just their own. -
Tom commented
@Fuat thanks for the update, appreciated. There was no communication on this ticket therefore your comment sheds some light on the case.
Just to clarify, if MongoDB teams are actively working on it, why do you ask for votes to get further updates on this? Should you not provide updates by default now that the teams are working on this case?
-
AdminFuat (Admin, MongoDB) commented
Just to bring some clarity with a public comment: The status of this ticket was updated to Started on Jul 20, 2022 that means the work to address the request started and MongoDB teams are actively working on it. Please vote for this request to get further updates.
-
Tom commented
Was about to vote for this, but then realised the issue was raised 3 years ago(!) with virtually no progress despite hundreds of upvotes. My conclusion is that this feedback platform does not seem to serve any purpose.
-
Emmanuel commented
Each member of an organization with "Organization Member" role is able to read the billing details of the organization. This should be restricted. We facing problems with our governance, because each member is able to get details about billing in MongoDB Atlas.
The use-case is to share a dashboard with no ability to read billing informations.
-
Björn commented
I voted for this but I came to a point where I have to say: it would be much more useful for an organization like ours (regulated) to have policies on an organization level that prevent unwanted settings espacially in App Services (like creating endpoints or allow anonymous authentication or just creating ip access lists .... there are tons of such settings) ... so if I have to decide between having fine grained permissions or policies to prevent unwanted/mistakenly made settings I would go with the second. By the way it seems that Atlas has to do some heavy lifting with the fine grained permissions compared to the time this is an open and whished feature ... ;-)
-
Dawson commented
Ditto what has been said about being able to get granular enough to control app services like Realm.
-
Ruben commented
Our use case: give manager permissions to create and invite new users to projects. For that project owner role is needed. With that role, the manager will have access to all data and this is not least privilege principle
-
Zach commented
Please include permissions for App Services (realm). Right now if you want to edit/test a function in the realm UI, you have to have owner level permissions. That is not a permission level that should be given to most resources on the project
-
Partab commented
I would like to be able to assign the roles at the cluster level within the project, so that right team members can access to the right cluster in the project instead of getting access to every cluster in the project. Creating multiple projects to resolve this issue causes the burden on network that organization have to dedicate big subnets for getting just 2/3 clusters per project, which ends up in wasting the remaining IPs in those subnets.
-
Oleksandr commented
That would be helpful to be able to restrict user access to particular nodes/node types.
Real world example:I want my data analyst to only have access to isolated ANALYTICS node, to not be ably to run heavy queries in operational nodes set and not affect application performance / customers experience.
-
Rohan commented
Also, i need more granular privilege for a user in order to add trigger role.
-
Joel commented
I'd like to be able to independently set user/team access to support tickets without giving them access to read information within databases.
-
Simon commented
For our Level 2 operations personnel it would be great to be able to assign a user role that allows for managing alerts, but does not need to be Project Owner role :-)
-
Martin commented
As per Stanislav : We would like to see Access Control Management as a separate role.