.png)
Explore the major differences between Ingress and Egress network traffic, and learn how they can affect the performance of your system. Get a detailed overview of the two concepts and how they impact network performance.
We consider workloads or servers running in a cloud to better understand ingress v/s egress
Ingress is traffic destined to a workload that runs inside your data center or cloud. The traffic is initiated by an entity outside your network boundary.
Ingress traffic more often isn’t trusted or does not have an identity. It can be rogue traffic that needs filtering, or trusted traffic that needs to be appropriately routed with proper controls
Depending on the network boundary you consider, ingress traffic may be trusted or untrusted
If you consider a Kubernetes pod, all the traffic received by the pod is ingress traffic for the pod. Similarly all traffic received inside a Kubernetes Cluster, is Ingress for that cluster
When considering cloud, all the traffic received by Cloud Infrastructure like a public load balancer is the Ingress layer for this cloud
A CDN probably fronts the cloud infrastructure that forms the Ingress for Internet traffic.
If a workload in pod in a Kubernetes is communicating with another pod, it is a part of Egress traffic for that pod
A cluster egress is the one that has all the traffic leaving the cluster
A workload may communicate external entities over the internet. These entities may be outside the Kubernetes Cluster, Cloud Data Center or Private Internet.
It is important to note where the traffic initiates to understand Ingress and Egress better. For a Kubernetes Pod that runs a workload, if it is the initiator of traffic, then all responses it is receives is treated differently from other untrusted Ingress traffic.
Broadly speaking Ingress applies to traffic that may be subject to Ingress policies which is either bypassed or reduced for egress or traffic initiated by egress.
Data loss can happen as a result of an Ingress connecting to an internal workload and response containing sensitive data. Loss can also happen in Egress cases when an internal workload initiates connection and transmits sensitive information
Typical cases for egress data loss are when emails are sent out, there is data uploaded to the cloud or an external server, or a file transferred through a network protocol like FTP or HTTP
Egress path can be subject to a rogue actor trying to steal data and sharing it externally. Securing egress involves running Data Loss Prevention policies for all outgoing traffic. Egress filtering is a critical aspect to enforcing security controls on outbound traffic towards external networks
Ingress path can be subject to unsolicited traffic, denial of service attacks, or an attacker looking for a vulnerability. Firewalls, API Gateways and mitigating denial of service attack are important when securing Ingress. Any incoming network traffic should be subject to inspection to detect malicious activity
EnRoute Ingress API Gateway is a key component that helps secure Ingress for incoming traffic.
Traffic entering a Kubernetes cluster goes through an Ingress. It is the first entry point for all external traffic entering the Kubernetes Cluster. Similarly, all traffic leaving a Kubernetes cluster forms the egress.
Typically a LoadBalancer type of service is defined to provide an External IP to a service which is the external facing interface.
Kubernetes Ingress provides an opportunity to route and secure traffic entering the cluster. EnRoute Ingress API Gateway provides both routing and security capabilities for all traffic entering the cluster.
Both the Ingress and Gateway API are standards that help standardize Ingress APIs. EnRoute is a full featured, battle tested Ingress API Gateway that can be programmed using it’s CRDs, Ingress or Gateway API
Kubernetes Egress is traffic destined towards a process outside the cluster. This is traffic that is initiated by a service to an external process outside the cluster. Note that traffic between pods in the same cluster is referred as East-West traffic and isn’t a part of egress
Per pod isolation for traffic can be specified for Ingress and Egress traffic. Network policies in Kubernetes provide a mechanism to control traffic and isolate pods by specifying detailed network policy rules.
Ingress and Egress network policies in Kubernetes can be specified using CIDR, Ports and namespaces. Along with this, the traffic direction can also be specified for a detailed policy
