Self-service concepts
Tenants, quotas, plans, catalogue images and servers of a multi-tenant Kyvernon cloud.
Kyvernon can run a multi-tenant cloud: customers (tenants) get their own part of the inventory, a quota, and an API to order and manage servers. A self-service portal drives it as a service principal; operators manage it in the web console under Tenants, VM plans and Image catalogue and with the kyvernon CLI.
Concepts
- Tenant: a customer. Creating one makes a folder
Tenants/<name>in every datacenter and a resource group<name>(called resource pool in vSphere) in every cluster. Its users see and change only what is in there; everything else is invisible to them, on every API (REST, gRPC, vSphere SOAP and REST facades, console, backup). - Quota per tenant: VMs, vCPUs, memory (MiB), disk (GiB), public IPv4 addresses, snapshots, traffic per month. Empty is unlimited. A request that would go over the quota is refused with
error.quota.exceeded, which names the resource, the limit and the current use. - Plan: a size class (vCPUs, memory, disk, traffic, IPv4, IPv6) servers are ordered by.
- Catalogue image: a template VM marked for the catalogue, with its OS, minimum disk and how it is personalised (cloud-init with SSH keys and password, or no credentials at all).
- Server: a tenant VM made from a plan and a catalogue image.
States of a tenant
A tenant is active, suspended or closed. Suspending shuts the virtual machines down and makes the users read-only; power-on and the console are refused until the tenant is resumed. Closing powers the virtual machines off at once and destroys them with their disks after a grace period; the users can no longer sign in.
Interfaces
The functions are available in the REST API (tags tenants, plans, servers), in the CLI (kyvernon tenants, plans, catalogue, servers) and in the gRPC service TenantService, whose bodies are JSON in the shape of the REST API. The console shows the operator side. The users of a tenant have roles that apply to the tenant's folder and resource group only: admin, user and read-only. The privileges that a portal needs are in the built-in role Tenant service principal.
Related tasks
Version 0.1. Last changed: 2026-11-13