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

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

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.

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.

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.

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).

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!

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

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.

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

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

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

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.