Tenancy and Isolation
How tenant identity, namespace isolation and capacity boundaries are technically enforced.
gh0stcloud tenancy is not a convention-based model — it is technically enforced across four independent layers. A tenant structurally cannot access another tenant's resources, even if both run on the same node pool.
Isolation model
The four isolation layers
1. Identity boundary
Each tenant operates within a dedicated identity scope. Every portal and API request is verified against two independent conditions: valid authentication via OIDC, and confirmed membership in the correct tenant organisation. There are no endpoints accessible without a tenant context.
2. GitOps boundary
Changes to runtime resources are only possible through Git commits. Our provisioning system declaratively manages all cluster and tenant configuration from versioned code — no direct cluster access is possible for tenant users.
3. Runtime boundary
Each tenant namespace has dedicated resource boundaries enforced by admission policies. Network traffic between namespaces is denied by default. Resource consumption is capped at the contracted tier. Container workloads run under a restricted security profile that prohibits privilege escalation.
4. Secrets boundary
Tenant credentials and secrets are stored in an isolated area within our secrets authority. Secrets are automatically synchronised into the tenant namespace — cross-tenant access is structurally excluded at the authorization level.
Shared vs. dedicated capacity
| Model | Isolation | When appropriate |
|---|---|---|
| Shared pool | Namespace + policy (layers 1–4) | Standard for Starter and Growth |
| Dedicated bare-metal | Additionally physically separated node | Compliance requirements, full resource guarantee |
On shared pools, tenants run on the same compute nodes but with strict resource quotas and network policies. This is not a hypervisor model — isolation is Kubernetes-native with Cilium networking.
Offboarding
A standardised offboarding runbook delivers:
- Exported Kubernetes manifests of all tenant workloads
- Exported configurations and ConfigMaps
- Persistent volume snapshots (Longhorn)
- Policy context and RBAC documentation
Goal: a qualified team can reproduce the tenant state in a different Kubernetes environment.
Questions or ready to get started?
Talk to us