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.
Kico
shared this idea
25 comments
-
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 -
Ben
commented
Coming, from a medical device company that has a conservative perspective on security, there's a basic policy of "need to know". There are several potential users of MongoDB Atlas, that don't need to know the list of users that are currently managed by Atlas or the financial information associated with the Organization. Currently, there's no way to block access to these capabilities/information.
-
Hi Greg,
We do plan to enable a database user to be granted multiple custom roles in the future. This remains a number of quarters out, however. Apologies for the friction in the meantime. Note that this particular suggestion was originally scoped to the slightly orthogonal context of the MongoDB Cloud control plane users (e.g. instead of database users).
Addressing Kico's original intent, note that annual subscription customers can now take advantage of Cross-Organization billing (see docs https://docs.atlas.mongodb.com/billing/#cross-organization-billing) which allows you to more easily use distinct Organizations for authorization-level isolation while maintaining a loose coupling for billing centralization. I think this will open up a degree of flexibility that was previously lacking in our control plane authorization experience.
Nevertheless, we hear you loud and clear on wanting to be able to express finer grained control plane privileged actions and roles, and do plan to address this over the long term.
Cheers
-Andrew
