Whether an enterprise is migrating its legacy application to a cloud-native architecture or deploying a new cloud-native application, it will face the challenge of integrating with security tools such as firewalls that rely on a stable network identity for security configuration. This is due to the fact that cloud-native workloads aren’t guaranteed to have a fixed network identity. The juxtaposition of dynamic, modern workloads alongside traditional applications that rely on fixed network identifiers presents a unique set of challenges.
This is particularly pertinent for DevOps and platform teams tasked with ensuring seamless communication and security between these disparate environments. It becomes crucial for DevOps, platforms, and network security teams to ensure seamless communication and secure traffic flow as organizations balance innovation (cloud-native applications) and harness existing investments (traditional firewalls and data sources).
Common Scenarios
Securing and Identifying Traffic Leaving the Cluster
One of the key challenges in integrating cloud-native workloads with legacy applications behind a firewall is securing and identifying traffic from specific workloads running in the cluster. Many applications, such as databases, are protected by firewalls that need a stable IP address to enable access to these applications. Teams want to ensure that only authorized traffic from specific workloads can access applications such as databases via the firewall rule put in place, thus reducing the attack surface area.
Integration with Third-Party Applications
In addition to bridging the gap between legacy and cloud-native applications, seamless integration with external third-party applications is required. These external applications may require fixed network identifiers to enable access to services behind their own firewalls.
What’s the Challenge for DevOps and Platform Teams?
A significant challenge that arises in both the scenarios above is maintaining a stable IP address for workload traffic leaving the Kubernetes cluster. This is due to the fact that any traffic leaving a Kubernetes cluster is assigned the IP address of the node that the pod is running on by the SNAT (Source Network Address Translation) process. Since a pod is not guaranteed to run on a specific node, the IP address associated with the egress traffic is dynamic, complicating identification by external resources.
Let’s take an example, as shown in Figure 1, where a platform owner or DevOps engineer needs to establish connectivity between two systems: a payment workload and a credit card database behind a firewall. The payment workload is located in the Kubernetes cluster, while the other system is located outside the cluster. In such a scenario, the firewall requires a fixed IP address of the payment workload in order to establish connectivity with the credit card data warehouse and implement security rules.
Egress Gateway: Assigning a fixed IP address to traffic leaving the Kubernetes cluster
Egress Gateway
DevOps and platform owners should be able to assign a fixed IP to egress traffic from workloads so that traditional applications and tools can use this fixed IP information to build secure workload communication with Kubernetes workloads, as shown in the above figure. An Egress Gateway creates a specific exit point for egress traffic and assigns a fixed IP to any egress traffic leaving that exit point. Teams can configure egress traffic from specific workloads to exit through an egress gateway, thus guaranteeing a fixed IP address associated with the egress traffic.
How it works
Workloads are configured so that their outbound traffic is directed through an egress gateway. For resilience, you can set up numerous egress gateways for high availability, or a specified route based on a policy. The egress gateways are set up to use a specific IP pool and to perform a network address translation (SNAT) on the traffic passing through them. Hence, any number of workloads can have their outbound connections multiplexed through a fixed, small number of egress gateways, and all of those outbound connections acquire a source IP from the egress gateway IP pool.
An egress gateway acts as a transit pod for outbound application traffic configured to use it. As traffic leaving the cluster passes through the egress gateway, its source IP is changed to that of the egress gateway pod, and the traffic is then forwarded on.
Benefits of Egress Gateway
- Enhance Security – By assigning fixed IP addresses to a workload’s egress traffic, DevOps and Platform Engineers can reduce the attack surface, and mitigate risks associated with exposing broad IP ranges of nodes.
- Extend Firewall Rules – Firewalls can now extend their rules to the specific workload in the Kubernetes cluster. The rule will always apply to that workload irrespective of its location in the cluster.
- Seamless Integration – Facilitates communication between Kubernetes workloads and traditional applications without the need for cumbersome workarounds.
Key Takeaway
With an egress gateway approach, DevOps and Platform engineers can ensure a stronger security posture for their Kubernetes cluster, simplified network security management, and no additional network infrastructure cost.
Learn more about Calico Egress Gateway.
