Different permissions for developers across different cluster environments

Hi there, I’m new to the Mongo space and am a database administrator.
We have 4 clusters, DEV, SIT, UAT and PROD.
I want to grant a developer

  • read/write to a database in DEV/SIT
  • read to the same database in UAT
  • read to the same database in PROD
    It seems I am only able to grant read and readwrite to the database, and I need to then select all the clusters to apply it to, meaning if I add it for DEV and SIT, that works, but then when I add it to UAT and PROD it would give the developer read/write over those clusters which I don’t want.

Can’t seem to find a way to apply read to PROD and UAT cluster only.

Can anyone point me in the right direction?

Kind Regards
Rod

Hey @Rod_West,

Welcome to the MongoDB Community Forums! :leaves:

This looks like 4 separate systems, and thus would have 4 different users that are not connected to one another even though their username might be identical.

A way to give permissions to developers across different environments in your case is to create separate roles for the developer in each cluster. For example, you can create a role called developer_readwrite in DEV and SIT, a role called developer_read in UAT, and a role called developer_prod_read in PROD. You can then grant the developer the appropriate role in each cluster. This way, they will only have read/write access in DEV and SIT, and read access in UAT, and in PROD. This approach allows for more granular control over the developer’s access permissions in each cluster.

You can read more about managing users and roles here: Manage Users and Roles
More on Built-In Roles

Please let us know if this helps or if this is not what you’re looking for, then it would be great if you can share the process of how you created the roles and are granting the accesses to your developers. Are you creating these roles on mongo shell or using some other software to do so?

Regards,
Satyam

Hi Satyam, thankyou for the considered response, very helpful. I’m using the cloud.mongodb.com interface, in the database access tab under security, I see the developers username, and it has been selected for access on 2 (DEV/SIT) of the 4 clusters with read and readwrite MongoDB Roles to the user database.
So the only option through this interface seems to be to add the extra clusters which would give him the same read/write throughout the UAT/Prod clusters, or login to the UAT/Prod clusters and add his username in manually through mongo shell to the read role in UAT and Prod.
Does this sound correct?
The web interface isn’t very helpful for managing this access across multiple clusters for this reason.

Hey @Rod_West,

Thanks for clarifying on how you are granting permissions to the users. Unfortunately, Atlas currently does not support the kind of granularity that you intend to have for your clusters in the same project. It is currently not possible to grant more granular permissions at the project/cluster level for database users. What you’re after is similar to what is described in the following feedback post: More granular user privileges for Database Users in the same project.

You can in the meanwhile, have individual logins for each environment. Having different projects for your different clusters would also grant you more control over what your users can access and not access. You can migrate a cluster from one project to another using the live migration option from the UI, as described in the live import documentation. Additionally, you can also restore a cluster from a backup onto a cluster in a different project. You can read more about Projects and Accesses here: Manage Project Access. However it is important to note when moving a cluster’s data to another project, Atlas does not migrate any project settings (e.g. Database Access settings, Network Access Lists, etc.). You will need to create these again specifically for the new project.

Please let us know if this helps your problem or not. Feel free to reach out for anything else as well.

Regards,
Satyam

1 Like

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.