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
-
Add support for custom comment field per API key access list entry
Currently, in the API Access List for an API Key in MongoDB Atlas, there is no way to associate metadata or context with each IP address or CIDR block. This makes it difficult to track the purpose or ownership of each entry, especially in environments with multiple users, services, or automation systems.
Please add support for an optional comment (description) field for each entry in the API Access List associated with an API Key. This field would allow users to provide human-readable context, such as:
- Who owns this IP address or range
- What system or service it corresponds…4 votes -
Masking of PII fields
Context:
We have multiple downstream systems that consume data from MongoDB. These systems are not capable of decrypting sensitive Personally Identifiable Information (PII) fields. Currently, to protect PII, data is encrypted in MongoDB, but downstream systems cannot process or display these fields without decryption, which poses operational challenges and security risks.Request:
We would like MongoDB to provide a native field-level data masking feature that allows:Masking or redacting sensitive fields (e.g., PII fields) at query time without requiring the consumer to decrypt the data.
The masking should allow downstream systems to receive the data in a protected form (e.g.,…
1 vote -
Identify users via API that are regular project users versus federated or built-in (e.g., charts) users
Expand the API to allow a way to identify and differentiate federated users and other non-manageable users (like "Charts User") from regular project users in MongoDB Atlas using API output, similar to how the Atlas UI visually marks federated users. For example, the Atlas UI displays a greyed-out edit icon and the ScreenTip displays a "Roles are managed through federated role mapping".
7 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…
14 votes -
12 hour option for Temporary User
Add support for a 12 hour Temporary User.
6 hours is too short for a working day
24 hours is too long for a working day12 hours is just right.
1 vote -
MongoAtlas Orga - Maximum number API keys exceeded
We have detected in our organisation that the limit of API keys has been reached. This is currently affecting our project teams in terms of resource distribution, so we are asking for an increase in the quoter in the short term.
Problem: We can't create keys and also delete them. The problem is that the key does not have an owner. Only org owner can delete this key. They did but this is only a reference deletion.
Alerting: Condition for alerting is not there
What we want to achieve:
- Transparency for the org owners about what the limit level…4 votes -
A new role for security auditing purposes
Currently MongoDB Atlas provides two read only roles at project level ("Project Read Only", and " Project Data Access Read Only").
"Project Data Access Read Only" seems to allow access to the data also, while "Project Read Only" role does not allow access to the logs. (https://www.mongodb.com/docs/atlas/reference/user-roles/)
For security officers (internal/external), they need to access to the logs (audit, access, etc) and also to review the configuration; but don't need access to the data.
Therefore, I would like to request a new project level role for security officers with following features.
- access to "Download Logs"
- access…6 votes -
Return a user createdDate for Atlas control plane and database users
Automated user systems such as Hashi-Vault will automatically create users. Typically these users have a 90day expiration. Any team using continuous delivery hits the atlas user limit. There is not a way to know when an atlas user was created from the API data
5 votes -
Support OIDC as Authentication Protocol for access to Mongo Portal
Currently SAML is supported: https://www.mongodb.com/docs/atlas/security/federated-authentication/#configure-federated-authentication
It would be preferable if OIDC was supported.
6 votes -
Atlas access management similar to Azure AD Privileged Identity Management (PMI)
Hello, we are looking for functionality that allows users to auto-promote or adjust their privileges based on the access needed.
For example: if user XYZ needs access to DB:123 he can elevate access himself to this db.
This would be similar to Azure Active Directory (Azure AD) Privileged Identity Management (PIM). A service offered by Microsoft as part of its Azure cloud platform. It helps organizations manage, control, and monitor access within their Azure AD environment, particularly for privileged accounts. These accounts have elevated permissions that can perform critical tasks, such as managing resources, configuring settings, or accessing sensitive data.
…
6 votes -
Hello, your login captcha is a real pain ********** !!!!!
Hello, your login captcha is a real pain ********** !!!!!
2 votes -
Atlas Role
The idea would be to have more advanced options when configuring access management to different projects/clusters.
A lot of companies would benefit greatly from seeing a segregation of roles and access to different features on a project.
It would be beneficial to have more read roles - focus on the metadata layer, but it would be also nice to have it on the DB level e;g. Onboarding a local entity - DBAs want to see only dedicated DB information - should be then between their responsibility.
The idea is to have differentiation between metadata and data, It can be particularly…
1 vote -
Include IdP Group and Atlas Role mapped in the ROLE_MAPPING_CREATED event
When an Atlas Role is mapped to an IdP group in the Federation Management Console, an event is created with the eventTypeName "ROLEMAPPINGCREATED" and the description "A Role Mapping was Created". The event returns in both the Atlas Admin API events endpoint and the Organization Alerts. It would be beneficial for auditing to include the IdP group and Atlas Role in the event.
2 votes -
Associate domains to an IDP at Organization level rather than for entire mongodb.com
At this time domain to IDP associations apply to entire mongodb.com. This makes it very difficult for large companies that have several independent departments to use mongodb.com. Some departments might want to create separate Atlas organizations and others simply access Support section of mongodb.com web-site. They wouldn't want to share an IDP created within one Atlas organization.
One possible approach to addressing this issue is for an Atlas organization to have a distinct sub-domain on mongodb.com (e.g. bigco-org-a.mongodb.com). Another approach would be to have a field for Atlas Organization name on logon page.
6 votes -
Parent - Child account set up
I have a client that has multiple BUs and would like to organize them under a Parent account. From my understanding, Atlas does not currently support a Parent-child account set up. This would be beneficial to have as we continue to onboard our enterprise clients and we get more use cases.
1 vote -
org owner permissions won't revoke due to role mapping
When choosing to use idp role mapping, if a user is not part of a group, his permissions are revoked, including locking him out of crucial administration options.
Users with the org owner permissions should be handled as super users and be excluded from any role mapping in order to refrain from having their permissions change
1 vote -
U domain Verification
If you are able to verify the parent domain for your company, then you shouldn't need to have to verify the sub-domains associated with that domain. Company's do not generally advertise their internal u-domains on the internet therefore any verification on that sub-domain will naturally fail. This is hindering us from integrating our Okta credentials with our login information.
2 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...
12 votes -
Option to Enforce Certain MFA Methods
Allow certain MFA methods to be disabled for our Organization.
e.g. we don't trust SMS or Email so want to force our users to only use Google Auth / Security Key/Biomeytric or Okta.3 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
20 votes
- Don't see your idea?