Automation: The Key to Consistent Security for Kubernetes

How is Kubernetes security managed in your organization? This question has become top of mind for security and DevOps teams as their job responsibilities get increasingly intertwined in the cloud native applications world. There are Kubernetes network policies and next-generation firewall (NGFW) security policies, and the teams crafting these policies tend to be different. A unified approach is needed so that consistent policies are applied with access control and advanced security services such as threat prevention and application segmentation. If a unified approach is not used, it is very cumbersome to figure out application connectivity issues post-deployment.

Automation is the key to helping cloud security teams pre-provision security policies to ensure they are in place and consistent before applications are deployed. Enabling communication and having checks and balances between different teams is important to having the right security controls on the network.

Kubernetes Network Policy: The Building Block

Since Kubernetes network policies have been introduced, they’ve been used extensively to bring in basic access control between application pods. In a Kubernetes cluster configured with default settings, all pods can discover and communicate with each other without any restrictions. The Kubernetes object type NetworkPolicy lets you allow and block traffic to pods.

When customers run multiple applications in a Kubernetes cluster or are sharing a cluster among multiple teams, it’s a security best practice to create network policies that permit pods that need to communicate with each other to do so, while blocking other network traffic.

Here is a small sample of a policy file that denies all ingress traffic to a cluster. The policies are expressed in YAML files so it is very easy for DevOps teams to automate this with Kubernetes tooling.

Figure 1: Sample Policy File

Enter CN-Series: Industry’s first Kubernetes Native Next-Generation Firewall

Cloud-native applications can be kept nimble and secure with the industry’s first Machine Learning-powered next-generation firewall (ML-Powered NGFW) built specifically for Kubernetes environments. The Palo Alto Networks CN-Series containerized firewall provides deep layer 7 visibility into container traffic and enforces threat prevention policies to protect allowed traffic across Kubernetes namespace boundaries. These container firewalls make the most of native Kubernetes orchestration by integrating firewall deployment directly into the DevOps workflow--a single command is all it takes for simultaneous deployment on all nodes of a Kubernetes cluster.

Figure 2: CN-Series: Industry’s first Kubernetes Native Firewall

Security Policies for CN-Series are applied via Panorama UX or XML APIs. Customers currently using Kubernetes tooling like Helm for applying network policies and XML APIs for PAN-OS based policies have desired a common automation mechanism for both.

Cortex XSOAR + CN-Series: Better Automation for Kubernetes Security

DevOps engineers typically configure network policies along with the application deployments in Kubernetes. Until recently, when CN-Series was deployed within the Kubernetes cluster(s) using automated mechanisms like Helm Charts, PAN-OS security policies had to be configured separately in Panorama.

That changes with this key innovation from Palo Alto Networks. We combine the native automation in Kubernetes with Cortex XSOAR and its integration with PAN-OS to help customers completely automate security for applications deployed in Kubernetes.

Figure 3: CN-Series Policy Management Automation with Cortex XSOAR

Customers want to continue to leverage the automation capabilities in Kubernetes. To make that easier, we extended the network policy constructs in Kubernetes. It now includes PAN-OS attributes like app-id, url filtering, vulnerability protection,  etc. as shown below.

Figure 4: Sample of Network Policy Constructs in Kubernetes with PAN-OS Attributes

This is how simple the end to end automated flow would be:

1. Security admins can now provide the required security services for specific containerized applications upfront to the automation teams as explained in the picture above.
2. DevOps teams can include these policies as code templates in their CI/CD pipelines
3. When the network policies are applied to Kubernetes, notifications from Kubernetes watcher triggers a Cortex XSOAR playbook. The Cortex XSOAR playbook translates the opaque PAN-OS objects along with src, dest, allow/deny to create the PAN-OS policies automatically for the relevant Kubernetes clusters.
4. Cortex XSOAR has a setting for auto commit of the policies in Panorama, so the security admin can do the commits to allow for manual checking if desired.

Here is the workflow for the automated Cortex XSOAR playbook setup that tracks incidents and debug issues:

Figure 5: Sample of Cortex XSOAR playbook

Summary

Palo Alto Networks strongly believes container adoption demands comprehensive protection all the way from scanning container registries in the CI/CD pipeline to network security in production deployments. We have built a comprehensive suite of products in Prisma Cloud, CN-Series firewalls and Cortex XSOAR to ensure security concerns do not remain a hindrance for our customers in their container adoption journey.

Automation is one of the key benefits of Kubernetes. Palo Alto Networks further augments securing Kubernetes using Cortex XSOAR, CN-Series, Panorama and Kubernetes network Policy with PAN-OS extensions! The video explains the new capabilities in detail.

Note: This CN-Series Content Pack will be coming soon to Cortex XSOAR Marketplace. If you are new to Cortex XSOAR, do take a test drive of our full-featured, free Community Edition.