As more organizations embrace containerization and adopt Kubernetes, they reap the benefits of platform scalability, application portability, and optimized infrastructure utilization. However, with this shift comes a new set of security challenges related to enabling connectivity for applications in heterogeneous environments.
In this blog post, we’ll explore a real-life scenario of security exposure resulting from egress traffic leaving the Kubernetes cluster. We’ll examine how the Calico Egress Gateway can help mitigate these issues by providing robust access control. By using Calico Egress Gateway, enterprises can secure communication from their Kubernetes workloads to the internet, 3rd party applications and networks while maintaining a high level of security.
The Calico Egress Gateway enforces security policies to regulate traffic flowing out of the Kubernetes cluster, providing granular control over egress traffic. This ensures that only authorized traffic is allowed to leave the cluster, mitigating the risks associated with unauthorized outbound traffic.
Egress security challenges
For enterprises developing cloud-native applications with containers and Kubernetes, a frequent requirement is to connect to a database server hosted either on-prem or in the cloud, which is safeguarded by a network-based firewall. Since workloads with Kubernetes are dynamic without a fixed IP address, enabling such connectivity from workloads requires opening up a range of IP addresses resulting in security exposure that malicious actors can exploit to gain unauthorized access to the database via the Kubernetes clusters. Kubernetes clusters have the following limitations that make it challenging to enforce granular egress access control.
- Workload IPs (Pod CIDR) are typically not advertised between heterogeneous networks; doing so requires unique Pod CIDRs for each cluster that most organizations cannot afford due to limited IPv4 address space. As a result, traffic is NATed to the node’s IP, which is non-deterministic.
- Unlike virtual machines (VMs), pod IPs in Kubernetes are ephemeral and cannot be used to identify a workload.
Security teams have invested years protecting critical assets by implementing zone-based security using network firewalls. Existing security processes require connectivity between assets in disparate environments to be routed, restricted, and logged by firewalls. Regulatory requirements such as PCI-DSS mandates the archival of firewall logs for audit, security incident detection, and response. Organizations risk non-compliance when Kubernetes workloads communicate with external services and fail to meet these requirements.
Native Kubernetes egress options
Kubernetes, by default, NATs egress packets to the interface IP of the node from which they exit the cluster. Consider the previous example of permitting connectivity to the database server; a network security admin must allow the entire node IP CIDR (node subnet) as pod scheduling on nodes is non-deterministic. Doing so will permit connectivity to the database server from any pod from any node in the cluster. In the example below, if “pod a” requires connectivity to the database server, the node IP CIDR must be allow-listed in the firewall, which would inadvertently grant access to “pod x” as well. In this scenario, the database server will be exposed to the threat actor if “pod x” is compromised.
It is possible to disable the default NATing behavior by configuring `natOutgoing` as false to retain the IP address of the pod that initiated the session. In this scenario, the network security admin must allow the entire pod CIDR (pod subnet) to enable connectivity, as pod IPs in Kubernetes are ephemeral. Both scenarios require overly permissive firewall rules increasing the attack surface and risking non-compliance.
Calico Egress Gateway
Calico Egress Gateway provides an elegant solution for organizations implementing zero-trust workload access control. It does this by using configurable IP pools to extend the identity of workloads to upstream network security devices. Network traffic from pods transits egress gateways, which perform source NAT to specific IPs. With an egress gateway in place, firewall rules can be adjusted to allow traffic only from the IP of the egress gateway rather than the entire node or pod IP CIDR, eliminating the need for overly permissive firewall policies. Further, egress gateways can be combined with Calico security policies to ensure unauthorized traffic does not leave the cluster. Going back to the previous example, with the implementation of the egress gateway, the database server is no longer exposed to compromised “pod x”.
Egress gateway deployment patterns
Calico Egress Gateways offer various deployment and configuration options to cater to the unique needs of your applications and infrastructure. Some examples include:
- Shared egress gateway
- Egress gateway per namespace
- Egress gateway per deployment
- Egress gateway load balancing and failover
Shared egress gateway
In a shared egress gateway setup, workloads in multiple namespaces route traffic through a single egress gateway deployment. Consider a scenario where workloads in the cluster connect to an external service provider that requires IP-based allow-listing. Traffic routed through a shared egress gateway is source NATed to a chosen IP to meet such a requirement.
Egress gateway per namespace
An egress gateway per namespace deployment extends the identity of the namespace to upstream network security devices by allocating an egress gateway to required namespaces. Consider an organization with several development teams, business units, or customers deploying applications to Kubernetes in their respective namespaces. These users can raise firewall access requests for their applications by providing namespace-specific egress IPs. Firewall teams can action these requests by associating egress IPs with firewall address groups, which simplifies change management and helps maintain an audit trail. With an egress gateway per namespace setup, each team has its own egress gateway deployment that ensures only the specified IPs are allowed to access relevant external services, guaranteeing security and compliance in multi-tenant environments.
Egress gateway per deployment
To provide secure connectivity for Kubernetes workloads, an egress gateway can be allocated for each deployment, thereby extending the identity of those deployments to upstream network security devices. Consider a namespace with backend workloads (deployment x) that connects to a secure on-prem database and frontend workloads (deployment y) that connects to an external service. Network firewalls must be able to uniquely identify each deployment to enforce workload-specific restrictions. Additionally, Kubernetes workload traffic may traverse network proxies and data loss prevention (DLP) solutions that also require unique identities for audit, logging, and compliance. Such security requirements can be met more effectively by assigning each deployment a distinct egress gateway.
Load balancing and failover
Calico Egress Gateways offer several benefits, including traffic load balancing, high availability, and fast failover using health probes. For organizations with Kubernetes clusters that span multiple data centers or cloud regions, egress gateways can perform health checks on network links and reroute traffic as needed. In addition, egress gateways that use BGP-based routing provide flexible deployment options to ensure reliable service availability. Organizations can optimize their Kubernetes cluster for high performance and resilience with Calico egress gateways.
Calico Egress Gateway is an elegant solution that allows DevOps and Security team to implement zero-trust workload access control. It helps accelerate the migration to Kubernetes without disrupting existing security processes by providing flexible deployment options to meet customer requirements.
Want to learn more about Calico Egress Gateway? Read this blog: Calico Egress Gateway: Universal Firewall Integration for Kubernetes
Join our mailing list
Get updates on blog posts, workshops, certification programs, new releases, and more!