--- title: "Tigera Secure Enterprise Edition 2.4 Extends Firewalls to Secure Dynamic Kubernetes Workloads" source: "https://www.tigera.io/blog/tigera-secure-enterprise-edition-2-4-enables-firewalls-to-secure-dynamic-kubernetes-workloads/" --- [Company Blog](https://www.tigera.io/category/company-blog/) [Technical Blog](https://www.tigera.io/category/technical-blog/) # Tigera Secure Enterprise Edition 2.4 Extends Firewalls to Secure Dynamic Kubernetes Workloads By [Vince Lau](https://www.tigera.io/blog/author/vincetigera-io/) on May 15, 2019 • 4 min read We are excited to announce the new security capabilities of[Tigera Secure Enterprise Edition](https://www.tigera.io/tigera-products/compare-products/) 2.4. This release enables enterprise security teams to extend their firewalls and existing zone-based architectures to Kubernetes and enable fine-grained access controls to external resources. Tigera Secure 2.4 solves three major network security problems that security teams run into when deploying alongside firewalls. *![Tigera Secure 2.4 diagram](https://www.tigera.io/app/uploads/2019/05/fw1.png)* *Figure 1 –Three major network security problems with Kubernetes in a zone-based model* - Existing zone-based security architectures cannot be extended to Kubernetes because the workloads use ephemeral, dynamic IP addresses that cannot be used to identify a workload. Security teams resort to opening large IP ranges within their inline firewalls between security zones, allowing all Kubernetes traffic to flow through the architecture. - Modern applications often integrate with third-party APIs like Twilio, SaaS services like Zuora and Salesforce, and resources outside the cluster like AWS RDS databases and VMs. To enable those integrations to work, security teams must allow large IP ranges to egress through the firewall and are unable to provide fine-grained access to specific workloads. - Without the ability to recognize a workload identity, network flows cannot be logged properly. The data misses context that is unique to Kubernetes, such as namespace, pod name, labels, and container ID. Without this information, debugging service issues and performing forensic analysis is not possible. While Kubernetes workloads are growing rapidly they currently represent a small fraction of the workloads that a security team has to secure. Consequently, redesigning existing security architecture isn’t a feasible option since a significant investment has gone into acquiring technology, designing processes, and training teams. With Tigera Secure 2.4, security teams can now extend their current investments in technology and processes to support new Kubernetes workloads. Tigera Secure 2.4 solves these three major network security constraints with the following three simple steps. The process starts with implementing Zero Trust Network Security that forms a micro-firewall around each Kubernetes workload, providing visibility and enforcement within the zone. Next, Tigera Secure filters zone-to-zone traffic at the source to prevent any unintended traffic. Finally, North-South policies are applied to filter traffic to your APIs, Cloud Services, and SaaS platforms. With this approach, Tigera monitors all connection attempts and logs whether they were accepted or denied at the pod level to provide accurate visibility into all Kuberenetes workloads. The data is all integrated into your SIEM and provides the visibility and controls security teams were lacking for Kubernetes deployments within their security architecture. *![security architecture diagram](https://www.tigera.io/app/uploads/2019/05/fw2.png)* *Figure 2 –Tigera 2.4 extends firewalls to Kubernetes in a zone-based network using either physical or logical zone architectures*   The highlights from this release include DNS Policies, Threat Defense, Compliance Dashboard and Reporting, and easier installation options. ## DNS Policies DNS Policies enable fine-grained access controls between individual Kubernetes pods and resources outside the cluster—on-prem and in the cloud. Teams can easily enable egress access to third-party APIs like Twilio, SaaS services like Zuora and Salesforce, and resources outside the cluster like ElastiCache, RDS databases, and VMs. ![DNS Policies screenshot](https://www.tigera.io/app/uploads/2019/05/2.4-f1.png) *Figure 3 – Egress policy rule to external resources within Tigera Secure Enterprise Edition 2.4*   ## Threat Defense Threat Defense ingests your Threat Intelligence Feed and blocks traffic from leaving your Kubernetes pods to IPs known for malicious activity. Attacks involving malware are unable to phone home for data exfiltration. *![Suspicious IP screen](https://www.tigera.io/app/uploads/2019/05/2.4-f2.png)* *Figure 4 – Detailed Kubernetes flow logs about suspicious IP connection*   ## Compliance Dashboard and Reporting Tigera Secure can be used to implement an organizations security controls and prevent tampering with those controls. Those security controls and evidence that those controls are enforced are mapped to compliance requirements that auditors need to see in order to complete an audit or issue a certificate. Compliance framework can be internal to the business based on their own risk profiles, or external frameworks such as PCI, SOC 2, and others. With Tigera Secure 2.4, evidence reports are easier to customize and generate based on the security controls defined by your business. Teams can define in-scope workloads and generate inventory, network access, and policy audit reports that quickly provide evidence auditors request. In addition, the dashboard offers graphical reporting features to help organizations quickly understand their security status. Tigera Secure implements Continuous Compliance enabling you to pull historical evidence reports to prove compliance at any given point in time, and actively monitors for adherence to security controls to alert immediately when there is a potential violation of those controls. ![Compliance Reports screen](https://www.tigera.io/app/uploads/2019/05/2.4-f3.png) *Figure 5 – Compliance dashboard displaying protected assets within Tigera Secure Enterprise Edition 2.4* ## Easy Installation Options Enables easier and quicker deployments with Helm charts. Helm charts enable the customization of settings that allow the installation of the product with one simple command. ————————————————- [**Free Online Training**](https://www.tigera.io/events/) Access Live and On-Demand Kubernetes Tutorials [**Calico Enterprise – Free Trial**](https://www.calicocloud.io/home) Solve Common Kubernetes Roadblocks and Advance Your Enterprise Adoption [Products](https://www.tigera.io/tags/products/)[Announcements](https://www.tigera.io/tags/announcements/) ## 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/)