Security concerns of App Services: Team development can't be isolated?

MongoDB Atlas App Services & Realm
,
1

We have multiple teams developing App Services apps; I’m concerned how to properly ensure data privileges for them. Every app has access to all linked clusters with readWriteAnyDatabase. This comes from the internal database user generated by App Services mongodb-realm-<your app id>.

As this user can’t be modified, how can I ensure specific privileges for each team/app?

The most fundamental concern is to be able to configure readWrite to specific databases in the linked cluster. The obvious risk (by mistake or malicious) is data integrity issues. Having each team/app configuring their own rules for data access is a no-go.

So far, my only solution is to create a Project for each team/app with individual clusters and replicating shared data among them. With globally distributed clusters and large data sets, I’m not a big fan of this approach.

2

How about this for a suggestion?

Given
it is possible to modify privileges for Realm database users;

When
a new App Services app demoapp-xijqb is created;

Then
a new database demoapp-xijqb is automatically created;
user mongodb-realm-demoapp-xijqb has readWrite to it;
user mongodb-realm-demoapp-xijqb has no other access;
user mongodb-realm-demoapp-xijqb can be given custom privileges;

3

This would give us quite a few benefits.

A new app always gets a dedicated database; very easy to deploy the same app multiple times in the same project without interfering with someone else.

We can write code like this (we already do this but you get the idea):

const DemoColl = context.services.get('mongodb-atlas').db(context.app.clientAppId).collection('Demo')

Even better would be to have the default database name as a context/placeholder value. Using %(%%environment.values.database) is OK but a little error-prone in the deployment phase.

demoapp/data_sources/mongodb-atlas/%(%%environment.values.database)/Demo/rules.json

{
  "collection": "Demo",
  "database": "%(%%environment.values.database)",
  "roles": [
    {
      "name": "default",
      "apply_when": {},
      "insert": true,
      "delete": true,
      "search": true,
      "additional_fields": {}
    }
  ]
}

Another thought is to combine database name with environment so there is 4 databases in the cluster:

  • demoapp-xijqb (no environment)
  • demoapp-xijqb-development
  • demoapp-xijqb-qa
  • demoapp-xijqb-production
4

Hi Mikael_Guenius,

This is a feature in our long-term roadmap but it is part of an overarching initiative that allows finer-grained authorization for Atlas. It is a project currently in development but will likely not land until mid-to-late next year. Once that lands, we can support more granularity as users desire.

For now, users would need to create an Atlas cluster per-app per-tenant. Or potentially, severless could be an option once we release changestreams support (where device sync could integrate), which is targeted for early next year. Hope that helps!

5

@Kaylee_Won, thank you! Looking forward to it. Knowing this, I’m more confident that we eventually can consolidate our clusters safely.

PS: Another idea to consider is letting us create shared environments on top of our dedicated ones, much like you do on the free tier.