Kubernetes is widely adopted as the default platform for running microservice applications. EKS is a managed K8s service offered by AWS. EKS supports native VPC networking with the Amazon VPC Container Network Interface (CNI) plugin for Kubernetes. This plugin assigns a private IPv4 or IPv6 address from the underlying VPC to each pod. Pods can benefit from other AWS features like Flow Logs and Security Group. Because Pod is attached to VPC subnets, AWS networking layer can also route some Pod traffic following the Route Table setup.
This blog illustrates K8s Egress inspection using AWS GWLB and Palo Alto firewall. It is very common for microservices running on K8s to access external services. Due to the dynamic nature of Pod, its IP address can change frequently. This poses challenges for traditional firewalls that rely on 5-tuple of traffic flow for policies.
Use Case

Figure 1 illustrates a typical use case. In EKS, the Istio bookinfo application is deployed. The “rating” service connects to an external database. It has two Pods running, rating1 and rating2. In this example, the database runs in a separated VPC to leverage the common east-west pattern of GWLB. Microsegment is desired to control database access. Only Pod instances of “rating” service should have network access to “rating-database”. Serivce “other”, running on the same EKS cluster, is not allowed to access “rating-database”.
Kubernetes label and Palo Alto Kubernetes plugin
In the previous blog, I introduced the idea of microsegmentation by digitizing security zones through workload metadata. It is similar to standard K8s network policies where “podSelector” is used to filter by Pod labels. For K8s egress, I will continue the same approach by using the Palo Alto Kubernetes plugin. This plugin runs on Panorama. It authenticates to K8s API server using K8s service account. Then it retrieves K8s label to IP address mapping of various Pod and service types. Once the mapping is obtained on Panorama, Dynamic Address Group (DAG) is defined that utilizes the mapping. Please refer to my previous blog on DAG for more details. Figure 2 shows a screenshot of K8s label-ip-address mapping in Panorama.

Takeaways
This blog demonstrates K8s egress inspection by integrating AWS GWLB and Palo Alto. Database is used as a sample external service. Other services can be protected with the same approach. The external service can also locate in the same VPC of EKS or outside AWS. Simply adjust GWLB flow patterns according to my other posts.
Standard K8s network policies and AWS Security Group operate at L3/4. Palo Alto offers L7 and other advanced security features. In case you already use Palo Alto in other areas of your environment, it makes sense to have a central place for policy management and observability.
Palo Alto Kubernetes plugin is typically discussed with its CN-series product. However, it can be used stand-alone. Again, microsegmentation by leveraging K8s labels, or metadata is a powerful and flexible design concept.