Atlas
- A brief description of what you are looking to do
- How you think this will help
- Why this matters to you
71 results found
-
Ability to invalidate or revoke a X.509 certificate that was not expired.
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).
8 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.
8 votes -
Ability to change First and Last Name
It would be good if users are able to modify their First and Last Name after account creation.
7 votes -
remove the captcha from login, especially if 2 factor auth is enabled.
I very much dislike being asking to train ML models by doing picture identification just to login to my account. Please find a less offensive captcha process, or remove it entirely when 2 factor auth is enabled.
7 votes -
Atlas User permissions/role by Cluster
It would be very helpful to restrict/allow access to clusters within an Atlas project, by Atlas user. This can be achieved with database users, but Atlas users have all or nothing access to the clusters within a project.
6 votes -
make empty teams possible
It is currently not possible to create empty teams of remove all users from teams.
We would like to arrange our access management through teams. For our production environment we want a 'read only' and an 'admin' team. The admin team should be empty at all times, except in the case of incidents where we want to add specific users to the admin team to be able to solve the incident.6 votes -
Day granularity for Atlas-managed X.509 certificate
It would be great to add more granularity when creating an Atlas-managed X.509 certificate for a MongoDB user, i mean by day at least.
Thank you6 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…5 votes -
Reuse email address for new Atlas account
Please allow email addresses to be reused/reinstated for new Atlas accounts if an Atlas account associated with that email address has been deleted.
5 votes -
My entire team receives the billing info every month.
Billing should be limited to organization owners only and not viewable by the entire organization.
5 votes -
Project Monitoring Admin -- Access
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.
5 votes -
Change Username
Ability to change your username after registration and be able to re-use it should you need to.
5 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
4 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.
4 votes -
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…3 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.
3 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 -
Separate access control for read-only replicas
There is a multi-replica cluster and there are read replicas. I consider it necessary to add the ability to restrict access separately for a read-only replica. Thus, limit the connection not only to the entire cluster at the project level, but also to specific replicas (for example, limiting access to read replicas).
I think that this is a standard business problem, the solution of which is simply necessary to exist in a product like yours.3 votes -
Allow access from anywhere button to be a separate UI permission
"allow access from anywhere" button should be a separate privilege. This would allow the ability to add it to a role. The goal is to allow developers to log into the control plane, use the UI to add 1 single IP(theirs)...but not open up IPs to all(0.0.0.0/0).
3 votes -
Allow custom duration for Temporary Users
In our software development lifecycle, we have sprints that are 2 weeks long.
We create temporary users for Software Engineers that are "onCall" during a sprint. The role is moving to a different engineer each new sprint.
It would be great to be able to specify an explicit
deleteAfterDatevalue or a custom duration greater than the current 6 days.3 votes
- Don't see your idea?