How to Overcome Pain Points with Kubernetes Egress Controls

As organizations begin to incorporate containers as part of their cloud strategy, they recognize the need to secure application traffic leaving their Kubernetes (K8s) and Openshift platforms. Cloud and security teams are looking to adopt a Zero Trust architecture. One of the first steps is enforcing least-privilege network access, or microsegmentation, across Kubernetes environments.

Recent research from the Unit 42 team explains the risks of having containers to freely connect to the Internet; however, many security professionals struggle to enforce granular Kubernetes egress traffic controls.

I will cover how Prisma Cloud Identity Based Microsegmentation makes Kubernetes egress controls simple. But first, I will explain why traditional practices fall short.

 

What’s Missing from Traditional Approaches

Applications spanned across Kubernetes clusters have unique external dependencies delivered by the network. The illustration below demonstrates three different applications: Payment, Updates and Alerts.

Applications on Kubernetes with unique egress traffic requirements
Applications on Kubernetes with unique egress traffic requirements

The Payment application is not authorized to send outbound requests to the Internet. The Update application requires SSH access to github.com. And the Alerts application should only access pagerduty.com via HTTPS.

Here are various tools organizations can leverage to control Kubernetes egress traffic and how they compare with each other.

Kubernetes Network Policy

Network Policy is a native Kubernetes tool built that enables admins to control egress traffic using Kubernetes commands (kubectl).

The challenge with using Network Policy is that it is limited to IP-based rules for traffic leaving the cluster. This means Kubernetes Admins cannot write egress rules destined to fully qualified domain names (FQDN) such as github.com or pagerduty.com. Instead, they must know the IP resolution for these FQDNs. There are also limitations regarding visibility and logs.

Network Firewalls

Some organizations have tried using network firewalls which sit outside of the Kuberentes cluster. Unlike Kubernetes Network Policy, most firewalls today can filter egress traffic based on FQDNs.

The problem with this approach is external appliances don’t have visibility into the Kubernetes network and are not aware of the pods and services inside the cluster. There's no way for the appliances to differentiate between applications.

At best, network security teams can still implement coarse-grained controls allowing all traffic to the external FQDNs (GitHub and PagerDuty), but this grants broader access than what is required by the applications.

Network Firewalls cannot distinguish between pods/services
Network Firewalls cannot distinguish between pods/services

Proxies

Another alternative that customers usually look at is to implement an egress proxy inside of the Kubernetes at each application namespace. What makes proxies a good approach is they can offer FQDN-based controls like external firewalls while maintaining pod and services awareness like Kubernetes Network Policy.

The problem customers face with this approach is proxies only support HTTP or HTTPS traffic. Customers usually have many services that rely on both web and non-web-based services, like databases and file synchronization services.

Proxies don't support services other than HTTP/HTTPS
Proxies don't support services other than HTTP/HTTPS

Recap

Based on the challenges highlighted in earlier sections, organizations require a solution that offers:

  • FQDN-based visibility and controls to simplify egress traffic control
  • Visibility and awareness into Kubernetes pods and services for granular security
  • Egress controls for web and non-web traffic
  • Full traffic visibility and meaningful flow logs
Comparison between common network egress technologies
Comparison between common network egress technologies

How can Prisma Cloud help?

Prisma Cloud Identity-Based Microsegmentation offers capabilities needed to enforce granular egress segmentation for Kubernetes deployments. Here is what Prisma Cloud delivers to make Kubernetes egress controls simple.

 

Granular visibility

Prisma Cloud builds an application dependency visualizing all your Kubernetes applications and flows going to and from pods. You can easily understand how applications communicate with external services.

 

Cloud native policy model 

Administrators familiar with Kubernetes Network Policy can easily adopt the microsegmentation policy model built into Prisma Cloud. Use tags to apply ingress and egress controls against communications across containers. Developers can codify microsegmentation policies and embed security into their workflows.

 

Controls for any network flow 

Prisma Cloud delivers segmentation for any web and non-web flow. You also have the ability to explicitly block or allow flows for more granularity.

Application Dependency Map illustrating egress traffic from Kubernetes
Application Dependency Map illustrating egress traffic from Kubernetes

 

Learn More

Identity-Based Microsegmentation from Prisma Cloud helps organizations scale their cloud network security efforts. To learn more about how Prisma Cloud can enforce Kubernetes egress controls, then check out our technical deep dive blog.

To get valuable hands-on experience with this Cloud Network Security capability, request a 30-day trial.