With KVM Multi-Tenant, multiple customers share the same hardware, and a technician switches between tenants on a daily basis. A single incorrectly assigned permission is enough for someone to view another customer’s console. This subtle detail determines whether the separation between customers is effective or exists only on paper.
Redfish manages permissions for KVM Multi-Tenant using fixed roles such as Administrator, Operator, and ReadOnly, as well as fine-grained privileges. OpenBMC implements this using privilege groups such as priv-admin, priv-operator, and priv-user. Older IPMI implementations do not support this level of granularity and therefore require an additional management layer above the BMC when true tenant isolation is required.
KVM Multi-Tenant: Roles in Redfish and OpenBMC
Redfish defines a role-based access control system with three basic roles: Administrator, for full access including firmware and configuration; Operator, for day-to-day operations without the ability to modify the basic configuration; and ReadOnly, for monitoring purposes only (DMTF, Redfish Specification). Individual privileges can also be assigned with fine granularity, such as the right to execute power commands without the ability to create user accounts. This combination of a base role and individual privileges allows for configurations that go beyond the three standard roles—for example, an account that can use the console and power functions but cannot change network settings.
OpenBMC, the widely used open-source firmware for BMCs, implements this model using privilege groups: priv-admin, priv-operator, and priv-user (OpenBMC Documentation). Each user belongs to exactly one group, and each group determines which Redfish endpoints are accessible. IPMI does not support this distinction in its basic form and uses passwords that, in many implementations, are stored in plain text. Redfish, on the other hand, supports modern authentication methods, including certificates—a difference that should be a deciding factor when choosing a protocol for multi-tenant environments.
| Characteristic | IPMI | Redfish |
|---|---|---|
| Tread depth | Broadly speaking, usually an admin or user | Fine-Grained Control Over Roles and Privileges |
| Password Storage | In plain text in many implementations | Modern Hashing Algorithms |
| Certificates | Not planned | Supported |
| Logging | Varies by manufacturer; often rudimentary | Organized by Event Log and Sessions |
Another practical issue concerns concurrent sessions. Some BMCs allow only one active console session per server, while others allow multiple concurrent sessions with access to the same screen. If multiple technicians share access, it’s worth taking a look at the Redfish Session Service configuration, as it determines how many concurrent sessions an account is allowed to open and how long an inactive session remains open before it automatically ends.
Administrator, Operator, and ReadOnly make up the Redfish role model, which can be further customized using individual privileges.
DMTF, Redfish Specification
A Role Model for Service Providers and System Integrators
Service providers who support multiple customers on shared hardware should limit technician accounts as strictly as the specific contract allows. For basic troubleshooting, power commands and console access to a customer’s defined systems are sufficient. Firmware privileges or access to other clients are not included in this scope. A technician who handles only issues for a single client needs access only to that client’s systems, not to the system provider’s entire fleet.
In practice, time-limited accounts function based on an expiration date that is stored directly with the account, not through a separate reminder in an administrator’s calendar. When an external technician’s assignment ends at a specified time, the associated account deactivates automatically, regardless of whether anyone remembers to lock it manually. This automation closes one of the most common security gaps in practice: a forgotten account from a long-completed project that still has valid login credentials months later.
Having separate accounts for each person instead of a shared master account is not optional. A master account makes it impossible to assign access retrospectively. If multiple technicians share a password and something goes wrong on a server, it is impossible to determine afterward who was actually logged in. Separate accounts with individual login credentials solve this problem and also provide the basis for a later analysis of the access logs.
Accesses and configuration changes at the BMC level must be logged at all times, regardless of the protocol used. Without logging, it is impossible to determine who changed a setting in the event of a dispute. This logging complements the network architecture described in the article Isolating the Management Network: Redundant Architecture for Emergencies as described. A separate management network is one prerequisite; the role model for individual accounts is added as a second layer on top of that.
Where Older BMC Generations Reach Their Limits with KVM Multi-Tenant
Not all hardware in the field supports the fine-grained Redfish model. Many older generations of BMC systems only support coarse-grained roles—often no more than an administrator account and a single restricted account, with no further differentiation. In practice, this is evident in server generations that were procured before the widespread adoption of Redfish and whose BMC firmware cannot be significantly expanded, even through an update.
Those who operate a mixed fleet of old and new hardware therefore do not rely solely on the role management of the respective BMC. This additional layer ensures consistency across hardware generations—something individual BMCs naturally cannot provide—and it unifies the view for technicians who switch between old and new servers on a daily basis. When procuring new hardware, you can take this into account during the selection process and specifically ask for Redfish support with fine-grained roles, rather than discovering the problem years later during operation.
Tailor roles to each customer and technician
All it takes is one incorrectly assigned permission for a technician to view another customer's console. A role model with tightly defined permissions per account addresses this exact issue.
Frequently Asked Questions
How do you separate customers on shared hardware?
Through tightly defined roles for each customer and system: access only to the agreed-upon servers, no firmware privileges, and no visibility into other tenants. Redfish and OpenBMC implement this separation through roles such as "Operator" and privilege groups such as "priv-operator"; on older hardware, a central management layer handles this task.
Does every technician need their own account?
Yes. A shared collective account prevents any retroactive assignment if it becomes necessary later to determine who made a change. Separate accounts for each person take a little more time to set up, but they pay off every time you review the access logs.
How long should access logs be retained?
There is no one-size-fits-all answer to this question. It makes sense to establish a retention period based on your own incident handling process, one that is long enough to allow you to trace incidents identified retroactively. Your own data protection policy and, depending on the client, contractual requirements set the binding framework for this.
torck manages several teams simultaneously within its own infrastructure—in Maxhütte-Haidhof, Vienna, and Rabat—and has consistently organized its role management by task from the very beginning. It is precisely this role model that is embedded in KVM Fleet, when customers manage multiple technicians or multiple clients on a shared platform. The contracting party in this case is the German company torck GmbH—a direct contract rather than a chain of subcontractors. Anyone who would like to have their own authorization model reviewed can schedule a product demo or an initial consultation, with no obligation.
German 
English 
French