Tenant isolation¶
RG enforces tenant isolation where it actually matters: at the query, audit, and resource-allocation layers, not in the UI. An organization can only ever reach its own resources, and a request that reaches across tenants returns "not found" rather than "forbidden", so a caller cannot even confirm that another tenant's resource exists. Isolation is a property of data access, not a screen that hides things.
Enforced below the UI¶
Hiding resources in the interface is not isolation — it leaves the data reachable to anyone who bypasses the UI. RG enforces separation at the layers that serve data. At the query layer, every lookup is scoped to the caller's tenant, so a query can only return that tenant's rows. At the resource-allocation layer, allocations — tunnel endpoints, identifiers, capacity — are partitioned by tenant, so one tenant's resources are never drawn from or visible in another's pool. At the audit layer, records are tenant-scoped, so an organization sees only its own audit. Because enforcement lives beneath every access path, there is no route — API, tool, or UI — that returns another tenant's data, regardless of how a caller constructs the request.
Enumeration-resistant "not found"¶
A cross-tenant request in RG returns "not found", never "forbidden". The distinction is a deliberate defense: "forbidden" confirms that a resource exists and is merely off-limits, which lets an attacker enumerate valid identifiers by watching which ones return "forbidden" versus "not found". By returning "not found" uniformly for anything outside the caller's tenant — whether it truly doesn't exist or simply belongs to someone else — the platform reveals nothing about other tenants' inventory. A caller cannot tell an absent identifier from one owned by another organization, so probing yields no map of what exists. This turns isolation from a visibility rule into an information-theoretic one.
What shared-cluster tenancy guarantees¶
On a shared cluster, multiple tenants coexist with these guarantees enforced per request: each tenant's devices, bridges, configuration, allocations, and audit are reachable only by that tenant, and cross-tenant access is indistinguishable from nonexistence. Combined with two-tier RBAC, a shared cluster lets a provider host many customers while giving each customer authority over only its own fleet, and giving each customer's users no signal that other customers are present. The isolation guarantees do not depend on how many tenants share the cluster or on careful UI configuration — they hold at the query, allocation, and audit layers for every tenant on the cluster.
When to choose a private cluster¶
Shared-cluster isolation is strong, but some requirements call for physical separation rather than enforced logical separation. Choose a private cluster when a contract, regulation, or security policy mandates that a tenant's workloads run on dedicated infrastructure; when data-residency rules require a specific location or operator-controlled environment; or when an operator wants an air-gapped deployment, which is inherently single-tenant. A private cluster uses the same identity, RBAC, and isolation model as a shared one — the difference is that it serves exactly one tenant, so separation is guaranteed by dedication as well as by enforcement. The choice is driven by external mandate, not by any weakness in shared-cluster isolation.