Extending Panorama’s firewall address groups into your Kubernetes cluster using Calico NetworkSets

When deploying cloud-native applications to a hybrid and multi-cloud environment that is protected by traditional perimeter-based firewalls, such as Palo Alto Networks (PAN) Panorama, you need to work within the confines of your existing IT security architecture. For applications that communicate with external resources outside the Kubernetes cluster, a traditional firewall is typically going to be part of that communication.

A good practice is to enable enterprise security teams to leverage existing firewall platforms, processes, and architectures to protect access to Kubernetes workloads.

Calico Enterprise already extends Panorama’s firewall manager to Kubernetes. The firewall manager creates a zone-based architecture for your Kubernetes cluster, and Calico reads those firewall rules and translates them into Kubernetes security policies that control traffic between your applications.

With its 3.11 release, Calico Enterprise extends its integration with PAN firewalls to include Panorama address groups in sync with Calico NetworkSets. The new release provides granular application security for your cloud-native application and eliminates workflow complexity.

This integration helps users to:

  • Eliminate complex workflows when using existing PAN firewalls with Kubernetes workloads
  • Extend their Panorama firewall investment to cloud-native applications
  • Provide granular application security for their cloud-native applications

Why Calico’s integration is important

Cloud-native workloads require access to external resources such as databases, cloud services, third-party application programming interfaces (APIs), and other applications. Unfortunately, traditional methods such as network firewalls, which rely on fixed network addresses, are insufficient to specify access controls at a granular workload level.

That makes controlling the egress traffic in a cloud-native environment challenging, because the security team needs to define a deny/allow list on the perimeter using firewall policies and on a granular level using Kubernetes network policies. This design increases the risk of having an inconsistent deny/allow list between the perimeter firewall and the Kubernetes cluster, increasing the time and cost of troubleshooting.

In short? Network firewalls and Kubernetes don’t speak the same language.

About the integration

On the perimeter level, Panorama offers address groups to simplify the creation of security policies. Panorama address groups are used to combine addresses that require the same security settings into address groups, and then use those groups to create security policies. Address groups can be configured statically or dynamically via a filter expression that selects tagged addresses.

On the granular level, Calico offers NetworkSets to enable fine-grained workload access controls. Calico GlobalNetworkSets and namespaced NetworkSets represent an arbitrary set of IPs/CIDRs/FQDNs to use in a network policy and eliminate the need for users to manually update all the access control policies when one end of the communication changes. Calico NetworkSets can be used to apply policy to control traffic going to or coming from external, non-Calico networks. Using Calico NetworkSets, you can easily scale out by using the same set of IPs in multiple policies.

With Calico’s new Panorama address groups integration with Calico NetworkSets, Calico automatically discovers Panorama address groups and translates them to Calico NetworkSets.

How to use Calico’s new Panorama integration

To integrate your existing address groups, you need to create a ConfigMap with Panorama parameters, install Panorama’s username and password as secrets, and install the address group controller in your Kubernetes cluster. Calico automatically maps the values to a Calico Enterprise GlobalNetworkSet.

Create a Panorama address groups ConfigMap

1. Create a namespace for the tigera-firewall-controller.

kubectl create namespace tigera-firewall-integration

2. Create a ConfigMap and add your Panorama device information in the data section. For example:

kubectl create configmap tigera-panorama-controller-config -n tigera-firewall-integration 
--from-literal=tigera.firewall.host=__IPADDRESS_OF_PANORAMA__ 
--from-literal=tigera.firewall.panorama.tags="tag1, tag2, tag3" 
--from-literal=tigera.firewall.panorama.device-group="shared"

 

In this example, tigera.firewall.host is the Panorama host address and tigera.firewall.panorama.tags is the set of Panorama tags used to filter the address groups.

Install Panorama username and password as secrets

Store each Panorama username and password as a secret in the tigera-firewall-integration namespace. Here is an example:

kubectl create secret generic panorama-access -n tigera-firewall-integration 
--from-literal=panorama.username=__USERNAME_OF_PANORAMA__ 
--from-literal=panorama.password=__PASSWORD_OF_PANORAMA__

Deploy the address groups controller in the Kubernetes cluster

Create the manifest.

kubectl create -f 
http://docs.tigera.io/manifests/tigera-panorama-address-groups.yaml

Verify the integration

  • Log in to Panorama.
  • Select Objects, and create new Address Groups.
  • In the Manager UI, click Network Sets in the left navbar and verify that the GlobalNetworkSets have been created.

 

If you have Panorama as part of your existing IT security infrastructure, integrating with Calico Enterprise is the best way to extend security to your cloud-native applications, reduce wait time to deploy new workloads, and enable better collaboration between security and DevOps teams.

Check out the Calico 3.11 release notes to see all of the details.

 

Join our mailing list

Get updates on blog posts, workshops, certification programs, new releases, and more!

X