--- title: "Extending Panorama’s firewall address groups into your Kubernetes cluster using Calico NetworkSets" source: "https://www.tigera.io/blog/extending-panoramas-firewall-address-groups-into-your-kubernetes-cluster-using-calico-networksets/" --- [Technical Blog](https://www.tigera.io/category/technical-blog/) # Extending Panorama’s firewall address groups into your Kubernetes cluster using Calico NetworkSets By [Joseph Yostos](https://www.tigera.io/blog/author/joseph-yostos/) on Jan 05, 2022 • 4 min read 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. ## 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 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 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. ![Calico discovers Panorama address groups and translates them to Calico NetworkSets. Diagram shows the flow](https://www.tigera.io/app/uploads/2021/12/panorama-integration.png) ## 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](https://docs.tigera.io/v3.11/release-notes/) to see all of the details.***   [Partner/Integration](https://www.tigera.io/tags/partner-integration/)[Products](https://www.tigera.io/tags/products/)[Release](https://www.tigera.io/tags/release/) ## Related posts [![Meet Mylo: An AI-native way to work with Calico](https://www.tigera.io/app/uploads/2026/09/Meet-Mylo-An-AI-native-way-to-work-with-Calico.png)](https://www.tigera.io/blog/meet-mylo-an-ai-native-way-to-work-with-calico/) #### [Meet Mylo: An AI-native way to work with Calico](https://www.tigera.io/blog/meet-mylo-an-ai-native-way-to-work-with-calico/) By [Phil DiCorpo](https://www.tigera.io/blog/author/phil-dicorpo/) on Sep 3, 2026 A library of Calico tools and skills — delivered through the Calico MCP Server What if your hardest network question took ten minutes instead of ten days? Anyone who has operated Kubernetes networking at scale... [Read more](https://www.tigera.io/blog/meet-mylo-an-ai-native-way-to-work-with-calico/) [![The Safest Place to Run an AI Agent Is On a Cluster That Doesn’t Trust It](https://www.tigera.io/app/uploads/2026/08/The-Safest-Place-to-Run-an-AI-Agent-Is-On-a-Cluster-That-Doesnt-Trust-It.png)](https://www.tigera.io/blog/the-safest-place-to-run-an-ai-agent-is-on-a-cluster-that-doesnt-trust-it/) #### [The Safest Place to Run an AI Agent Is On a Cluster That Doesn’t Trust It](https://www.tigera.io/blog/the-safest-place-to-run-an-ai-agent-is-on-a-cluster-that-doesnt-trust-it/) By [Alister Baroi](https://www.tigera.io/blog/author/alister-baroi/) on Aug 27, 2026 Every organization running AI agents has already made a hosting decision. Most made it by accident. The sales team switched on the agent built into their CRM. Engineering is piloting a coding agent in a... [Read more](https://www.tigera.io/blog/the-safest-place-to-run-an-ai-agent-is-on-a-cluster-that-doesnt-trust-it/) [![AI Red Team Agents Automate Attacks on your AI Agents. Runtime Policies Automate their Defense.](https://www.tigera.io/app/uploads/2026/08/AI-Red-Team-Agents-Automate-Attacks-on-your-AI-Agents.-Runtime-Policies-Automate-their-Defense.png)](https://www.tigera.io/blog/ai-red-team-agents-automate-attacks-on-your-ai-agents-runtime-policies-automate-their-defense/) #### [AI Red Team Agents Automate Attacks on your AI Agents. Runtime Policies Automate their Defense.](https://www.tigera.io/blog/ai-red-team-agents-automate-attacks-on-your-ai-agents-runtime-policies-automate-their-defense/) By [Alister Baroi](https://www.tigera.io/blog/author/alister-baroi/) on Aug 24, 2026 The AI red teaming market grew up fast this year. OpenAI bought Promptfoo, Cisco and Microsoft shipped automated attack suites, and a seed-stage startup publicly compromised 50 of 55 live customer service bots. These platforms... [Read more](https://www.tigera.io/blog/ai-red-team-agents-automate-attacks-on-your-ai-agents-runtime-policies-automate-their-defense/)