Isolation

Every Kiste is a separate microVM with its own kernel. It is not a container that shares a kernel with its neighbours. The layers are described below from the inside out. Each one is meant to hold even if the one inside it fails.

A microVM per Kiste

• Own kernel, hardware virtualisation. Each Kiste runs in a Firecracker microVM on KVM. Firecracker is the virtual machine monitor built for multi-tenant serverless platforms. It emulates only a handful of devices, which keeps the attack surface between a guest and the host small.
• Own disk, own identity. Every Kiste has its own persistent disk, SSH host key, network address and management credentials. Nothing is shared between two Kisten except the read-only base image they were cloned from.
• No shared desktop process. The desktop of a Kiste is captured inside that Kiste and encoded on the host by a separate, unprivileged process. The guest opens no network port for the stream and holds no secret for it.

A jail around every microVM

Firecracker itself does not run with the server's privileges. Every Kiste is started only through Firecracker's jailer; there is no path that starts a microVM without it. The jailer gives each Kiste:

• its own user and group, so the processes of two Kisten cannot signal or read each other,
• its own file system root that contains only what that Kiste needs,
• its own process namespace and its own network device,
• its own resource group with limits on CPU, memory (no swap), processes and open files, so one Kiste cannot starve the others or the server,
• Firecracker's built-in system-call filters.

A confined service on the host

The service that manages Kisten on the compute server also runs confined. It has a fixed list of devices and only the privileges it needs to set up jails and networking. It runs under a mandatory access control profile and a system-call filter, and it cannot see the rest of the host's process or resource hierarchy. The part that processes the video and audio coming from a Kiste runs as yet another separate process, with its own user, no privileges and its own system-call filter. Data that originates in a guest is handled with the least privilege the server has.

Nested virtualisation is switched off on the compute server, so a guest cannot start its own hypervisor.

Between your account and everyone else's

• Every API request is tied to the account that made it. Every Kiste, command, snapshot, environment, image, published service and log query is looked up within that account. Code review and live tests with two separate test accounts treat a cross-account path as a release-blocking defect.
• Published ports run under a separate domain, kiste.stream. A web app you publish from a Kiste therefore cannot read cookies or storage of kiste.run, even though it runs in the same browser.
• Desktop links only work for the signed-in owner of the Kiste. A leaked desktop link is useless without your session.

What Kiste staff can reach

Kiste is run by one operator. There is no operator back door into Kisten.

• SSH to a Kiste needs one of your device keys (Devices). Each computer you sign in from registers its own key, and you can revoke a computer at any time.
• The operator does not access the contents of your Kisten. Contents are accessed only on your documented instruction (for example a support request you make) or when the law requires it. The data processing agreement makes this binding.
• Off-site checkpoints are encrypted with your account's key before they leave the server. The storage provider holds no key (see Encryption).

Limits you should know about