Network rules and reasons

Grants

The rules written into every resource group of a boundary. Rules considered in the Can this reach that? check lists them by the portal name; the API returns the kind. Traffic passes when at least one grant that applies to the workload allows it.

Kind	Portal name	What it allows
default-deny	Platform basics	Nothing in or out, except DNS (UDP and TCP 53 to the cluster's DNS) and platform telemetry (TCP 4317 and 4318).
allow-same-boundary	Same boundary	Everything, on any port and in both directions, between the boundary's resource groups on the same cluster.
allow-ingress	Web ingress	Inbound from the cluster's ingress controller, on any port.
allow-runtime-egress	Outbound HTTPS	Outbound TCP 443 to any address except 169.254.0.0/16, addresses inside the cluster included.
allow-build-egress	Build fetch	The same, for build jobs.
allow-apiserver-egress	Cluster API	Outbound TCP 6443 to the Kubernetes API server; on a default installation to any address.
allow-system-egress	Platform services	Outbound to platform services on TCP 5000 (the registry) and TCP 15008 (the service mesh).
allow-secret-injection-egress	Secret injection	Outbound to the managed-identity and secrets services on TCP 8080, used when a workload fetches its secrets at start.
allow-s3-control-egress	Object storage control	Outbound from S3 storage servers to the platform on TCP 8081.
allow-system-db-ingress	Platform database access	Inbound from platform services on TCP 5432, 1433 and 15008, for the platform's database explorer.
allow-operator-ingress	Database operator	Inbound from the database operator on TCP 8000, so it can read a database's health.
allow-db-rg-ingress	Same resource group database	For databases whose Firewall is Same Resource Group Only: everything within their own resource group. They lose the same-boundary grant.
allow-db-any-ingress	Open database	For databases whose Firewall is Selected Networks: inbound TCP 5432 from every workload on the cluster. Workloads in other boundaries have no outbound grant for TCP 5432, so they still cannot connect.
egress-allowlist	Outbound allowlist	Outbound rules for one boundary. No boundary has any today, and there is no way to add them.

Two more grants exist for resources published through a load balancer — one for databases, one for container instances. They admit traffic to the published ports from the resource's allowed addresses when it has a list of them, and otherwise from any source, on the cluster as well as outside it, which is how workloads in other boundaries can reach them — see Between boundaries. They are not part of the check, which says so when the destination could be published.

Reason codes

Every answer from the check, and every blocked connection in the log, carries a reason. The portal shows its sentence; the API also returns the code.

Code	Meaning	What to do
allowed	A grant permits the connection. The sentence names it.	Nothing in the boundary's rules. If the connection still fails, look at the destination: reaching it is not the same as being let in.
cross-boundary	The other end is in another boundary.	Nothing to change: the boundary rules open no connection between boundaries. Another boundary reaches only what is published — see Between boundaries.
egress-not-allowlisted	Outbound to an address outside the cluster, on a port no grant opens. The sentence lists the ports that are open.	How to allow it shows the address, protocol and port an outbound rule would need; such rules cannot be added today. Use a port that is open, such as HTTPS on 443.
platform-port-not-granted	A platform service was called on a port the platform grants do not open. The sentence lists the ports that are.	Use one of the listed ports.
build-egress-https-only	A build job fetched over something other than TCP 443.	Use an HTTPS source.
link-local-blocked	The destination is a cloud metadata or other link-local address.	None: these are always blocked.
ingress-grant-missing	Routed traffic reached a resource group whose ingress grant is missing. Marked as a platform fault.	Nothing on your side. The platform restores the grant on its next pass; contact your platform administrator if it persists.
unmanaged-cluster-policy	A cluster-wide rule that the platform does not manage decided. Only seen in the log of blocked connections.	Contact your cluster administrator.
no-matching-allow	No grant allows this protocol and port in this direction, and nothing more specific applies.	Check the port and protocol against the grants above.

Two notes can follow the sentence: that the destination may be published through a load balancer, whose grant the check does not see, and that a grant names its port by name, which the check cannot resolve.