Customer Views

Multitenancy is acheived using Customer views that are a way of ensuring logged in users only see alerts that relate to their organisation.

This is for Alerta deployments that are used to manage multiple customer sites.

Roles

The role of an API key is assumed to be “user” if it is a customer generated key. The role of admin

You can have a customer/user API key and an admin API key, but not a customer/admin API key – this makes no sense.

How it works

A new top-level alert attribute called customer is used to partition alerts for particular customers within the same alert database.

When a user logs in to the Alert console, a customer lookup is done to determine what customer value should be assigned to that user.

The customer value is then used as an implicit additional filter for all alert and heartbeat queries.

It is also assigned to any API keys generated by that user and the customer field is automatically used whenever that API key is used to generate or query for alerts.

Configuration

To configure customer views follow these three easy steps:

Authentication must be enforced and customer views enabled so in alertad.conf:
```
AUTH_REQUIRED = True
CUSTOMER_VIEWS = True
```
Define administrators that will have a global view of all customers and will have no restrictions on generating API keys or blackout periods, so in alertad.conf:
```
ADMIN_USERS = ['foo@bar.com']
```
Populate the Customer Lookup table in the web console to map Google email domains or Github/Gitlab orgs and groups to customers

Web Console for Users

Users that have a customer view are limited to what they can do in the web console (and via the API). They cannot create other users, configure blackout periods or modify the customer lookup table.

Web Console for Administrators

Administrators are not limited in what they can do in the web console (or via the API). Importantly, they can configure the customer lookup table.