> Documentation index: https://docs.kiste.run/llms.txt, a list of every page in this documentation.

# Isolation

> How each Kiste is kept apart from other Kisten, from the compute server and from the people who run Kiste.

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](https://firecracker-microvm.github.io/) 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](https://docs.kiste.run/ssh/devices.md)). 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](https://kiste.run/dpa) 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](https://docs.kiste.run/security/encryption.md)).

## Limits you should know about

> **Warning:** What isolation does not cover today
>
> - Kiste currently runs on a **single compute server**. Your Kisten share that server with other
>   accounts. They are isolated by the layers above, but a vulnerability in KVM or Firecracker
>   itself would cross that boundary. We follow Firecracker and kernel security releases and patch
>   them as a priority.
> - Kisten share the server's disk bandwidth. A neighbour that writes heavily can slow your disk
>   down. It cannot read your data.
> - No external penetration test has been done yet. All security reviews so far are internal (see
>   [Compliance](https://docs.kiste.run/security/compliance.md)).

## Related topics

- [Security and trust](https://docs.kiste.run/security.md)
- [Network](https://docs.kiste.run/security/network.md)
- [Encryption](https://docs.kiste.run/security/encryption.md)
- [Supply chain and updates](https://docs.kiste.run/security/supply-chain.md)
- [Data location](https://docs.kiste.run/security/data-location.md)
- [Subprocessors](https://docs.kiste.run/security/subprocessors.md)
- [Logging and retention](https://docs.kiste.run/security/logging-retention.md)
- [Export and deletion](https://docs.kiste.run/security/account-data.md)
- [Incidents and status](https://docs.kiste.run/security/incidents-status.md)
- [Vulnerability disclosure](https://docs.kiste.run/security/disclosure.md)
- [Compliance](https://docs.kiste.run/security/compliance.md)
- Previous: [Security and trust](https://docs.kiste.run/security.md)
- Next: [Network](https://docs.kiste.run/security/network.md)