We are excited to announce the new security capabilities of Tigera Secure Enterprise Edition 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.

Figure 1 –Three major network security problems with Kubernetes in a zone-based model

  1. 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.
  2. 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.
  3. 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.

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.

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.

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.

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. 

Learn more about how Tigera Secure extends your firewalls to Kubernetes in our upcoming webinar on May 21. Register here to attend.

 

Subscribe to our newsletter

Get updates on webinars, blog posts, new releases and more!

Thanks for signing up. You must confirm your email address before we can send you. Please check your email and follow the instructions.

Pin It on Pinterest

Share This