Skip to main content
Version: 0.1.0-rc.5

Decision matrix

Isolation pillars

Isolation pillars.
PillarWhat it protectsPrimary mechanism
Identity separationProvisioning and workload management do not share one broad credential.The provisioner grants access, while the controller uses tenant-scoped access without minting it.
Admission guardrailsUnsafe RBAC writes and operator-object drift are blocked at the API boundary.Validating admission policies constrain names, subjects, and managed-object mutation patterns.
Network and namespace hardeningCross-tenant traffic and insecure sidecar drift are reduced by default.Default-deny NetworkPolicy and Restricted Pod Security labels apply at onboarding time.

Diagram

Tenant introduction flow

The provisioner writes the access grant into the target namespace, but the ongoing controller uses that access without being able to mint or broaden it freely.

Onboarding models

Decision matrix

Choose the governance model

Choose the governance model.
ModelWho creates the requestPrimary constraintWhy you would use it
Centralized onboardingA platform-admin workflow creates the request in the operator namespace.Normal tenant users must not be able to write onboarding requests there.Use this when quotas, guardrails, or namespace vending are controlled centrally.
Task versus model

This page explains the isolation contract. Use Onboard the target namespace when you need the concrete onboarding workflow and field-level configuration.

What the model guarantees

Reference table

Operational guarantees

Operational guarantees.
GuaranteeWhat it meansPrimary control
No cross-tenant Secret browsingThe controller should not treat tenant Secrets as generic cluster inventory.Secret access is name-scoped, role-scoped, and guarded by admission policy.
No all-powerful long-running operator credentialThe component that grants access does not also reconcile every tenant workload with the same credential.Provisioner/controller identity split.
Namespace-level runtime baselineTenant namespaces start from Restricted pod-security enforcement and default network isolation.Provisioner-owned namespace labels and network-policy defaults.

Assumptions and residual risk

Reference table

Assumptions you still need to own

Assumptions you still need to own.
AssumptionWhy it mattersWhat to do
The surrounding cluster is trustworthyNode compromise, cluster-admin access, or hostile CNI behavior are outside what namespace isolation can solve.Pair the operator model with normal cluster hardening, audit, and node-security controls.
Shared external systems are partitioned appropriatelyObject storage, PKI, and KMS systems can still become cross-tenant blast-radius points if configured broadly.Separate identities, prefixes, or trust roots per tenant or per environment where required.

Continue tenant isolation

Prerelease documentation

This version tracks a prerelease build. Features and behavior may change before the next stable release.

Was this page helpful?

Use Needs work to open a structured GitHub issue for this page. The Yes button only acknowledges the signal locally.