How Calico network policies isolate tenants on shared hosting

When teams hear "shared hosting," they often picture a single flat network where every service can reach every other service. That mental model made sense in the era of shared VMs and cPanel accounts. It does not describe a modern Kubernetes platform, at least, not one we would operate.

On StackBlaze shared hosting, every customer environment runs in its own namespace on a multi-tenant cluster. Workloads from different tenants may share physical nodes, but they do not share a network trust boundary. Calico enforces that boundary with Kubernetes NetworkPolicies at the CNI layer, backed by policy-as-code that we generate and audit on every deploy.

Why network isolation matters on shared infrastructure

Kubernetes namespaces are a logical grouping mechanism. By themselves, they do not stop Pod A in namespace `team-alpha` from connecting to Pod B in namespace `team-beta`. Without explicit network controls, any compromised workload can scan the cluster network, attempt lateral movement, and probe services it was never meant to reach.

That risk is acceptable in a single-team cluster where every pod is equally trusted. It is not acceptable on a platform where hundreds of unrelated applications run side by side. Network isolation is the layer that turns "we share hardware" into "we do not share blast radius."

• Prevents cross-tenant traffic even if an application misconfigures its service endpoints
• Limits lateral movement after a container escape or RCE vulnerability
• Enforces least-privilege connectivity between app tiers (web → API → database only)
• Provides auditable evidence for security reviews and compliance questionnaires

Calico as our CNI

We run Calico as the Container Network Interface (CNI) on every shared cluster. Calico programs iptables or eBPF rules on each node so that NetworkPolicy decisions are enforced locally, without a centralized proxy that could become a bottleneck or single point of failure.

Calico also supports platform-level network rules when we need cluster-wide boundaries, for example, blocking egress to private ranges outside a tenant's allowed destinations, or scoping observability agents to scrape only the pods they are authorized to see. For day-to-day tenant isolation, namespaced policies derived from your service graph are enough for customers to reason about during audits without wading through infrastructure internals.

The baseline policy stack

When we provision a new environment, the platform applies a baseline stack of network policies before any customer workload is scheduled. Every namespace starts from default deny, no ingress, no egress, and nothing is opened until there is an explicit reason. Intra-environment traffic is allowed only between services in the same project. Cross-service access to attached resources (Postgres, Redis, internal APIs) is derived from the dependency graph you define in the dashboard, not from ad-hoc rules someone writes by hand.

Policies are label-driven, not IP-driven. That matters because pods move, nodes get replaced, and autoscaling creates new replicas constantly. Calico resolves those labels to per-node enforcement rules automatically, so isolation survives deploys and scale events without manual updates.

How shared hosting stays isolated in practice

Isolation on shared hosting is the combination of several controls, not NetworkPolicy alone. NetworkPolicy is the enforcement layer; the platform adds identity, admission, and observability around it.

What tenants cannot do to each other

• Reach another tenant's ClusterIP or headless service, those packets never leave the source pod
• Scan neighboring namespaces via kube-dns, cross-namespace DNS responses are not useful without matching NetworkPolicy allows
• Impersonate the platform control plane, platform namespaces are excluded from tenant RBAC and have separate network policies
• Bind to host ports or share the host network namespace, blocked at admission

Linkerd for east-west trust

Network policies tell you which packets may flow. They do not tell you who sent them. For traffic inside an environment, web to API, worker to Redis, we run Linkerd as a lightweight service mesh. Linkerd injects a sidecar proxy that upgrades connections to mutual TLS automatically, so every service-to-service call is encrypted and tied to a cryptographic identity without you managing certificates or rotation.

That layer matters on shared hosting because it closes a gap Calico alone cannot: even if two pods are allowed to talk, Linkerd ensures the caller is who it claims to be. Combined with default-deny network policies, you get defense in depth, Calico decides whether a connection is permitted; Linkerd decides whether the peer is authentic. Linkerd also gives golden metrics on success rates and latency per route, which feeds directly into incident response when something looks wrong but has not yet triggered a Falco rule.

Falco for runtime threat detection

Network isolation and mTLS reduce your attack surface. They do not guarantee a workload will never behave badly once it is running. Falco closes that loop. Falco watches syscalls and Kubernetes audit events at the node level, shell spawns inside application containers, unexpected outbound connections, reads of credential files, attempts to load kernel modules, and raises alerts when behavior matches known threat patterns.

On StackBlaze shared clusters, Falco runs as a platform-managed daemonset with a curated ruleset tuned for multi-tenant environments. Alerts are scoped to the tenant namespace that triggered them and forwarded into the same audit pipeline as Calico deny logs. During a security review, that gives you a coherent story: Calico blocked the lateral movement attempt, Linkerd shows which identity initiated the call, and Falco captures the runtime indicator that something inside the container was already compromised.

Policy-as-code and drift detection

None of these controls, Calico policies, Linkerd identities, Falco rules, are edited manually in production. They are generated and reconciled from a canonical model of your environment: services, attachments, ingress exposure, and plan-level egress limits. That model is version-controlled on our side and continuously compared to what is actually running in the cluster.

If someone attempts to loosen network rules beyond what the platform model allows, for example, opening unrestricted outbound access on a shared cluster, our admission controls reject the change before it takes effect. Dedicated clusters (covered in our next article) can relax these guardrails when an enterprise team owns the full policy surface.

Observability and incident response

Calico can emit flow logs for denied connections. We aggregate these into per-environment views so you can answer "why can't my worker reach Redis?" without SSHing into nodes. Denied flows show the source pod, destination, port, and which NetworkPolicy rejected the packet.

During an incident, this matters: if a compromised pod tries lateral movement, you see the attempts in denied-flow logs even when the attack failed. That is evidence for your own post-mortem and for compliance auditors who ask whether you detect anomalous east-west traffic.

Shared hosting isolation is a design choice

None of this is accidental. Shared hosting on StackBlaze is engineered for density and cost efficiency, but the security model assumes mutually untrusting tenants. Calico, Linkerd, and Falco work together at different layers, network, identity, runtime, to make that assumption enforceable, not aspirational.

If your threat model requires stronger guarantees, single-tenant control planes, customer-managed encryption keys, or data residency in a specific jurisdiction, dedicated clusters extend this same policy toolkit with physically and logically separated infrastructure. We will cover that comparison in depth in the next article in this series.