Skip to content
KubeCell logoKubeCell

Guides

Security and isolation

KubeCell gives every child cluster a real API server without giving tenants control of the host. Isolation is enforced by Kubernetes primitives on the host, plus a small admission layer that closes the obvious escalation paths.

Trust model

This is not strong-adversary multi-tenancy. Developer credentials are child-cluster admin kubeconfigs, and the network boundary assumes trusted or at least accountable tenants. Do not use KubeCell to host untrusted third-party code.

The five isolation layers

  1. Dedicated host namespace. Each child cluster maps to one host namespace with policy labels and annotations. Reflected Pods and PVCs land there, and nothing else does.
  2. ResourceQuota. The VirtualNodeClass entitlement becomes a hard quota on the host namespace. Requests and limits are both enforced, so a child cluster cannot overcommit the host.
  3. LimitRange. A default of 100m CPU and 256Mi memory applies to containers that declare nothing, which prevents platform sidecars in the child cluster from landing unschedulable.
  4. NetworkPolicy. Cross-namespace traffic is denied by default. Only the child API server path and required platform flows are allowed.
  5. Admission rejection. Privileged containers, host namespaces, and hostPath volumes are rejected in tenant workloads before the host ever schedules them.
quota.yaml
apiVersion: v1kind: ResourceQuotametadata:  name: kubecell-<vc>-quota  namespace: <vc>-nsspec:  hard:    requests.cpu: "4"    limits.cpu: "4"    requests.memory: 8Gi    limits.memory: 8Gi    requests.huawei.com/Ascend910: "2"    limits.huawei.com/Ascend910: "2"
admission.txt
# What the host admission layer rejects in tenant workloads#   - privileged containers#   - host namespaces (hostNetwork, hostPID, hostIPC)#   - hostPath volumes (with a replacement hint pointing at the storage class)#   - host device access outside the declared extended resources## What it does not do: inspect container images, enforce vendor runtimes,# or act as an adversarial sandbox. See "Trust model" below.

Management-plane boundary

The controller is intentionally weak by design. It can write OCM ManifestWork objects and read hosts through the OCM cluster proxy. It does not hold host kubeconfigs and does not open connections to host APIs.

  • Every host-side change is a declarative work object, which makes changes reviewable and retries idempotent.
  • A compromised controller can disrupt the fleet, but it cannot silently edit host state without leaving ManifestWork artifacts.
  • Host onboarding requires a manual clusteradm accept. KubeCell never auto-approves a ManagedCluster.

Accelerator isolation

  • Extended resources are allocated as whole cards: request equals limit, integer values. Sharing one accelerator between child clusters is not supported.
  • Observed allocatable is the source of truth. A Cell declaration that exceeds observed capacity produces a CapabilityMismatch condition instead of oversubscription.
  • KubeCell does not manage vendor runtimes, CDI, or Device Plugin health. Those remain host platform responsibilities, and diagnostics go through host Pod status and logs.

Credentials

  • Each VirtualCluster always publishes an admin kubeconfig to a management-plane Secret. There is no credential-less mode.
  • Treat the Secret as cluster-admin material for the child cluster. Store it in your secret manager and use mode 600 for files.
  • Revocation is deletion: removing the VirtualCluster removes the child API and its credentials. Rotate by recreating the child cluster.

Storage and data

  • Child volumes live on host TopoLVM logical volumes. Deleting a child cluster does not automatically destroy data under the Retain policy.
  • Reclaim is a deliberate operator action (lvremove for cluster-created volumes only). Never remove the volume group.
  • hostPath is rejected because it would let a child workload read host data outside its namespace boundary.

Reporting a security issue

Do not open a public issue for a suspected vulnerability. Contact the maintainers through the repository's security reporting channel and include reproduction steps, the affected version, and the observed versus expected behavior.

See also: technical principles for the control flow and day-2 operations for credential handling routines.