Node Security
A node runs code you don't control: renters start their own containers on it. We isolate those containers from your network and from the host, but no isolation is perfect. Treat the node as a dedicated machine on a separate network, with nothing on it you can't afford to lose or leak.
How containers are isolated on the network
The installer sets up a firewall service, octa-netguard, and a Docker network of its own, octa (bridge octa0, subnet 172.31.240.0/20). The rules apply to every Docker bridge on the machine, not just octa, and are restored automatically every time Docker restarts.
A renter's container | Allowed |
|---|---|
Reaching the internet | Yes |
Accepting connections on the ports published for the rental | Yes |
Reaching your local network (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) | No |
Reaching the host itself (SSH, the agent's web UI, any service on the host) | No |
Reaching other containers on the same machine | No |
Reaching link-local addresses, including cloud metadata (169.254.169.254) | No |
Reaching carrier-grade NAT, multicast and other reserved ranges | No |
Reaching private and link-local IPv6 addresses | No |
To check that the rules are in place:
systemctl status octa-netguard
sudo octa-netguard showWhat isolation does not cover
- Containers are not virtual machines. A container shares the kernel with the host. A kernel or Docker vulnerability can let a container escape to the host, and from there to anything the host can reach.
- The renter is root inside the container and has full access to the GPU and the disk space given to the rental.
- Outgoing traffic leaves from your IP address. Whatever a renter does on the internet comes from your connection.
- Your own idle jobs are not restricted the same way. A job with privileged mode or host networking, and its start and stop commands, run with full access to the host and your network.
Keep the node on a separate network
The firewall stops containers from reaching your network. It does not help if the host itself is compromised: then the attacker is on whatever network the host is on. Keep the node away from your main network so that a compromised node can't reach your other devices.
- Best: a separate VLAN on a managed switch, with a router rule that lets the VLAN reach the internet only, not your main network.
- Simpler: the router's guest network, or a separate router behind your main one, with no access to the main network.
- Avoid: the node in the same network as your PCs, NAS, cameras, smart home devices or work laptop.
Several nodes can share one VLAN. If one node is compromised, the others in the same VLAN are reachable from it, so a VLAN per node is safer when your equipment allows it.
Security checklist
Data on the node
The node is a dedicated machine, not your personal or work computer.
No personal files, documents or photos on it.
No crypto wallets, seed phrases or private keys.
No passwords, password managers or saved browser sessions.
No SSH keys, API tokens or cloud credentials that give access to other systems.
No network drives (SMB, NFS) or cloud storage mounted.
The node is not joined to a company domain and has no work VPN.
Network
The node is on its own VLAN or guest network, without access to your main network.
The router forwards only the node's service port range, nothing else.
The node is not in the router's DMZ.
SSH is not reachable from the internet, or uses keys only, with password login turned off.
Remote management (IPMI, BMC, Intel AMT) is turned off or on a separate management network.
Your internet provider allows this use of your connection.
System
The operating system, the kernel, Docker and the GPU driver are kept up to date: updates close container escape bugs.
octa-netguard is running and is not turned off.
You don't add your own firewall rules to the DOCKER-USER chain or remove the OCTA-GUARD chains.
No other Docker workloads run on the node, especially with --network host or --privileged.
BIOS/UEFI is protected with a password, and the machine is physically secured.
Account and node identity
The account in the dashboard has a strong, unique password.
Enrollment keys are never shared: anyone with a key can register machines to your account. Revoke a key you no longer need.
The node's identity key (/home/octa/osn/osn.key) is not copied or shared: it is how the platform recognizes your node.
Idle jobs
Idle jobs use only images you trust, from their official source.
Privileged mode and host networking are turned on only when the job really needs them.
Start and stop commands contain nothing you wouldn't run as root yourself.
If you suspect the node is compromised
- Disconnect the node from the network.
- Change the password of your account in the cube and of any service the node had access to.
- Reinstall the operating system from scratch, then install the agent again with a new enrollment key.
- Check the other devices on the same network, especially if the node was not on its own VLAN.