[SERVER-22951] Using regexp patterns for resource scope in user-defined roles Created: 03/Mar/16  Updated: 23/Jan/24

Status: Backlog
Project: Core Server
Component/s: Security
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: Pavel Duchovny Assignee: Backlog - Security Team
Resolution: Unresolved Votes: 14
Labels: security
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-48632 Use wildcard collections in user role... Closed
is duplicated by SERVER-78575 Use wildcard databases in user role p... Closed
Related
related to SERVER-13696 Allow revoke/deny role permissions Open
Assigned Teams:
Server Security
Participants:
Case:

 Description   

Resource document within Collection-Level Access Control currently supports the following.
1. Explicit values :

inventory collection in products database

 
{ db: "products", collection: "inventory" }

2. Empty strings that includes the entire scope :

all collections in products database

 
{ db: "products", collection: "" }

Request is to have a pattern matching on either db or collection fileds, this way permissions can be granted based on the matching pattern rather then explicit literals.

3. regexp example

Collections starting with "inve" in products database

 
{ db: "products", collection: "^inve*" }



 Comments   
Comment by Teddy poujol [ 11/Dec/23 ]

up folks

Comment by Shanjeef Satchithanantham [ 07/Nov/23 ]

Agree with spencer.brown@mongodb.com here re: ask at the collection level, and not at the document level. We don't want the role to query any specific tenant, but rather only allowed, specified tenants. To allow tenant specific access, I have leveraged [views|https://www.mongodb.com/docs/manual/core/views/] --> ex: given tenants X, Y and collection `users`, I have defined views `users.X`, `users.Y` and created a role that allows access to Y tenant'd documents via view `users.Y`. As new collections are added, I have a recurring job that creates views for new collection. Unfortunately at the moment, I must manually update the role's privileges list with the new views.

Comment by Teddy poujol [ 07/Nov/23 ]

Hello Folks

It's not really solving my problem.

 I have a dream, this dream is to grant rights in order to create database with a pattern like 'mydatabase*0[0-9]' and manage only these databases with that pattern.

privileges: [
       { resource: { db: "pattern_for_database_name", collection: "pattern_for_collection_name" }, actions: [ "find", "update", "insert", "remove" ] }
     ],

Currently we are able to do that at a collection level but not at database level.

Comment by Spencer Brown [ 07/Nov/23 ]

Salman, I see a couple of potential problems:

1. This would require a query parameter, but how would it enforce the value that is set? Could not this database user query any tenant?
2. This handles queries but what about inserts and deletes?

What this ticket is asking for is not access control at the document level, but access control by collection name. But document level access is a valid feature request, but is covered under another ticket.

Comment by Salman Baset [ 07/Nov/23 ]

Thanks, folks for your ideas.

If there was a way to define a database role which forces application to pass an application-specific specific tenant ID in every query, could that meet your needs?

Example:

1 Create a database read-only role for the application database user. This role requires a mandatory query parameter (appSpecificTenantId) which must be supplied on every query. The value of appSpecificTenantId parameter will need to be provided by the application on each query.

db.createRole({
  role: "appSpecificDBRole",
  privileges: [{
    resource: {
      db: "mydb",
      collection: "mycol" 
    },
    actions: [ "find"],
    mandatory_query_parameters: [ "appSpecificTenantId" ] //<-- does not exist today
  }]
})

 

2. Then, application issues a query such as the following where it always supply a value for `appSpecificTenantId` . Application may also add other filter parameters (`cityName` in this case)

db.users.find({ appSpecificTenantId: '1234', cityName: 'foo' }) 

Comment by Teddy poujol [ 06/Nov/23 ]

up

Comment by Shanjeef Satchithanantham [ 21/Aug/23 ]

Similar to Teddy above, I work on a multi-tenanted application where data segregation is enforced at the application (db driver shim) level. Our collections store documents that span across all tenants, but when queries are applied through app code, we enforce tenant segregation. Outside app logic, https://www.mongodb.com/docs/manual/core/views/ allow us to control which users have access to specific documents within a collection. It'd be great for us to have wildcard matching when defining resource access through roles. We have a pattern for creating our views (by tenant), but right now when a new collection (and view) is created, we have to manually update the role's privileges list. It would be nice to avoid this step! I have upvoted feature request: https://feedback.mongodb.com/forums/924145-atlas/suggestions/46874569-use-wildcard-databases-in-user-role-privileges-li 

Comment by Teddy poujol [ 06/Jul/23 ]

Hello,

It would be great to be able to use wildcard databases when creating privileges for user roles.
both for the creation of new databases and the management of the existing.

We needs to be able to create roles that enable multitenant architecture.
For exemple, in order to create dynamicaly databases per tenant and per microservices.

We have for exemple 2 microservices: microservice1 et microservice2
and 2 tenant: tenant 1 and tenant 2.
And we want to create RoleMicroservice1 and RoleMicroservice2

 

db.createRole(
   {
     role: "RoleMicroservice1",
     privileges: [
       { resource: { db: "*-microservice1", collection: ".*" }, actions: [ "find", "update", "insert", "remove" ] }
     ],
     ...
   }
)

 

This would make it easier for administrators to manage permissions for all databases but enables our developers to create dynamicaly databases without impact on other microservices databases.

Generated at Thu Feb 08 04:01:55 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.