Configure multiple tenants on your instance

Enable multi-tenancy to allow one security team to manage multiple independent customers while segregating their customers' assets and data. For example, a Managed Security Service Provider (MSSP) business can use multi-tenancy to perform incident response for multiple clients with one analyst team on a single instance and maintain customer separation. The MSSP SOC can administer each customer's data set without needing a separate login and permissions configuration.

How many tenants can be configured?

The Community License only allows for one tenant if the multi-tenancy feature is enabled. You can view the number of allowed tenants in your instance by performing the following steps:

1. From the main menu, select Administration.
2. Select Company Settings, then select License.
3. View the information in the Tenant Count field.

The system default tenant doesn't count towards the total count.

Enable multi-tenancy

multi-tenancy isn't enabled by default. Perform the following steps to enable multi-tenancy:

1. From the main menu, click Administration.
2. Select Product Settings, Multi-tenancy.
3. Toggle Enable Multi-tenancy to ON.
4. Click Confirm to confirm that you want to enable multi-tenancy.
5. Provide the information for the default system tenant.
6. Click Save.

View the tenants configured on your instance

To view the configured tenants in , perform the following steps:

1. From the Home menu, click Administration.
2. Select Product Settings, then select Multi-tenancy.

The default system tenant has an ID of 0. Each container in must have one tenant assigned. Before creating any additional tenants, all containers are assigned this default system tenant. Any containers that don't have an explicitly specified tenant and are created through an automated process are assigned to the default system tenant. If a container is created manually through the web interface you must select a tenant once you enable multi-tenancy.

Add a tenant to

To add a new tenant to , perform the following steps:

1. From the main menu, click Administration.
2. Select Product Settings then select Multi-tenancy.
3. Click + Tenant.
4. Complete the information in the Add Tenant dialog box.
5. Click Save.

You can configure only as many tenants as your license allows, not including the default system tenant. If you already reached your limit, you must disable an existing tenant before you can add a new one.

Edit an existing tenant in

To edit the information for an existing tenant, hover and click the tenant you want to edit. Once a tenant is defined, you can't delete it. You must disable it instead. All tenant names must be unique.

Configure permissions for tenants and assets in

Each asset in must belong to one or more tenants. An asset can only be used by containers that share the same tenant as the asset. See Add and configure apps and assets to provide actions in for more information about configuring assets for tenants.

You can restrict access to tenant information based on role configuration in . A role with no tenants specified means all users with the role have access to all tenants. To limit access to specific tenants, specify the tenants as part of the role configuration. See Manage roles and permissions in for information about configuring tenant user permissions.

Each container must have exactly one tenant. If no tenant is assigned to a container, then the container belongs to the default system tenant. An asset can have no tenants, which means it can be used with any tenant. See the following examples of assets and tenant usage:

• You can make assets based on public services, such as the whois databases, usable by all tenants.
• You can subscribe to a commercial service and make this service available for all tenants regardless of service level.
• Some assets such as a customer's firewall belong only to a specific tenant. Configure only one tenant for this type of asset.
• A premium commercial offering such as a commercial sandbox might be made available to a specific group of tenants. In order to ensure that only customers paying for that offering can use it, configure the asset so that it has only the paying customers.

Ingestion assets must have only one tenant, and this tenant is also assigned to any containers created by the ingestion asset. You can use separate assets for an app to separate data for different tenants. For example, consider if a Splunk Enterprise app is ingesting multiple customer logs tagged per customer. You can have a app that performs periodic polling of the Splunk Enterprise app based on a query containing the customer tag. One customer is called Initech, and a second customer is called Initrode. Create one asset for each company based on the Splunk Enterprise app:

• One query can contain customer=initech. Containers created by this asset belong to the Initech tenant.
• The second query can contain customer=initrode. Containers created by this asset belong to the Initrode tenant.

Containers can also be pushed to using the REST API. The REST API is accessed by automation users in , each of whom is assigned a default tenant. The API caller can override this tenant, or use the default tenant if one is not specified. See REST Containers in the REST API Reference for .

In situations where you are not able to assign the correct tenant to a container, such as if you are unable to properly separate the data for different tenants, or do not have proper access to call the REST API to create containers, you can ingest the data using any default tenant, then use a playbook to assign the container to the desired tenant. For example, a container might have a field or artifact that maps directly to a customer name, or you might even need to look up custom IP address ranges to determine the customer before assigning the proper tenant.