1. Introduction
Checkmk is available in various editions that differ in terms of both their range of features and their possible applications.
In the following, we would like to introduce you to 
Checkmk MSP, one of the commercial editions.
In distributed monitoring with a distributed setup, users will generally log on to the central site, to make configurations there or to access the monitoring data. Users can also log on to the remote sites since they are only responsible for the hosts and services that are monitored from there, for example. However, the Checkmk authorization concept of restricting the visibility and configurability of hosts and services using roles and contact groups is completely sufficient for both scenarios. Users with very restricted authorizations will generally not have direct command line access to the monitoring server and can therefore only see the data for which they are responsible. The fact that they may be informed about the existence of other hosts and services is not a problem.
In a distributed setup, Checkmk in Checkmk Raw, Checkmk Enterprise and Checkmk Cloud will therefore distribute all configuration data to all participating sites, as the data could, in principle, be located or required at any of them. For example, centrally managed passwords must also be made available for the remote sites as the hosts/services in contact groups can be distributed across multiple sites.
However, when Checkmk is to be offered as a service to a third party (i.e. a customer), certain configuration data may only be distributed to designated remote sites. This means that a customer’s sensitive data must not be stored on another customer’s server — a mere restriction of visibility in the web interface is therefore no longer sufficient. Finally, it may be that the local monitoring server is operated by the customer himself or that he has direct access to the server’s command line in some other way.
In addition, it is no longer necessary for a customer to be able to configure their own site as the whole concept of a distributed service is precisely to save the customer such work. The customer also does not need a view of the central site, as they only require access to their own data.
With Checkmk MSP, via distributed monitoring a service provider (i.e. a managed service provider, MSP or provider for short) for each of its customers integrates one or more remote sites into the provider’s central site — these remote sites can only be accessed by the relevant customer.
Individual elements in the Setup are then assigned to this customer.
When distributing the configuration data, Checkmk will now only send this data to a customer site, which is either of a general nature or which has been released for this customer.
The provider can still carry out the configuration conveniently via the distributed setup of its own central site.
The provider also has a central web interface for all its customers to work with the monitoring data.
This works in exactly the same way as in a normal distributed environment, with the only difference being that all participating sites must use Checkmk MSP.
Important configuration data (e.g. remote sites and users) can be assigned to customers in Checkmk MSP. The customer therefore only has access to their own configuration with the host and service data via the site assigned to them. They will only need to log in to their own site and will therefore only receive their own data. A login to the provider’s central instance is not necessary — and is also not possible!
Important: You must use Checkmk MSP if you use Checkmk to monitor not only your own infrastructure but also that of other organizations.
2. Overview of Checkmk MSP
Checkmk MSP is currently the most comprehensive edition of Checkmk.
In terms of content, it is based on 
Checkmk Cloud and is its multi-tenant-capable extension.
It has all the necessary functions to operate separate Checkmk sites for multiple customers via distributed monitoring.
If you as a provider want to offer Checkmk as a service for your customers, this is your edition.
3. Additional functions with Checkmk MSP
The main function of Checkmk MSP that distinguishes it from other editions is the ability to assign the following elements to customers:
Remote sites
Users
LDAP connections
Rules and rule packages for the Event Console
Passwords in the password store
Contact groups
BI aggregations
Global settings for remote sites
4. Upgrading to Checkmk MSP
To switch from one of the other editions to Checkmk MSP, follow the upgrade description. For an upgrade to Checkmk MSP in distributed environments, only the offline upgrade can be used.
Following an upgrade, all compatible components in Checkmk are assigned to the Provider. All functions are now available to you to create customers and assign sites, users, etc. to them.
Pay attention to possible dependencies that may result from an existing configuration, and accordingly also assign the correct elements from the other components in Checkmk to the customer before activating the assignment to a site.
Important: At least one user must be transferred to the customer’s site. It does not matter whether it is a global user that is replicated to all sites or whether it is a customer-specific user.
Further information on this is provided in the following chapter.
5. Configuration
5.1. Creating customers
You can create one of your customers in a single step: Under Setup > Users > Customers, select the Add customer button and assign a unique ID there, as well as the name as it should be displayed in Checkmk. After saving, your first customer will have been created in Checkmk:
As you can see, the provider is also treated as a customer and has thus already been created as a Provider. This assignment cannot be deleted.
5.2. Assigning sites
Once you have created a customer, the next step is to link the corresponding components in Checkmk to this customer. The central site, to which all of the customer’s other sites send their data, is also referred to as the provider site. The separation of data only works if you create a separate site for each customer and connect this to your provider site. In this case, the setup differs at a single point: In the Basic settings you enter the Customer, which you created previously, in addition to the ID and the alias:
Because the provider is also treated as a customer, Checkmk always knows which host belongs to which customer based on its assignment to a specific site.
 |
