Network model

Before you start

• You understand the Kubernetes NetworkPolicy resource at a reading level. If not, the upstream Kubernetes docs have a one-page primer.
• You have read Tenancy model — network policy on Kestrel is tenant-scoped, so the tenant vocabulary has to be in place before the rules make sense.

Default-deny is the floor

Every namespace inside a Kestrel tenant starts under a default-deny NetworkPolicy distributed by Capsule’s GlobalTenantResource. New namespaces inherit it the moment they are created — there is no window in which a fresh namespace is wide open.

Default-deny applies to inbound traffic: a Pod you create cannot receive traffic until an explicit allow rule permits it. This is the opposite of a default Kubernetes cluster, where Pods can reach each other freely until a NetworkPolicy narrows the traffic down. (Outbound traffic is a different story — see below.)

The default-deny policy itself carries four pre-approved ingress allow rules that are always in effect in every namespace your tenant owns. They cover the inbound traffic everyone needs, so the floor is “nothing gets in” but the practical starting state is “the four sources every workload needs can reach you, and any other inbound traffic is blocked until you write your own rule”.

The four allow rules

• Intra-namespace — Pods in the same namespace can always reach each other. A workload can talk to its own sidecars and sibling Deployments without any extra rule.
• Intra-tenant — Pods can talk to other Pods in the same tenant: any namespace carrying the capsule.clastix.io/tenant: <your-tenant> label is reachable from any other namespace in the same tenant. Cross-tenant pod-to-pod traffic is blocked.
• Traefik ingress — The Traefik ingress controller pods (running in the traefik namespace) can reach your pods on whatever port your Ingress resource points at. This is what makes external HTTP and HTTPS routing work — Traefik sits at the edge, terminates TLS, and forwards to the backend Service you named.
• Monitoring scrape — The cluster Prometheus (running in the monitoring namespace) can reach your pods on their metrics ports. This is what makes Grafana tenant dashboards work; you do not have to write an allow rule for the scrape path.

Outbound traffic is not restricted by the platform

The platform policy restricts inbound only. Outbound traffic from your pods — cluster DNS, in-cluster services, and external endpoints alike — is unrestricted until a NetworkPolicy with policyTypes: Egress selects them. That is why DNS lookups and external pulls work with no extra setup. The flip side: the moment any egress policy selects a pod, that pod’s outbound traffic is limited to what the selecting policies allow — so every egress policy you write must include its own DNS allow, or the selected pods lose name resolution. See NetworkPolicy in practice.

Adding tenant-scoped allow rules

For inbound traffic that does not match one of the four rules — for example, a Pod that should accept traffic from a specific source beyond the Traefik path — you create your own NetworkPolicy. The rule is additive: it does not remove the default-deny posture, it just opens a lane on top of it. For outbound, you write an egress policy only when you want to restrict where a pod may send — good hygiene for anything handling sensitive data — and every such policy must carry its own DNS allow.

The exact shape of a tenant-scoped NetworkPolicy (pod selectors, ingress/egress blocks, the namespaceSelector tricks for cross-namespace-same-tenant traffic) is covered in NetworkPolicy in practice. The one-line rule comes in two directions: for ingress, write a NetworkPolicy in the destination namespace, select the destination Pod, and allow the source you need; for egress (restricting where a pod may send — an S3 bucket, a public API), write a NetworkPolicy in the source namespace, select the source Pod, and allow the destination in an egress block. The Ingress on Kestrel page covers the external HTTP/HTTPS path through Traefik in more detail.

What is blocked and why

Cross-tenant pod-to-pod traffic is blocked by default because a tenant is the boundary of trust on Kestrel — RCS treats two tenants as two different teams with no implicit sharing. If two tenants need to cooperate on a workflow, open a ticket and RCS will add an explicit allow.

A handful of service and ingress shapes are restricted at a different layer than NetworkPolicy. The distinction matters because the error (or lack of one) tells you which layer is involved:

• LoadBalancer and NodePort services are rejected at admission time, not at packet-routing time. See Known limitations.
• Wildcard Ingress hostnames are not rejected at admission — the manifest is accepted — but they are unsupported and will not work. See Known limitations.

If a packet gets through to your Pod and is then dropped, the problem is NetworkPolicy. If the manifest itself is rejected before the Pod even exists, the problem is Capsule admission. The fix paths are different, so the layer that rejected you is worth noting.