According to the security organization’s R&R and the company’s RBAC policy, data access through the **Data Explorer** feature should be restricted for all roles except the Owner, including Project Owners. However, Project Owners currently have the ability to manipulate the availability of the Data Explorer feature. It is inefficient from a long-term operational perspective for the security team to intervene at the Project level (e.g., user access management). We request a solution or new role granularity that allows only the Organization Owner to control the **Data Explorer** feature.

Hi all, we’re happy to introduce three new Atlas Project roles: Project Backup Manager: Manage database resiliency without being able to make broader infrastructure changes or access Data Explorer. https://www.mongodb.com/docs/atlas/reference/user-roles/#mongodb-authrole-Project-Backup-Manager Project Observability Viewer: Utilize performance and ops monitoring tools without being able to manage infrastructure, configurations, or access data adhoc via the Data Explorer. https://www.mongodb.com/docs/atlas/reference/user-roles/#mongodb-authrole-Project-Observability-Viewer Project Database Access Admin: Manage database access without being able to manage infrastructure, configurations, or access Data Explorer. https://www.mongodb.com/docs/atlas/reference/user-roles/#mongodb-authrole-Project-Database-Access-Admin These three roles address some of the frequently-mentioned use cases in this thread that formerly required the Project Owner role. As we are still working towards continuously granulating our Atlas RBAC, including more built-in roles as well as ability to create custom roles with granular permissions, we’d also like to hear which use cases we still need to address. Feel free to keep adding your feedback to this feedback thread. Thank you!

hii, your website is so good. click this link too https://tiktok.com/@servisbinawebsite

+1 My organization is using MongoDB Atlas for some daily tasks. I’d love to set fine-grained permissions to, for example, edit specific collections.

I was told this issue is preventing us from using the API without creating a key that has __owner__ access. If that's true, then it... it seems outrageous? I cannot open our system up to a ransomware attack because my team is trying to setup scripting for compliance and disaster recovery. Is this truly under active development? It has been an open issue since 2020? Can additional resources be allocated and an estimate provided? Perhaps a smaller release could be cut to allow API keys with more granular permissions? I obviously am not privy to your backlog, and I certainly understand the difficulty of prioritizing items like this instead of new features that would improve sales, but this seems pretty egregious if you would like your clients to pass compliance and have disaster recovery scripting. Hopefully I am misunderstanding the situation and an alternative or workaround can be proposed. I would absolutely love to be wrong about this.

Hi, I also agree this is imperative (for I believe any large organisation) to manage permissions in Atlas. Can we get an ETA on this please? The link provided by admin points to this specific feedback item. Thank you.

The request was opened in 2020. It shows that this item was s tarted two years ago (2022). Seems like you have not started (or at least you did not back in 2022). Could you please provide us with an ETA?

This would be very helpful for compliance to restrict access based on need to know

Hi Hyung, Thank you for your feedback. This is a feature currently under active development. I recommend to follow it with existing feedback item: https://feedback.mongodb.com/forums/924145-atlas/suggestions/39906208-granular-permissions Thank you, Fuat -

Atlas admin can assign specific permissions to a custom Atlas role which will be very useful to control users for the project/org level. This is the same concept of the custom role of database user.

Specifically - managing project access lists can add a lot to security but that's much less effective if I'm creating an Project Owner api key to do so.

Hi Mongo Team. Could you please bring an update on progress for this feature? Thanks in advance ;)

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.