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 currently managed by RCS in Keycloak: staff add and remove users in the tenant’s Keycloak group on request (open a ticket). A CCDB account is the prerequisite — Keycloak’s user store federates from the Alliance (CCDB) LDAP, and users are never created directly in Keycloak. The next kubelogin login after a change reflects the new membership. PI self-service via the Cloud RAP in CCDB is planned but not live yet. See Managing membership.

Tenant membership is not automatic

Being sponsored under a PI in CCDB — or listed on the Cloud RAP — does not by itself grant Kestrel access: RCS must add each user to the tenant’s Keycloak group. This is the most common “why can’t I access my tenant?” question on Kestrel. CCDB-level issues (account approval, missing role) go to accounts@tech.alliancecan.ca; membership requests and Kestrel-specific issues 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 def-profname, a namespace called explorer is rejected at admission time; def-profname-explorer is allowed. The namespace name must begin with your full tenant name followed by a hyphen (<tenant>-); any label after that is yours.

This is enforced by Capsule’s forceTenantPrefix: true setting on the shipped tenant chart. The rule is admission-layer: every request made with tenant credentials — including CI pipelines — 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 def-profname-experiments can exhaust the CPU or memory budget for def-profname-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.