14 results found

1. Allow to define access to DBs/collections by prefix or pattern.

   Please extend ACL to support prefixes (or regex) in the database name/collection.
   Currently only allowed ALL (when empty string provided) or exact db/collection matching when provided.

   Use case: Several services are using the same cluster but need to be isolated. Every service can get readWriteAnyDatabase but only to databases prefixed by some prefix.
   Services need to create new databases on the fly, so it is not possible to define a list of databases upfront.

   For example - rwRoleForService1 allows "update", "insert", and "remove" operations only on databases prefixed by "service1-" (sevice1-db1, sevice1-db2, ....)
   {
   role: "rwRoleForService1",
   privileges: [
   {
   { resource: { db: "service1-", collection: "", dbPatternType: PREFIX },
   actions: [ "update", "insert", "remove" ] },
   },
   ...
   ],
   ...
   }

   dbPatternType/collectionPatternType can be:
   LITERAL (by default) - A literal resource name.
   PREFIX - A prefixed resource name.
   REGEX - Will perform pattern matching.

   Please extend ACL to support prefixes (or regex) in the database name/collection.
   Currently only allowed ALL (when empty string provided) or exact db/collection matching when provided.

   Use case: Several services are using the same cluster but need to be isolated. Every service can get readWriteAnyDatabase but only to databases prefixed by some prefix.
   Services need to create new databases on the fly, so it is not possible to define a list of databases upfront.

   For example - rwRoleForService1 allows "update", "insert", and "remove" operations only on databases prefixed by "service1-" (sevice1-db1, sevice1-db2, ....)
   {
   role: "rwRoleForService1",
   privileges: [
   {
   {… more

   6 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Security  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

2. Use a private peering that resolves to the private IP address of your LDAP server.

   We need to consume an LDAP server traffic through Private Endpoints. In the documentation we find that only creating a public endpoint it's possible but we have a security restriction. Our TAM suggested create a feedback request to the product owner.
   tks!

   4 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Security  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

3. Deny Privilege

   Provide the ability to explicitly deny a privilege on a specific resource.

   Example: Grant the privilege to perform the find action on all collections in the test database except "test.secrets".

   4 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Security  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

4. Enhancement on Native Auditing

   When we enable native auditing the following three information is missing. Its more useful from security aspects . Can it be considered to capture these information in current or future releases soon..

   Session ID
   
   OS user
   Service name

   Kannan

   3 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Security  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

5. Add SSO authentication support to mongoDB database

   Existing issue: One user has accounts in multiple mongoDB databases on Atlas that exist in different Projects and maybe Organizations as well. When he wants to switch from one database to the other from a 3rd party app, he has to provide his credentials every time.

   Adding SSO authentication support to the mongoDB databases would add flexibility to a user like that, to switch from one database to the other without being asked for his credentials every time when connecting from a 3rd party application.

   3 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Security  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

6. Add timestamps to user documents

   Most database technologies store this metadata by default.
   Because the expected data volume and change rate of this attribute will most probably be low, there should be no reason of not storing this information.
   Of course this information might already be available in audit files, but first: auditing isn't enabled by default.
   Second: most database users won't have access to this file/info and third: most users won't expect this info in a separate file (reminder, MongoDB recommends to store the data where it belongs when it comes to "data/schema modelling", so the metadata of a user document should also be located within this document!).

   Most database technologies store this metadata by default.
   Because the expected data volume and change rate of this attribute will most probably be low, there should be no reason of not storing this information.
   Of course this information might already be available in audit files, but first: auditing isn't enabled by default.
   Second: most database users won't have access to this file/info and third: most users won't expect this info in a separate file (reminder, MongoDB recommends to store the data where it belongs when it comes to "data/schema modelling", so the metadata of a user document should also be… more

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Security  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

7. Improve fortification coverage with _FORTIFY_SOURCE=3

   MongoDB Server codebase uses _FORTIFY_SOURCE=2 fortification level (e.g. see v7.0, latest at the moment: https://github.com/mongodb/mongo/blob/v7.0/SConstruct#L4698).
   Consider changing it to a new fortification level (_FORTIFY_SOURCE=3) provided by GCC 12 to improve DB's security.

   See also:
   https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distribution_build_flags
   https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Security  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

8. Make consistent use of system-wide CA certificate store

   Please make the use of system-wide CA certificate store the same in all tool/commands.

   • If tls.CAFile is not specified in mongod/mongos configuration then the system-wide CA certificate store will be used.

   • If --sslCAFile is not specified in mongoimport/mongoexport tool then the system-wide CA certificate store will be used - but this behavior is not documented.

   • For mongosh you have to specify option --tlsUseSystemCA is you like to use the system-wide CA certificate store. I did not check how it is/was working in legacy mongo shell.

   • For command Mongo() (https://www.mongodb.com/docs/v6.0/reference/method/Mongo/), I was not able to find out, how to use the system-wide CA certificate store

   • If you add tlsUseSystemCA=true to connection string URI, then you get an error

   So, there are several ways for doing that. There should be a consistent way across all tools

   Please make the use of system-wide CA certificate store the same in all tool/commands.

   • If tls.CAFile is not specified in mongod/mongos configuration then the system-wide CA certificate store will be used.

   • If --sslCAFile is not specified in mongoimport/mongoexport tool then the system-wide CA certificate store will be used - but this behavior is not documented.

   • For mongosh you have to specify option --tlsUseSystemCA is you like to use the system-wide CA certificate store. I did not check how it is/was working in legacy mongo shell.

   • For command Mongo() (https://www.mongodb.com/docs/v6.0/reference/method/Mongo/), I was not able to find out, how to… more

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Security  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

9. testing

   <BODY onload!#$%&()*~+-_.,:;?@[/|\]^`=alert("XSS")>

   • 

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   4 comments  ·  Security  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

10. Implement restrict Network access list to improve Security risk

    Currently the Network access list admits to add IP addresses to allow connections from. However, we are using Private Endpoints to connect to our clusters; from Google Cloud we cannot add rules to PSC in the firewall, so this means that being in our VPN all devices internally has access to our mongo databases.

    How can we prevent access from any place in our company to our databases. This is a huge security risk.

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Security  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

11. STIG for MongoDB 6
    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Security  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

12. STIG for MongoDB 5
    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Security  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

13. Please create a build in role that grants developers all permissions needed to add/edit schema validations short of adminAll.

    Please create a built-in role that grants developers all permissions needed to add/edit schema validations short of dbAdminAnyDatabase.

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Security  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

14. Support for CentOS Stream 8 in MongoDB OPS Manager version 5.x

    Per the Server Support Matrix https://www.mongodb.com/try/download/ops-manager support for CentOS Stream 8 is not al.
    We would like to see the currently supported MongoDB OPS Manager version 5.x available on the CentOS Stream 8 distribution.

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Security  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close