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.

-
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.
-
Richard commented
I want to allow users to add their own IP address for 6 hours, with a comment specifying what username added that IP permission. Our users have dynamic IP addresses working remote and it is a constant effort trying to grant network access.
-
ONYANCHA commented
The permissions should also put into consideration the view access rights for different member including access to billing informations among others.
-
Neil commented
The aspect of this feature I would find very useful is to allow certain non-project users to be authors on a data source. At the moment I can give a user author access to a chart but they have very limited editing ability and cannot see the fields of a data source to which they only have viewer access.
-
Nikhil commented
If I am reading the request correctly, it would help us fine-tune access including creating triggers without opening up the project-level access.
-
Pär commented
This would be very helpful for assigning permissions for API-keys and also users. .
Custom Roles would be great, but a couple of more restrictive roles for special tasks would be a good start.
As it is now you need to assign "Project Owner" to be able to do specific task like adding database users or managing Atlas Search indexes. However this also enables the user/key to delete clusters, as an example...
-
Sebastien commented
One other example: we would like to authorize our application team to download backup.
However, You must have the Project Owner role for an Atlas project to manage backups for or to restore a backup to clusters in that project.
We dont want to give Project Owner permissions just to download a backup.
It goes against the best practice of least privileges.
So in our cases we would like Atlas to improve the granularity of the permissions to be able to assign specific data backup / download backup / restore permissions
-
Maurizio commented
Example: at present if I want to give to an external, occasional user the permission to download a backup I need to assign it to the Project Owner role, which is not an option for very obvious security reasons.
At least with mlab there was the option to automatically send a backup to a S3 bucket.
-
Derek commented
To give an example for more granular permissions, we're using an API key to create an Atlas Search Index, but because of the current permission set, we have to give that API key Project Owner permissions. We only need the API key to do this one specific task, but yet, that API key has full permissions to our entire project. From a security standpoint, this will keep me up at night.
-
Simon commented
Enabling granular permission at the API level would also be helpful. For example I want to set up a process to pull Metrics into Prometheus, I would like to be able to set up an API key that just has the ability to perform this task on just this particular API resource.
-
Jonathan commented
Our use case is related to allowing developer team backup/restore downloads of particular clusters without having to grant project owner level (the min required to create/download backups).
-
Morgan commented
This would be very useful.
I'm currently setting up Terraform to work with your provider to manage our alerts, but I need to give the keys "Project Owner" access which is very excessive for the level of access it needs!
-
Provider commented
Also in a healthcare related field. I need to restrict access to production database collections and only allow access to the test instances. This should be a priority feature
-
Alexander commented
Another use case is having individuals in a support/on-call role being able to initiate a failover. Currently the only user role that can initiate a failover is Project Owner, who also has the ability to modify/delete clusters which is not desirable.
-
Michael commented
Hi Andrew,
Thank you very much for your answer. Cross-Org Billing really helps us.
Do you think, it would be possible to set more than one "Billing Email Address" in billing profile? I asked the support, but it seems that you only can set up one address. This shouldn't be a big change. The billing mail should be sent to me and my colleague.I have seen that you cannot change the billing profile for the linked organization. If you would made this possible, it would be much easier to manage the accounts for our subsidiaries. Because then you would receive a separate invoice to a separate mail address.
Regards,
Michael