Skip to content

Network Isolation

Managed cluster workloads get outbound internet access, DNS, and pod-to-pod traffic within their own cluster, and nothing else. This page covers what is allowed, what is blocked, and how cluster API access and ingress differ from outbound workload traffic.

DestinationAllowedNotes
Public internetYesAny external IP or hostname
DNSYesCluster DNS resolves normally
Same-cluster podsYesPod-to-pod within your cluster works
Other tenants’ clustersNoBlocked by network policy
Platform servicesNoBlocked (monitoring, auth, secrets)
Cluster nodesNoBlocked (kubelet, etcd, API server)
Cloud metadata / link-localNoBlocked (169.254.0.0/16, incl. 169.254.169.254)
CGNAT rangeNoBlocked (100.64.0.0/10)

Managed clusters apply network policies that:

  1. Allow DNS: your pods can resolve hostnames normally
  2. Allow same-cluster traffic: pods within your cluster communicate freely
  3. Allow internet egress: outbound to any public IP
  4. Block internal ranges: RFC 1918 private ranges (10.x, 172.16.x, 192.168.x), link-local (169.254.0.0/16, which covers the cloud metadata endpoint 169.254.169.254), and CGNAT (100.64.0.0/10) are all blocked

Workloads operate normally, while infrastructure belonging to the platform or to other tenants stays unreachable.

Your cluster’s Kubernetes API is accessible via a public endpoint:

https://<cluster>.<tenant>.clusters.kupe.cloud

This endpoint uses TLS passthrough with OIDC authentication, the same security model used by managed Kubernetes providers such as EKS, GKE, and AKS. No VPN is required.

Inbound traffic to your workloads flows through the shared Gateway API infrastructure. Create HTTPRoutes to expose your services; the platform handles TLS termination and routing.

Your pods receive traffic from the gateway proxy only. Direct inbound connections from the internet to pod IPs are not possible.