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.
-
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 -
Greg commented
Yes, from an enterprise standpoint, this is a problem. For example, if I have a user that I want to be able to grant "readWrite@mydb", but I also want to grant them the "modColl" privilege, there is no way to do this. I have created a custom role (modCollRoleTest) where I have granted the modColl privilege on the test db, but I am unable to grant both a "built-in" role AND a "custom role" to a user. Granted, I can add "readWrite@mydb" to the custom role and then grant the custom role, but this causes problems too. It means that if we want to maintain this sort of granular control that we have to create at least two new custom roles every time we create a new database even if we aren't sure we'll want to add granular privileges to those roles (one with read@db and one with readWrite@db). If we don't do this, then if we do need to add granular privileges, we'll have to create the roles and then go back and re-assign the appropriate role to the users with the built-in roles (read@db or readWrite@db) where appropriate.The ideal feature would be to be able to assign built-in privileges AND custom roles to users.
-
Hi Michael,
Thanks for flagging all of issues: we definitely want to improve on all of them.
You may want to take advantage of new functionality that we just launched for annual subscription customers: Cross-Org Billing. See https://docs.atlas.mongodb.com/billing/#cross-organization-billing for more information.
With this capability you can move some Projects to other Organizations (this can be done without downtime via a purely logical backend move), giving you a loose-coupling with authorization-level isolation, but a shared billing subscription. Organization-scoped users can only see the billing usage associated with their respective Organization.
Cheers
-Andrew -
Matt commented
One option is Project member get added to the Org-level as Project Member Only so the Org owner can know who has access (and change it), but the Project-level owners can also manage those users.
-
Stanislav commented
Same issue regarding access control management. we want Access Control Management to be a separate role.
-
Michael commented
1. Each Organisation-Member is able to read the billing details of the organisation. This should be restricted. We facing problems with our governance, because each member is able to get details about billing in MongoDB Atlas.
2. As an Project-Owner, you are able to invite new member to you project and so implicitly to the organisation. But you are not able to delete member from the organisation. If you delete a member, he has still access to the organisation and is able to read the invoice. Even if that member has not access to any project.
3. Each member gets the invoice via mail. Again this is not a good idea from governance perspective. You can only restict this, by adding (only one) "Billing Email Address". There should be a solution, to send the invoice only to project owners or something like this.