About ACezar

  A common struggle that Palo Alto Networks customers shared before adopting Prisma Cloud was filtering network traffic leaving their Kubernetes platforms . It is a valid concern as applications should only connect to the minimum set of components they need in order to support the business.   In this post, I will walk through how you can visualize and isolate Kubernetes pod egress traffic with the Identity-Based Microsegmentation module from Prisma Cloud.   Kubernetes Egress Control Scenario   In our example below, we have a K8s cluster running three applications (Payment, Updates and Alerts). The Payment application must be blocked from accessing the Internet, the Update application can only access github.com over SSH, and the Alerts application can only access pagerduty.com over HTTPS.   The ideal outcome with Kubernetes network egress controls   The table below identifies various technology approaches and their capabilities. For more details about this comparison, see our blog on Kubernetes egress challenges.     K8S Network Policy External Firewalls Proxies Prisma Cloud Support for FQDN-based policy   ✓ ✓ ✓ Visibility into K8S pods for granular controls ✓   ✓ ✓ Supports any port/protocol ✓ ✓ HTTP/HTTPS only ✓     How to Filter Egress Traffic with Prisma Cloud   As Prisma Cloud Identity Based Microsegmentation is deployed inside the K8s cluster as a daemonset ( K8s will make sure that the microsegmentation pod is always available at all nodes ). With this approach, the microsegmentation module is able to automatically discover the K8s namespaces and it's aware of every single pod and services. A very important factor to consider, as it needs to enforce policies against any protocol/port to any pod/service.    Prisma Cloud can enforce egress controls at the K8s level on any protocol/port Let's look at how we can achieve this. Payment application The requirements here is to not allow any connection to the internet from this application, so the only thing we need to have is to enable Enforcement mode on the Payment App. Once this is done, only the traffic that matches an existing "Allow" policy will go through and everything else will be rejected.   Update application The update application has specific requirements that the developers must adhere to. It must connect to GitHub over SSH to synchronize files and deny everything else.   Let's add a policy that allows SSH traffic to Github and enable Enforcement Mode. Update app policy   The above policy defines as subjects (pods that will be affected by this policy) any pod that is deployed in the update namespace and has the tag app=update.   The action enforces that only traffic on tcp port 22 will be allowed to Github (a FQDN address). Alerts application The alerts application also has very specific requirements. It must connect to PagerDuty over HTTPS to send alerts and deny everything else.   Let's add another policy to enforce this requirement and after that, enable Enforcement Mode.     Alerts app policy   The above policy defines as subjects (pods that will be affected by this policy) any pod that is deployed in the alerts namespace and has the tag app=alerts.  The action enforces that only traffic on tcp port 443 will be allowed to Pagerduty (a FQDN address). Now that everything is in place, let's check how our applications are behaving.   Applications with strict egress controls   As we can see, the Alerts application is being allowed to reach out to PagerDuty but it's being denied access to GitHub . The Payment app is being denied access to GitHub (and everything else over the Internet) while the Update application has some traffic to GitHub being allowed and some other traffic being denied, because we're only allowing SSH and anything else (that's why we have the flow colored in amber).   Learn More   Identity-Based Microsegmentation is a Cloud Network Security capability in Prisma Cloud. Get valuable hands-on experience with a 30-day trial.   ... View more