Hi Mongo Team,

I would really like this feature implement immediately.
Because if we organization consist of Developer, Data Team and Tech.
Now only Tech have full access, if we share to Developer and Data Team it would cause issue, because we should not allow other team for able to read all the data inside cluster.

I second on this request, this should be a top priority fix.

It doesn't make sense when I restirct access from DB while all user can just access everyhing from Atlas UI(we do need this b/c Atlas Chart is a selling point to us), there should have some consistence of access control across frontend & backend.

I have just raised a support ticket with the following limitation as more granularity is required. You must grant the ORG_OWNER role to an API key if you need only READ access to the Federation Settings. The ORG_READ_ONLY role receives a 403. The permissions need to be more granular.

Hi Jaime, thank you for the feedback. We are actively working on this feature. I will close this feedback item as it is a duplicate but please follow it here https://feedback.mongodb.com/forums/924145-atlas/suggestions/39906208-granular-permissions to get updates.

Create the ability to make custom Project Roles to allow for users to have some of the Project Owner permissions but not all. In our example, we want to limit who can modify the Network Access Allow List but still provide other Project Owner capabilities.

When defining Custom Roles it should be possible to use placeholders / patterns (regex ?!?) in the "Database" or "Collection" field. This would allow to setup more fine grained rules and allow to reduce the count of rules to be defined.

I need to employees in operations team access to download backups while still limiting other access rights

On Mongo Atlas we are looking to restrict the user permission in specific cluster within project.

I would like to vote this request, since I hear that from the field that customer would like to have more possibilities to allow/restrict access per particular user/group also for CHARTS specific

We are looking for this feature that will allow our teams to access to the Atlas Query Profiler without also granting at least read-only access to the Data Explorer.

We have many teams with different databases they are managing on a cluster.
Right now, to create Search indexes, they have the permission at the project-level and thus can create/delete Search indexes in ALL databases; not just their own.

@Fuat thanks for the update, appreciated. There was no communication on this ticket therefore your comment sheds some light on the case.

Just to clarify, if MongoDB teams are actively working on it, why do you ask for votes to get further updates on this? Should you not provide updates by default now that the teams are working on this case?

Just to bring some clarity with a public comment: The status of this ticket was updated to Started on Jul 20, 2022 that means the work to address the request started and MongoDB teams are actively working on it. Please vote for this request to get further updates.

Was about to vote for this, but then realised the issue was raised 3 years ago(!) with virtually no progress despite hundreds of upvotes. My conclusion is that this feedback platform does not seem to serve any purpose.

Each member of an organization with "Organization Member" role is able to read the billing details of the organization. This should be restricted. We facing problems with our governance, because each member is able to get details about billing in MongoDB Atlas.

The use-case is to share a dashboard with no ability to read billing informations.

I voted for this but I came to a point where I have to say: it would be much more useful for an organization like ours (regulated) to have policies on an organization level that prevent unwanted settings espacially in App Services (like creating endpoints or allow anonymous authentication or just creating ip access lists .... there are tons of such settings) ... so if I have to decide between having fine grained permissions or policies to prevent unwanted/mistakenly made settings I would go with the second. By the way it seems that Atlas has to do some heavy lifting with the fine grained permissions compared to the time this is an open and whished feature ... ;-)

Ditto what has been said about being able to get granular enough to control app services like Realm.

Our use case: give manager permissions to create and invite new users to projects. For that project owner role is needed. With that role, the manager will have access to all data and this is not least privilege principle

Please include permissions for App Services (realm). Right now if you want to edit/test a function in the realm UI, you have to have owner level permissions. That is not a permission level that should be given to most resources on the project

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.