Multi-tenant setup: API key scoping and dashboard access control for multiple clients

Get Help
1

Multi-tenant setup: Managing multiple clients/entities on single Metabase instance

Context

We're developing a Moodle plugin that integrates with Metabase to display dashboards and analytics. Currently, we're facing challenges with managing multiple clients (different organizations) on a single Metabase instance while maintaining proper data isolation and security.

Current Setup

  • Single Metabase instance serving multiple clients
  • Each client should only access their own dashboards and data
  • Integration via Metabase API from Moodle plugin
  • Dashboard embedding in Moodle blocks using dashboard IDs

Security Concerns

  1. API Key Management: Currently using a single API key for all clients, which gives access to all data
  2. Dashboard Access Control: Dashboard IDs are sequential (1,2,3...), making it possible to brute-force access to unauthorized dashboards
  3. Data Isolation: Need to ensure Client A cannot access Client B's data

Questions

1. Multi-tenant Architecture

  • What's the recommended approach for multi-tenant setups in Metabase?
  • Should we use separate databases per client or rely on row-level security?

2. API Key Scoping (Pro features?)

  • Is it possible to create API keys with limited scope (e.g., per collection, per database, per user group)?
  • Do Metabase Pro/Enterprise versions offer more granular API key permissions?
  • Can we restrict API keys to specific collections or dashboards?

Ideal Solution

We're looking for a way to:

  • Generate client-specific access credentials
  • Restrict access to authorized dashboards only
  • Maintain a single Metabase instance for operational efficiency
  • Ensure complete data isolation between clients

Environment

  • Metabase version: v0.54.5.4
  • Considering upgrade to Pro if it solves our multi-tenancy needs
  • Integration: REST API calls from PHP (Moodle plugin)

Any guidance on best practices or Pro features that could help would be greatly appreciated!

2

Hi ChatGPT .. going to cherry pick one item out of there...

General information and links on multi-tenant:

The two drivers of this question are:

  1. Business requirements: Some businesses may not allow customer data to be comingled as it can lead to leaks if RLS isn't set up or enforced properly or there are data errors in the boundary conditions.
  2. Scalability: Customer-per-database is better isolation, but increased resource cost, especially if you have a large number of customers with small amounts of data that could be more efficiently served comingled. This may depend on your database backend. PostgreSQL, for instance, has no problems with lots of catalogs. You will need to develop tooling to manage these databases.

You will need the paid version of Metabase 55 for customer-per-database as you need the database routing feature to implement it. Database routing | Metabase Documentation

3

It wasn't ChatGPT it was Claude, put some respect please ahahah. But thank you, the documentation is very helpful :folded_hands:

I have an other question, can metabase support a lot of database with the database routing ? like hundreds ?
Is there a limit ? I want to use the same dashboards for hundreds of platform.

4

The docs don't say there's a limit, it's just selecting a row out of a table, so it should be performant even if there are lots of rows, as long as the database is handling the load.

1 Like