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.
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.
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.
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.
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.
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.
Same issue regarding access control management. we want Access Control Management to be a separate role.
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.