Tenancy model

Before you start

• You understand that Kestrel is a shared multi-tenant Kubernetes cluster (see What is Kestrel?).
• You have a working mental model of Kubernetes Namespace as a scoping boundary. If not, the Namespace glossary entry is a one-sentence refresher.

What a Tenant is

A Kestrel Tenant is a Capsule Tenant custom resource. Capsule is the operator that enforces the multi-tenancy rules on every Kubernetes admission request — namespace prefixing, network isolation, shared quota, and service-type restrictions all flow from this one resource.

One tenant on Kestrel maps to exactly one Alliance Cloud RAP — a Resource Allocation Project held by a PI at a CFI-eligible Canadian institution. The tenant name matches the Cloud RAP’s Alliance LDAP POSIX group name; tenant owners are identified by that group name via the Identity chain. RAP group name conventions (def-profname / crg-profname-xx / cpp-profname-xx) are documented in the Cloud RAP glossary entry.

Tenant creation is an RCS-operated procedure in response to a Cloud RAP — when a PI holds a new Cloud RAP on Arbutus, RCS provisions the corresponding Capsule Tenant, and when the PI’s RAP is retired the tenant is torn down. See Requesting access for the PI’s request flow and for adding individual users to an existing tenant. Tenants cannot self-serve the Tenant resource itself — it is RCS-managed, and every new tenant is a small platform-team ritual rather than an API call you make.

Who owns a tenant

Every tenant is owned by the PI holding the Cloud RAP that backs it. The PI is any faculty member at a CFI-eligible Canadian institution — UVic is one of many Canadian institutions whose faculty can hold RAPs on Arbutus, not a restriction on who can own a tenant. Inside the cluster, the owning identity is the Alliance LDAP POSIX group that matches the Cloud RAP group name; the kube-apiserver re-prefixes it with oidc: when it validates your identity token (see Identity chain), so the Capsule Tenant resource lists oidc:<rap-group-name> as an owner group — e.g. oidc:crg-profname-01 for a RAC Cloud RAP.

Tenant membership is managed in CCDB, not in Keycloak. The PI adds or removes users from the Cloud RAP at ccdb.alliancecan.ca; Alliance LDAP propagates the change; the next kubelogin login reflects the new membership. Keycloak reads Alliance LDAP on every authentication — there is no Kestrel-side group store to update.

Cloud RAPs do not auto-add sponsored users

Alliance HPC RAPs (rrg-*, rpp-*) automatically include all of a PI’s sponsored users. Cloud RAPs do not. The PI must explicitly add each user to the Cloud RAP in CCDB — this is the most common “why can’t I access my tenant?” question on Kestrel. CCDB-level issues (account approval, missing role, RAP membership) go to accounts@tech.alliancecan.ca; Kestrel-specific issues still go through RCS. See Requesting access for the end-to-end flow.

The namespace prefix rule

Every Namespace inside a tenant must be named <tenant>-*. If your tenant is demo, a namespace called explorer is rejected at admission time; demo-explorer is allowed. The prefix is the tenant name — not a hyphen-separated label — and anything under it is yours.

This is enforced by Capsule’s forceTenantPrefix: true setting on the shipped tenant chart. The rule is admission-layer: even a cluster-admin running from a CI pipeline hits the same error if the manifest violates it.

Blocked by: Capsule admission webhook

Any namespace that does not start with your tenant name is rejected at kubectl apply time with a Capsule admission error. Use instead: always prefix your namespace with your tenant name. See Known limitations for the full rule.

Who creates and deletes namespaces

Tenant owners can create namespaces under their prefix directly — either by hand from a workstation, or by letting ArgoCD reconcile a Namespace manifest out of your app-of-apps repo. Both paths hit the same Capsule admission rule, so a correctly-prefixed name works from either direction and a badly-prefixed name fails from either direction.

Tenant teardown — deleting the Tenant resource itself — is an RCS procedure. Capsule’s preventDeletion: true setting on the tenant chart deliberately prevents accidental teardown so that one wrong argocd command cannot evaporate a research team’s entire scope. See Known limitations for the rationale and the path for intentional teardown when a project ends.

Shared quota across namespaces

Every namespace a tenant owns pulls from the same Capsule ResourcePool — splitting work across namespaces is an organization choice, not a quota-isolation choice. A runaway Job in demo-experiments can exhaust the CPU or memory budget for demo-prod even though the namespaces look separate. The isolation you get from a second namespace is scoping and RBAC, not resource accounting.

See Resource pools and quotas for the full model and the tier numbers (sandbox, standard, premium, custom), and the Glossary for the one-sentence version.