When testing out API keys that are normally only run through CI/CD tools, I'd like to be able to add my local IP to the API Access List for a temporary time window.

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

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 atlasAdmin role, 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.

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.

Currently all IdP federation set up must be done in the Atlas GUI. This prohibits scripting the setup of IdP organization and role mapping for new projects.

Customers can prefer setting this up via a scriptable Rest API interface for a new project. Everything else about the project has an API that is currently used to create projects and deploy clusters. Authentication is important part of the process and currently requires manual set up through the GUI.

It would be great to have an opportunity to automatically rotate the idp signature certificate.

I could provide a metadata.xml url. With that metadata.xml in generally it's possible that okta rotate the certificate on it's own. But it's not possible to configure in Mongodb Atlas.

Best regards
Fabian

Right now the API to retrieve information of a team ( either by ID or by Name ) only gives the name, the id and a link of the specific team.

I would like to see to what projects a team has access with which permissions ( as you can see via the atlas console ).

This would help a lot with automating access management

MongoDB Atlas does not seem to provide a tool or a page that will show the authentication logs for the Atlas console users. Example - a log indicating when a project owner or a cluster manager logged in or out of the Atlas console along with the relevant time stamps.

I have raised a support case with MongoDB and the engineer suggested to raise a feature request as this feature is currently not available. Refer case #00755619.

Thank you.

Billing should be limited to organization owners only and not viewable by the entire organization.

Hi Team,

We need to give access to a particular team so they can create, edit, clone, disable, and delete the alarm for the entire organization in Alert setting only.

We should not give them access other than the Alert setting. Is there any way to give access for Alert setting only, kindly provide your suggestions at the earliest.

Please provide us steps if there's any way to create custom access for alert settings alone.

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

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 members

Currently, X.509 certificates can be issued for authentication and authorization. However, it is not possible to invalidate an already issued certificate. In a situation where the certificate would be compromised, it is therefore not possible to invalidate it and re-issue a new one. The only way is to delete the user associated with the certificate and create a new user account (New CN).

When trying to implement Atlas infrastructure for Organization/Project users, the Teams functionality is useless unless we can add pending users to a Team. Right now, if a new user doesn't login for two weeks, we can't assign them to a Team until two weeks after the implementation was supposed to be configured.

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.

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.

When entering the txt value for validation atlas should use its own subdomain for the verification rather than requiring the domain root which is often populated with spf keys.

Other examples of this implementation are

Github: github-challenge-org.domain.com
Mandrill: mandrill.domainkey.domain.com
Google: google._domainkey.domain.com