01
Encrypted secrets management
Secret variables are encrypted with AES-256-GCM using unique nonces and versioned key rings, decrypted only in-memory when container cells spawn or builds run.
Security
Security enforced bythe Linux kernel, not just APIs.
Control plane permissions are only as strong as the underlying isolation. Hubfly space workloads are separated by Linux namespaces, capability restrictions, and seccomp filters — well below the application layer.
Project workflow01 / 03
01
SourceProject network
02
ControlRuntime control
03
ReleaseRelease path
Hubfly space projectNetwork · volumes · domains · team access
One project model
01
7
Linux namespaces per cell
PID, mount, network, UTS, IPC, user, cgroup
02
ALL
Capabilities dropped by default
13 safe capabilities restored explicitly
03
33+
Syscalls blocked
mount, pivot_root, ptrace, setns, kexec_load, reboot
04
1000000+
Host UID range for container root
Container UID 0 is unprivileged on the host
Defence in depth
Six isolation layers guarding every container.
We don't rely on a single security mechanism. Every layer assumes the layer above it has already been tested.
01
Seven isolated namespaces per cell
Every container cell runs in its own PID, mount, network, UTS, IPC, user, and cgroup namespace. Processes cannot view, signal, or communicate outside their own container boundary.
02
Unprivileged root UID remapping
Root UID inside a container maps to an unprivileged host UID range (1000000–1065535). A process breaking root inside a cell remains an unprivileged account on the host.
03
Minimal capability set
Linux capabilities are stripped down by default, leaving only thirteen operationally necessary privileges like `NET_BIND_SERVICE`, `CHOWN`, and `SETUID`.
04
Strict seccomp syscall filtering
A custom seccomp profile unconditionally blocks 33+ dangerous system calls including `mount`, `pivot_root`, `ptrace`, `setns`, and `reboot`.
05
Read-only system mounts
Critical host system paths like `/proc/sys` and `/sys` are mounted read-only inside container cells, preventing processes from modifying kernel parameters.
06
Enforced privilege restriction
`no_new_privileges` is enforced system-wide so setuid binaries inside containers cannot escalate beyond their assigned unprivileged host UID.
User namespaces
Container root is never host root.
This is a core security guarantee of our runtime. A process running as UID 0 inside its container cell remains an unprivileged user on the host node.
UID mapping
Inside the cell
uid 0 · root
Apparent root privileges strictly within container namespace
user namespace remap
On the host
uid 1000000+
Unprivileged host user owning zero host resources outside its cell
Container escape vulnerabilities attempt to turn internal root privileges into host root access. User namespace remapping breaks this escalation path: container root is mapped to an unprivileged account on the host kernel from the start.
Layered on top, Linux capabilities are stripped down by default, and seccomp filters block dangerous system calls required for escape attempts.
Containers run without a background Docker daemon. There is no long-lived privileged daemon socket that could be targeted or compromised.
Seccomp profile
Blocked system calls.
A sample of dangerous system calls blocked by our default seccomp profile. These calls are typically exploited to break container boundaries.
| Syscalls | Category | Why it is blocked |
|---|---|---|
| mount · umount2 | Filesystem manipulation | Prevents remounting host filesystems inside containers |
| pivot_root · chroot | Root filesystem changes | Blocks container root escape mechanisms |
| ptrace | Process tracing | Prevents inspecting or injecting into adjacent processes |
| setns · unshare | Namespace manipulation | Blocks breaking out of assigned namespace boundaries |
| kexec_load · reboot | Kernel and power control | Prevents containers from loading custom kernels or restarting host nodes |
mount · umount2
- Category
- Filesystem manipulation
- Why it is blocked
- Prevents remounting host filesystems inside containers
pivot_root · chroot
- Category
- Root filesystem changes
- Why it is blocked
- Blocks container root escape mechanisms
ptrace
- Category
- Process tracing
- Why it is blocked
- Prevents inspecting or injecting into adjacent processes
setns · unshare
- Category
- Namespace manipulation
- Why it is blocked
- Blocks breaking out of assigned namespace boundaries
kexec_load · reboot
- Category
- Kernel and power control
- Why it is blocked
- Prevents containers from loading custom kernels or restarting host nodes
Data and supply chain
Security across your deployment lifecycle.
02
Private networking by default
Containers start completely isolated from the internet until ports are deliberately mapped. Internal services communicate privately without firewall rules to manage.
03
Secure port forwarding
Access private services locally over an encrypted WebSocket connection authenticated by short-lived connect tokens — no public ports required.
04
Automated vulnerability scanning
Trivy and Govulncheck scan images on push, reporting severity levels, affected packages, current versions, and official patch fixes.
05
Build command allowlisting
Auto-generated build steps are validated against platform allowlists, preventing malicious repositories from executing arbitrary commands on build servers.
06
Audit logging
Sensitive organization operations log the user actor, target resource, IP address, user agent, API request ID, and timestamp.
Edge protection
Threat filtering before traffic hits your containers.
01
IP allow and deny lists
Block malicious IP ranges or restrict internal admin tools to your office network right at the edge proxy.
02
Request rate limiting
Protect authentication routes and heavy API endpoints from brute force attempts with configurable rate windows.
03
Automatic circuit breakers
Degrading backend services trigger circuit breakers returning 503s instantly, preventing widespread outage cascades.
04
Edge bot filtering
Identify and block automated scrapers and bots at the edge before they consume your container's compute budget.
Security
Need detailed security & compliance details?
Evaluating Hubfly space for strict security requirements? Reach out to our engineering team to review exact kernel controls, isolation benchmarks, and compliance specs.