Network isolation

The platform closes every boundary off with the same set of network rules. It writes them into each of the boundary's resource groups, on every cluster, and keeps them there.

Important

A new resource group gets its rules on the platform's next pass, which runs every five minutes by default. Until then none of the rules below apply to it: its workloads can connect anywhere, cloud metadata addresses (169.254.0.0/16) included, and accept connections from anything whose own rules let it through.

What the rules allow

• Inside the boundary. Workloads in any of the boundary's resource groups reach each other on any port, in both directions.
• Routed web traffic. The cluster's ingress controller can reach every workload, so apps and other published endpoints receive their traffic.
• Outbound HTTPS. Every workload can open TCP 443 to any address except cloud metadata and other link-local addresses (169.254.0.0/16), which are always blocked. Any address includes addresses inside the cluster: such a connection gets through when the destination's own rules admit it.
• The cluster API. Every workload can open TCP 6443, the port of the Kubernetes API server. Unless your platform administrator has narrowed it, this covers TCP 6443 to any address.
• DNS and telemetry. Name lookups (port 53) and the platform's telemetry collector are always reachable.
• What the platform itself needs. Narrow grants, each for one purpose: builds pushing images to the platform registry, workloads fetching their secrets when they start, the platform's database explorer and database operator reaching databases, and a few more. They are all listed in Network rules and reasons.

What the rules block

• Other boundaries. Workloads in two different boundaries cannot connect to each other, except to what one of them publishes — see Between boundaries.
• Outbound traffic on any other port. A database outside the cluster on 5432, an SMTP server on 25, an API on 8443: all blocked. There is no way to add outbound rules for other ports today.
• Anything else inbound. Only the sources above, and callers of what you publish through a load balancer (see Databases), can open a connection to your workloads.

A blocked connection does not fail cleanly. It hangs until the client gives up, and the application log says only that it timed out. The boundary's Network tab exists to tell you that it was the network — see Find out why a connection is blocked.

Databases

A PostgreSQL database has a Firewall setting in its networking configuration that changes the boundary rule for it:

• Boundary Access — the boundary rule above applies. This is the default.
• Same Resource Group Only — the database exchanges traffic with its own resource group only, instead of with the whole boundary. The platform's own grants still apply.
• Selected Networks — in addition to the boundary rule, the database admits TCP 5432 from every workload on the cluster. Workloads in other boundaries still cannot connect, because their own rules open no outbound TCP 5432; in practice the setting admits workloads on the cluster that are not in any boundary.

SQL Server shows the same setting, but it has no effect on SQL Server today: the boundary rule applies whichever choice is saved.

A database or container instance published through a load balancer also gets a rule for its published ports. When the resource has a list of allowed addresses, only those addresses are admitted. Without one, the rule admits any source, on the cluster as well as outside it.

Between boundaries

A connection needs the rules at both ends to allow it: the caller's outbound rules and the destination's inbound rules. Between two boundaries, that happens in two ways:

• Routed web traffic. The cluster's ingress controller reaches workloads in every boundary. An app's routed address serves whoever reaches it, and that can include workloads in other boundaries.
• Load-balancer endpoints. A database or container instance published through a load balancer without a list of allowed addresses admits any source on its published ports. A workload in another boundary gets through on a port its own outbound rules open, such as TCP 443.

What you publish is therefore published to other boundaries too. A list of allowed addresses on the resource narrows a load-balancer endpoint to those addresses, and whatever gets through still has to pass the destination's own sign-in.

Reaching is not access

A rule that lets a connection through only means it reaches the other end. The destination still decides whether to let the caller in: a database still asks for credentials, and the secrets service still checks the workload's identity.

The rules cannot be changed from inside

The platform is the only author of network rules in a boundary's resource groups. A network policy written into one of them by hand is removed on the platform's next pass, so isolation cannot be loosened from inside the boundary.

Across clusters

The rules apply cluster by cluster, and a workload's in-cluster address only works on its own cluster. To call a service of the same boundary on another cluster by its usual name, turn on Crosslink.