github/k3k
1
0
Fork 0
mirror of https://github.com/rancher/k3k.git synced 2026-08-18 20:07:06 +00:00
Code Issues Packages Projects Releases Wiki Activity

(docs) Remove ambiguity of virtual mode isolation (#1122)

Browse Source 
* Remove ambiguity of virtual mode isolation

Signed-off-by: galal-hussein <hussein.galal.ahmed.11@gmail.com>
This commit is contained in:
Hussein Galal
2026-08-06 12:25:57 +03:00
committed by GitHub
parent b7dc666748
commit 98cd3ee92e
2 changed files with 21 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/architecture.md
+19 -3
View File
@@ -73,11 +73,27 @@ This approach provides a clear and direct way to control the resources available
### Isolation and Security
The `virtual` mode offers strong isolation due to the dedicated K3s clusters deployed for each virtual cluster. Because each virtual cluster runs its own separate control plane and worker nodes, workloads are effectively isolated from each other and from the host cluster. This architecture minimizes the risk of one virtual cluster impacting others or the host cluster.
The `virtual` mode offers more isolation than `shared` mode due to the dedicated K3s clusters deployed for each virtual cluster. Because each virtual cluster runs its own separate control plane and worker nodes, workloads are effectively isolated from each other and from the host cluster. This architecture minimizes the risk of one virtual cluster impacting others or the host cluster.
Security in `virtual` mode benefits from the inherent isolation provided by the separate K3s clusters. However, standard Kubernetes security best practices still apply, and K3k emphasizes a layered security approach. While the K3s server pods often run with elevated privileges (due to the nature of their function, requiring access to system resources), K3k recommends minimizing these privileges whenever possible and adhering to the principle of least privilege. This can be achieved by carefully configuring the necessary capabilities instead of relying on full `privileged` mode. Further information on K3s security best practices can be found in the official K3s documentation: [https://docs.k3s.io/security](https://docs.k3s.io/security) (This link provides general security guidance, including discussions of capabilities and other relevant topics).
Currently, `virtual` mode runs the server and agent pods with a `Privileged` securityContext to allow the kubelet and other components to function properly. As a result of this drawback, any pod that is privileged inside a virtual cluster also holds full privileges on the real host node.
Currently security in virtual mode has a risk of privilege escalation as the server pods run with elevated privileges (due to the nature of their function, requiring access to system resources).
Pod Security Admission configured *inside* a virtual cluster is administered by the owner of that virtual cluster, who can relax or remove it. It restricts the workloads of that cluster; it does not protect the host cluster from the owner of the virtual cluster.
To close this gap, however, the server and agent pods can be run under a sandboxed runtime by setting `runtimeClassName` on the `Cluster` (or on a `VirtualClusterPolicy`, to apply it to every cluster in the bound Namespaces):
```yaml
apiVersion: k3k.io/v1beta1
kind: Cluster
metadata:
name: my-cluster
spec:
mode: virtual
runtimeClassName: kata-qemu
```
Runtimes such as [Kata Containers](./howtos/using-kata-containers.md), which runs each pod in a lightweight VM, or [Sysbox](https://github.com/nestybox/sysbox) provide a kernel or hardware boundary between the virtual cluster and the host node. Support for these runtimes is experimental; see the [Kata Containers how-to](./howtos/using-kata-containers.md) for a full setup walkthrough.
Beyond that, standard Kubernetes security best practices still apply, and K3k emphasizes a layered security approach. K3k recommends minimizing the privileges of the virtual cluster pods whenever possible and adhering to the principle of least privilege; `securityContext` and `podSecurityContext` on the `Cluster` can be used to override the defaults, keeping in mind that the nested kubelet and container runtime require most of these privileges to function. Further information on K3s security best practices can be found in the official K3s documentation: [https://docs.k3s.io/security](https://docs.k3s.io/security) (This link provides general security guidance, including discussions of capabilities and other relevant topics).
## K3k Components