Atlas
- A brief description of what you are looking to do
- How you think this will help
- Why this matters to you
74 results found
-
Granular Permissions
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…
477 votes -
Allow an "Any Database" option for actions in custom roles
Much like built-in roles have the ability to target all databases/any database, it would be ideal if collection actions could also target any database. Similarly to how, when adding collection actions to a custom role, if you leave the "collection" field blank, it applies to all collections in the specified DB, it would be great if you could leave the "database" field blank too (or add an "any database" option) and have the actions associated with the role be allowed on any database.
This feature gap creates unnecessary maintenance overhead for clusters with large numbers of databases. This is particularly…
99 votes -
Make session timeout in Atlas UI configurable
Session timeout value in Atlas UI defaults at 12h. Allow it to be configurable per Project or Organization, with the minimum value being 15 minutes. All Atlas users within an organization that have been idle for the duration of the configured session timeout should be automatically logged out.
44 votes -
Project teams
Hello,
I think it would be a good idea to have team management at project level.
We have many projects and members in our Atlas account.
I'm a organization owner. The people in my organization use the Altas service. I create
a project for them and give my colleagues the project owner authorizations.Project owners can invite other members. This is good. But it's a little inconsistent that
they are not able to create groups or teams within their projects They have to manage the permissions for each member separately.We can't use organization teams, because they are located at…
42 votes -
Support for User Groups with Separate Authentication Configurations
Currently Atlas only uses a single (flat) user group which only allows for 1 type of authentication per Organization.
However if Federated Authentication is enabled, the authentication mechanism in Atlas is bypassed for the IdP based on the domain name of the user and the configuration of Atlas Authentication.
This causes a problem if there are multiple groups of users who all share a domain name, some of whom are registered in an IdP, and some of whom are not registered in an IdP (for example users in 2 divisions of the same company).
In this scenario, users who are…
25 votes -
Projects Organization
It would be great if we could organize the projects and not have them all at the same level of organization.
We could use this hierarchy to put rights, consult costs ...
A bit like the idea of Azure's management group or GCP's "Folder".25 votes -
Migrate users and roles with cluster data
It would be great to be able to transfer users with their credentials and permissions from our on-premises deployment to Atlas during migration to avoid having to recreate those users using the Atlas interface or API.
22 votes -
Share API key cross organizations
Today, it's not possible to share an API key between different organizations (https://www.mongodb.com/community/forums/t/sharing-api-key-between-different-organizations/190785/13)
It makes it impossible to restore snapshots from one organization to another automatically.It's very important for us, as we need this feature to clone our customers clusters into our organization
19 votes -
API Key Expiration date
We have a security reqirement that secrets must expire after 2 years.
Therefore it would be awesome if MongoDB Atlas API Keys would support an expiration date.
Somethig similar exists for the IP Whitelisting. Here we have the option to remove IP Whitelist entries after er certain time period. But for API Keys it would be better to have an expiration date and keep the API Key in the list even if its expired.
In addition it would be good to have a daily notification once the expiration date is ahead less than 30 day.
19 votes -
Expose the killOp() action when creating custom roles in Atlas UI
It would be nice to have the
killOp()action exposed when creating a custom role in Atlas.I also think it would make sense to grant this action to the
atlasAdminrole, but at a minimum I feel that Project Owners should be able to create a custom role that is allowed to kill ops that were initiated by other database users.16 votes -
Allow me to stay logged in for a long period of time
I access Mongo Cloud / Atlas very frequently. However, almost every day I need to re-login using my Google account. It doesn't seem to "remember" my session.
I would love if I can extend the default, and let me (and other members) stay logged in for a longer period of time.14 votes -
Support Google IdP for OIDC Workforce Federation
The Atlas supports federated login with external Identity Providers via OIDC (https://www.mongodb.com/docs/atlas/workforce-oidc/) for authenticating human users in tools like mongosh or Mongo Compass.
Unfortunately the OIDC login doesn't work with the GCP IdP: OAuth2 clients in Google IdP always have a client secret (even clients considered as "public"). There is no way to specify the client secret in Atlas UI in the Workload Federation configuration and this leads to "invalidrequest (clientsecret is missing.)" error returned from the IdP as it always expects a client secret to be present.
The support of an optional client secret in…
13 votes -
Allow Atlas User Data Access Permissions to be configured on a per-database/collection basis
Similarly to how database user data access permissions can be configured on a per-database or per-collection basis, it would be ideal if Atlas user data access permissions (as they apply to Data Explorer) could be configured on a more granular basis as well.
13 votes -
API Improvements - OpenAPI and more auth options
The API should be documented with OpenAPI to allow better tooling.
Ideally using the above OpenAPI spec you could auto generate a SDK or API client for popular languages.
Lastly, the API should accept authentication options other than digest. There is very poor support for digest authentication by popular HTTP clients. I don't like trying to implement security protocols myself, as there is often some quirk I have not fully understood that ends up leaving me less secure than I hoped.
In many questions online when searching for information about digest authentication, the person asking the question is asking about…
12 votes -
Backup for project user
Hello,
it would be good if we could better granulate which users have access to cloud backups.
Currently only a project user with Project Owner rights can perform backups, restores etc. It would be really cool if some users, such as developers, could be given the right to work with the backup, and at the same time not have to have the Project Owner right, as it is not wanted to be able to add users, create and delete clusters etc...
11 votes -
create API keys that support linked orgs
It is possible to link multiple orgs to each other. It should therefore be possible to use a single API key to access all linked orgs.
11 votes -
Via API call invite existing atlas user & assigne them to project & teams
in are organization we want user to have a self serve service that allow them to create project, cluster ,etc ...
for now we can only automate half of the process, because we need the web UI to invite user & wait that they approve the invitation before assigning them to project.
It would be great than we could, via API call, invite user & assign them to project or team without having to use manual process & wait for user to acknowledge the invitation
thanks
11 votes -
Improve 2FA and auth management
Right now, there is no way to require Google auth or to require 2FA. The only way to enforce 2FA for a team is to check the team mangagement page. However, since some users may have only used Google auth to login, they will show up in this view as not having 2FA, creating auditing headaches. Please
- indicate if a user does not have 2fa because they do not have a password vs just not having 2fa
- ideally, add the ability to require 2fa and/or Google auth for all team members11 votes -
More granular user privileges for Database User in same project
When having several clusters in the same project, it would be nice if we could configure different privileges to different clusters for the same user credentials.
Like in the following example
Name | Cluster1 | Cluster2 | Cluster3 | Cluster4
User1 | R/W | R | R | R/W
User2 | R | R/W | R | RCurrently it's not possible to specify different privileges on the cluster level.
10 votes -
Manage Database Access and Network access
I would like to give colleagues the ability to manage Database Access and Network access for a project without giving the the project owner role.
A way to provide more granular access in Atlas would be nice
10 votes
- Don't see your idea?