How we isolate tenants at the kernel level

The problem with soft boundaries

Plain containers on a shared kernel are a packaging format, not a security boundary. By default, every container on a host shares the same kernel attack surface, the same scheduler and the same IO queues. If a tenant finds a kernel vulnerability — or simply runs a fork bomb — the blast radius is the entire machine, including every other customer on it.

Noisy neighbours are the everyday version of the same failure. Without enforced limits, one tenant's batch job can steal CPU cycles, saturate disk IO and evict another tenant's pages from memory. Hostile multi-tenancy demands boundaries the kernel enforces, not conventions a well-behaved workload happens to respect.

Namespaces, cgroups and seccomp

Every tenant workload on Anested Cloud gets its own PID, network and mount namespaces. Processes in one tenant literally cannot see, signal or trace processes in another; each workload sees its own private view of the filesystem and its own network stack. This is enforced by the Linux kernel on every syscall, not by a policy engine that can be misconfigured.

On top of namespaces we layer cgroup v2 resource control and seccomp syscall filtering. Quotas cap CPU time, memory and block IO per tenant, so a runaway process throttles itself instead of the host. Seccomp profiles reject syscalls a workload has no business making — cutting off entire classes of kernel exploits before they reach vulnerable code paths.

• Dedicated network namespace with its own virtual interface and firewall rules
• cgroup v2 quotas for CPU, memory and block IO
• seccomp profiles that whitelist only the syscalls a workload needs
• Read-only root filesystems with explicit writable mounts

Network isolation per tenant

Each tenant lives on its own private virtual network. Firewall rules are generated per tenant and default to deny: there is no route between one tenant's workloads and another's, so cross-tenant east-west traffic is impossible by construction. Scanning your neighbour's ports from inside an Anested VPS doesn't return closed ports — the packets never leave your network namespace.

Public traffic enters through the edge proxy and nowhere else. TLS terminates at the edge, requests are routed to exactly one tenant's network, and internal services never accept connections from outside their own segment. The result is a topology where the only reachable surface is the one you deliberately exposed.

What this means for databases

The same walls apply to every managed PostgreSQL, MongoDB and MySQL database we run. Each database instance is confined by its own namespaces, cgroup v2 limits and seccomp profile, so one tenant's slow query or runaway index build can't starve another tenant's database of CPU, memory or IO. Your p99 latency is a function of your workload, not your neighbour's.

Connection strings are scoped per database and only resolve inside the owning tenant's network. Even a leaked credential is useless from another tenant's segment, because the packets simply can't get there. Isolation at the kernel and network layers means database access control isn't your last line of defense — it's one of several.

Defense in depth, by default

No single layer is trusted to be perfect. Hosts are patched on a rolling schedule with live migration where possible, kernels are kept current against known CVEs, and every layer is monitored for anomalies — from unexpected syscall denials to cross-namespace traffic that should never exist. Every internal component runs with the least privilege it needs, so a compromise of one service doesn't cascade.

None of this is an enterprise add-on. Kernel-level isolation, per-tenant networking and resource quotas apply to every workload on Anested Cloud — including the free tier. Security that depends on your billing plan isn't security; it's a pricing page.