Overview
Running other people's code on your infrastructure is the core job of a PaaS, and the core security challenge. Lucity takes a defense-in-depth approach: multiple independent layers of isolation, each one meaningful on its own.
Threat Model
Lucity runs untrusted user code in two places:
- Build time: source code is compiled into container images via BuildKit. User-provided build commands (
RUNinstructions) execute on the BuildKit daemon pod. - Runtime: user containers run as Kubernetes workloads in isolated namespaces.
In both cases, the goal is the same: a compromised or malicious workload should not be able to reach platform components, other tenants' workloads, or the Kubernetes control plane.
Defense Layers
| Layer | What it protects | How |
|---|---|---|
| Build isolation | Platform from builds | Builds run in lucity-builds, credentials kept off BuildKit filesystem |
| Network policies | East-west traffic | Deny-all default, selective egress allowlists per namespace |
| Pod security | Host from containers | Non-root, dropped capabilities, seccomp RuntimeDefault |
| Registry auth | Image integrity | Authenticated push (builder) and pull (reader), no anonymous access |
What's Not in Scope
Lucity does not attempt to sandbox the Kubernetes control plane itself. If you're running a hostile multi-tenant environment where tenants actively try to escape containers, you'll want additional isolation at the node level (dedicated node pools, gVisor, or Kata Containers). Lucity's security model assumes tenants are generally cooperative but potentially careless, not actively adversarial.
For most teams running their own workloads across multiple projects and environments, the isolation described in this section is appropriate and well beyond what most PaaS platforms offer.