A Firewall Between Ports Is Not a Host Boundary

The website answers on 443, the VPN answers on 1194, the firewall allows exactly those two, and the review passes. Nothing in that sequence asked what the web worker can read or which files it can rewrite. A compromised worker does not need an open port if it can reach a control socket or a writable config directory. The boundary is authority, and listeners are only the part that is easy to see.

A separate service name is a label; a separate identity is a security property.

Count the Worker's Authority, Not the Ports

Start with the runtime user, its groups, its capabilities and its filesystem view. A service account that happens to belong to a VPN group can read key material without any port being open. Writable mounts are the other half: uploads and caches should sit far from policy files and secrets, and an unnecessarily shared writable directory defeats tidy naming. Check the process that would perform the operation, because a privileged parent and unprivileged workers do not share one authority.

A VPN key being readable during daemon startup does not mean the web worker needs it. Separate the read the daemon performs from the access the application is granted.

Sockets That Grant More Than They Look

Some endpoints are administrative APIs wearing the costume of a metrics feed. The VPN's management interface can change sessions, disconnect clients and read state. A container runtime socket is broader still: access to it is effectively host control, far beyond what a web application needs. Neither belongs in an ordinary application's mount set, and neither appears when you count listening ports.

Binding a management listener to a local address is a start, not a complete restriction, because every ingress path to that address still matters. Permit only the intended sources and interfaces.

Containers Share a Kernel

Containers add process, filesystem and network boundaries, and they share one kernel with the host. That makes capability choices, host mounts and daemon access decisive: mounting host secrets or granting privileged runtime control erases the boundary the container label suggests. Separate VMs do give separate guest kernels, while the hypervisor, administrative identities, storage and backups remain shared. Choose the boundary whose configuration and updates have a named owner.

A more elaborate arrangement nobody maintains is worse than a simple one that is actually reviewed.

Test the Denial, Then the Service

Use approved checks under the worker's real context to confirm it cannot modify VPN policy, read unnecessary secrets or touch the management interface. A successful read as administrator tests nothing about that denial. Then verify the website, an ordinary permitted VPN operation, and what happens to each on restart. Preserve a recovery path that does not depend on the VPN being repaired, so a mistake stays recoverable.

Both roles still share CPU, memory, uplink capacity and maintenance events. Those shared resources belong in the plan even when the authority boundary is clean.

Record what each process can do, what fails if it stops, and which boundary remains shared. Port counts are not that record.