Egress allowlists need destination identity and a bounded IP range
An internal service can make outbound requests to package registries, model providers, webhooks, and partner APIs. Those connections are often treated as normal infrastructure traffic. If the service is compromised, the same network path can become a channel for data exfiltration, command-and-control, or access to a cloud metadata endpoint. An egress allowlist narrows that path, but only when it identifies the destination and protocol that the application actually needs.
An allowlist based on a broad IP range is easy to bypass when the destination uses a content delivery network or a shared cloud address. A hostname rule can also be too broad if it permits every path and method on a shared domain. The policy should combine a destination, a port, a protocol, and, where the proxy understands it, a path or TLS server name. The goal is to make the permitted traffic attributable to a use case.
Start from the application contract
List each outbound dependency and the exact service, region, port, and protocol it requires. Record whether the connection is a public API, a private endpoint, a package mirror, or a webhook. Put the owner and expiry on every exception. A wildcard entry should be a reviewed temporary control, not the default that makes an application work.
For HTTP traffic, enforce policy at an egress proxy or gateway where it can inspect the destination host, TLS server name, and request method. A layer 3 network policy can permit or deny addresses, but it may not know that a broad service address belongs to an unrelated tenant. Pair network policy with application-level authorization and a trusted DNS resolver.
When a Kubernetes workload needs an external service, an implementation may expose an explicit service entry or gateway route. Istio's egress guidance describes changing from an allow-any mode to a registry-only mode and creating a service entry for each approved destination. Gateway API documentation warns that external hostname backends still depend on DNS trust and recommends egress domain allowlists plus admission and network controls. Those controls address different failure modes.
Close the metadata and DNS paths
Cloud metadata endpoints are not ordinary external dependencies. Block application access to metadata addresses unless the workload has a documented identity-federation need. Use a managed identity path that limits token scope, and test from the workload rather than assuming a network policy covers the host's routing table.
DNS is part of the policy. A hostname allowlist that follows a DNS answer chosen by an untrusted resolver can be redirected. Use a controlled resolver, resolve internally, and apply policy to the resolved destination and the original host or TLS identity where possible. Protect the configuration that changes DNS records and monitor for new names that resolve to the same destination ranges.
Logging must show the workload identity, permitted destination, policy rule, and decision, while avoiding sensitive request bodies. Count denied and allowed connections by service and owner. A sudden allowed connection to a permitted wildcard can be more useful evidence than a blocked request to an unknown address.
Test bypass paths as well as denials
Try a direct IP connection, a mismatched TLS server name, an alternate port, and a destination reached through a redirect. Confirm that the policy follows the same trust path the application would use. Test from a pod, a node, and a serverless function if they share the same account. A control that works in one runtime may not exist in another.
Run a canary that attempts to reach an unapproved test domain and verify the denial is recorded. Then exercise each approved integration after a certificate rotation, DNS change, and provider outage. An allowlist that breaks recovery tools or blocks a trusted patching service may be removed under operational pressure unless the exception process is clear.
The final control is a small, reviewable set of destinations with an owner and a reason. Egress restriction is not a promise that a compromised service cannot communicate. It is a way to make that communication require an approved route and leave a record of which workload used it.
Top comments (0)