Network policies

← Documentation · Welcome

Your namespace is sealed and deny-by-default: it can't be reached from and can't reach into anything outside itself, except what the platform explicitly opens. NetworkPolicies are platform-managed - you can't create or edit them yourself (see Cluster policies); you request changes instead.

What works out of the box

• Traffic inside your namespace - your pods can talk to each other and to your own Services freely.
• Incoming HTTPS via your Ingress / HTTPRoute - the platform's ingress controller reaches your pods; that's how your users get in.
• DNS and the other cluster basics your pods need to run.
• Egress according to your app's profile - what your app may reach outside the cluster was set up at onboarding; if a destination you need is blocked, request it (below).

Everything else - reaching another namespace, being reached from another namespace, additional external destinations, traffic that bypasses the shared ingress - is an exception you request.

Diagnosing a blocked connection

Symptoms are always the same: timeouts (not "connection refused") from inside your pods, or an external client that can't reach something not exposed via your Ingress. Before opening a ticket, check:

1. Is the target inside your namespace? Then it's not the network policy - check the Service name/port and pod labels.
2. Is it another namespace or an external host? That's the isolation working as designed - request an exception.

Requesting an exception

Open a ticket at support@inf.ethz.ch (what to include) and name the exact flow - source, destination, port:

• Extra egress - e.g. "allow egress to example.com:443".
• Cross-namespace traffic - both namespaces, direction, and port.
• A LoadBalancer / external IP - for non-HTTP(S) traffic that can't go through the shared ingress; name the Service and port.

Exceptions to isolation are reviewed before they're granted - one line on why is enough.