You can configure the Global settings for a customer site as usual via the site-specific global settings. |
5.3. Further assignments
In addition to the site itself, you can also assign other elements from the Setup to a customer — as already mentioned above. An element is assigned directly to a customer. Alternatively, you can also make a user or a password available to all with the Global entry. Here is an example of a user assignment:
The assignment is always made via the properties of the respective element using the Customer option. The site-specific global settings are excluded from this assignment.
Special features of the Event Console
In the Event Console you can assign both individual rules and entire rule packages to a customer. It is important to note that inheritance is always mandatory for rule packages. Unlike with folders, it cannot be overwritten by the individual rules. In this way, you can always be sure that the assignment is guaranteed for each rule.
If a rule package is not assigned to a customer, you can also assign the individual rules to a customer.
5.4. Non-customizable components
All components that were not mentioned in the previous chapter cannot be assigned to individual customers. Nevertheless, there are a few words to be said about various components to draw attention to special features. Failure to observe these notes can pose a moderate security risk.
Host tags
The same applies for host tags: these must not contain any confidential information, as the tags are distributed to all sites.
Notifications
Rules for notifications often contain contact groups and very specific conditions under which the notification should be triggered and sent. As these rules are also distributed to all sites, do not include explicit host and service names, contact addresses or any other sensitive data.
Customizations for global users
Note that all customizations made for a global user are transferred to all of the customer’s sites. Global users are therefore not suitable for special views, custom graphs or bookmarks, as these may contain sensitive, customer-specific data. You should therefore use global users only for exceptional cases and not for regular, everyday tasks.
5.5. Certificate management
The points mentioned in the previous chapter, such as notifications with contact groups or host tags, can only reveal information about the organizational structures of other customers.
The situation is different with the distribution of CA ('certificate authority') root certificates: If a CA certificate intended for Customer A were to be distributed to Customer B, there would be a risk that malicious employees at Customer A could carry out a machine-in-the-middle attack on the encrypted communication at Customer B. For this reason, CA certificates stored with the Trusted certificate authorities for SSL global setting are not transmitted to the remote sites.
The correct way to configure customer-specific CA certificates is to enter them in the site-specific global settings of the customer’s remote sites.
6. Differences of the components in detail
6.1. Setup interface
You can access a view for managing customers in Setup > Users > Customers.
When setting up the elements that can be assigned to customers, an additional Customer field is available.
These functions are described as examples in the chapter on configuration.
6.2. Monitor interface
Dashboard
New in the Main dashboard is the Customers dashlet, which is located to the left of the service problems:
When you select a customer, a view appears in which all of their hosts are listed. This table view therefore works like the All hosts view — with the difference that only specific customer’s elements are displayed in this case.
Sidebar
For the sidebar, in the central site there is the Customers snap-in, which works in the same way as the similar-looking Site status snap-in. Here you can display the status of the sites for the individual customers, and also by clicking on the status hide specific customers from, or show them in the view.
Building and filtering views
Of course, you can also use the filters and data sets as they are used for the dashlet and the snap-in for your own views. On the one hand, the Site filter has been extended for customizing views:
On the other hand, you can also build entirely new views based on one or all customers. To do this, select All customers as the data source:
