# Configuration question for multi-tenant setup

**URL:** https://discuss.konghq.com/t/configuration-question-for-multi-tenant-setup/7513
**Category:** Questions
**Created:** [November 26, 2020, 5:32pm UTC](https://discuss.konghq.com/t/configuration-question-for-multi-tenant-setup/7513 "2020-11-26T17:32:46Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![anorm](https://avatars.discourse-cdn.com/v4/letter/a/9dc877/32.png) [@anorm](https://discuss.konghq.com/u/anorm)
#### Post date: [November 26, 2020, 5:32pm UTC](https://discuss.konghq.com/t/configuration-question-for-multi-tenant-setup/7513/1 "2020-11-26T17:32:46Z")

</div>

We’re planning to use Kong as an API gateway in front of a set of services. Our product is a multi-tenant solution where each tenant has a number of users.

**Requirements**

- A user with admin rights within a tenant can issue an API key which grants access to the APIs but limits the access to that specific tenant.
- Several API keys may be issued for the same tenant
- API keys should only have access to a selected set of services
- All services and all tenants are served by a single host ([api.example.com](http://api.example.com))

**My ideas**

I thought of solving this by

- Create services with corresponding routes `/service-a`, `/service-b`
- The routes will have ACL plugins requiring the consumer to have a specific group (`/service-a` requiring `group-a`, etc)
- Creating a new Kong Consumer for every issued API key.
- The consumers will have groups added corresponding to the services served.
- The consumers will have individual Request Transformer plugins set up which adds a “X-Tenant-Id” header so the upstream services know which tenant to serve

**Questions**

1. Is this a good way of configuring Kong for my use case?
2. Assuming there are 10,000 tenants, all with 2 API keys, there will be 20,000 request-transformer plugins running. Is that OK?
3. Is there a way to have a database table with API keys and tenant IDs and make the above mapping dynamically?
4. How can I make sure the “X-Tenant-Id” (and other internal headers) are stripped from the client requests? I could delete it with a request transformer but the order of the transformers are not easily controlled (all have priority 801 and when configured with decK, there is no way of controlling creation order)