Ingress traffic enters a defined network boundary; egress traffic leaves it. The boundary might be a device, server, subnet, Kubernetes Pod, or cluster. Always name it. A request from a browser is egress from that device and ingress to the server receiving it.
In Kubernetes, the words also appear in specific resources: NetworkPolicy controls allowed connections for selected Pods, while an Ingress resource configures incoming HTTP routing. Those are related ideas with different responsibilities.
Ingress vs egress at a glance
| Question | Ingress | Egress |
|---|---|---|
| Direction relative to a boundary | Entering | Leaving |
| Example for a web application | A customer's signup request reaches the app | The app calls an email provider |
| Typical control question | Which sources may reach this service? | Which destinations may this service contact? |
| Useful evidence | Source, destination, port, route, account context | Destination, port, dependency, volume, purpose |
Direction does not describe trust. An incoming request may be a legitimate purchase, and an outgoing request may transmit stolen data. First identify the asset and permitted communication, then choose the control.
Follow one request across the boundaries
Illustrative example: a customer opens a signup form served through a CDN. The browser sends a request to the CDN, the CDN forwards it to the application, and the application calls an email service.
Browser to CDN: egress from the customer's device, ingress to the CDN.
CDN to origin: egress from the CDN, ingress to the origin network.
Application to email provider: egress from the application's network, ingress to the provider.
Provider response: traffic returns over the connection, subject to the network's connection-tracking rules.
A log labelled “egress” is ambiguous until you know which component produced it. Record the observation point when comparing firewall logs, proxy traces, and application events. Otherwise the same transaction can appear to contradict itself.
Kubernetes NetworkPolicy: ingress and egress are independent
In Kubernetes, a NetworkPolicy selects Pods and specifies allowed traffic. A Pod can be isolated for ingress, egress, both, or neither. Applicable allow rules combine; for a connection between isolated Pods, the source's egress and destination's ingress permissions both matter. The official NetworkPolicy documentation describes these semantics and the treatment of reply traffic.
Check your network plugin before relying on a policy. Kubernetes notes that NetworkPolicy requires an implementation that enforces it. Creating a resource is insufficient if the cluster's networking does not support enforcement.
For a frontend that calls an API, write down the required path before changing policies: frontend Pods to API Pods on the application port; API Pods to their database; and any necessary DNS and external dependencies. A default-deny rollout that overlooks name resolution can break an otherwise correct destination rule.
Is Kubernetes Ingress the opposite of egress?
Lowercase ingress is a traffic direction. The capitalized Kubernetes Ingress API defines external HTTP and HTTPS routing to Services, with a controller implementing it. It is not a general outbound policy mechanism. Kubernetes recommends Gateway API for new capabilities; the Ingress API is frozen, which does not mean every existing Ingress deployment suddenly stops working.
Keep routing and access policy separate in your review. “The request reaches the right backend” does not establish “the requester may perform this operation.” Likewise, permitting an outbound connection to a payment provider does not authorize a payment.
Ingress controls and egress controls protect different things
For ingress, start with intended exposure. Which services must be public? Which should accept traffic only from another internal service? At the application layer, keep authentication, authorization, request validation, and action-specific abuse controls close to the operation they protect.
For egress, inventory required destinations and investigate unexpected outbound behavior. An application may need package repositories during deployment but not during normal operation. An API may need one messaging service without needing arbitrary internet access. Separate runtime dependencies from maintenance workflows so exceptions do not become permanent broad permissions.
Measure before restricting a shared dependency. Record expected destinations and error rates, test in a limited environment, and identify the operator who can restore service. A security rule that blocks necessary callbacks can create retries and queue growth even when inbound pages look healthy.
A practical investigation checklist
Name the boundary: Pod, namespace, node, subnet, proxy, or application.
Describe the failing operation: a route and effect, not only “network broken.”
Trace the actual path: include DNS, proxies, load balancers, and third-party calls.
Check both sides: source egress and destination ingress rules may each affect the connection.
Separate layers: successful TCP connectivity does not prove correct TLS, HTTP routing, authentication, or authorization.
Test the intended result: confirm the signup, login, or order completes once, rather than relying only on a successful health check.
Keep rollback specific: know which policy changed and how to restore the previous allowed communication.
Where browser verification fits
Traffic direction helps place a control, but cannot establish that a browser-originated request is suitable for a valuable action. A login request can pass network rules and still be an automated attempt against a real account. An outbound callback can be legitimate while the signup that triggered it was abusive.
MANDATE focuses on invisible browser verification for those high-value web actions. Hosted verification evaluates browser proof against live server-side state, while the application retains responsibility for account permissions and business outcomes. That is an application concern alongside network policy. It does not replace Kubernetes networking, a firewall, or an egress control.
For an example of the boundary between fresh browser evidence and a backend decision, read why browser proof needs server state. If the problem is repeated valid-looking requests, continue with replay attacks and legitimate retries.
AI-assisted article. Review linked sources and current integration guidance before implementation.
Next evaluation step: If network connectivity is already correct and the remaining problem is automated abuse of a browser action, review the supported browser integration quickstart to plan the first route and its failure path.