Tigera Taps into Palo Alto Networks to Secure Kubernetes
Tigera announced this week it is bridging the divide between Kubernetes and traditional firewalls by integrating its zero-trust framework for cloud-native applications with tools and frameworks employed to manage traditional firewalls.
Andrew Wright, vice president of marketing for Tigera, says the first instance of that integration comes in the form of support for the Panorama framework from Palo Alto Networks in version 2.5 of Tigera Secure Enterprise Edition.
The goal is to make is easy for organizations to apply the same policies and controls they have already developed for the rest of the enterprise to Kubernetes clusters, says Wright. Tigera Secure is built on top of the open source Calico networking fabric for Kubernetes. In addition to Tigera Secure, the company offers a curated version of Calico for the enterprise as an alternative to legacy network virtualization overlays.
The inability to apply existing cybersecurity policies to Kubernetes clusters easily is a major inhibitor of adoption of Kubernetes in enterprise IT environments, says Wright. Cybersecurity teams don’t want to have to set up and manage separate policies for container firewalls, especially when containers are so ephemeral. Many cybersecurity teams are already chronically understaffed, so adding support for another platform creates a major resource allocation issue.
To address that issue, Tigera will continue to expand the number of existing firewall managers that integrate with Tigera Secure, which also includes its own container firewall, says Wright, adding Tigera is starting with Panorama because it’s the most widely employed by enterprise IT organizations.
Of course, every provider of an existing legacy firewall is hoping organizations will adopt the container firewalls they provide. Palo Alto Networks, for example, just acquired Twistlock. However, from a firewall manager perspective, Tigera is clearly trying to remove any objection cybersecurity teams might have about adopting a container firewall from another vendor. Not every policy applied to a legacy workload might be appropriate for a containerized application, but Wright says cybersecurity professionals and developers at least now have some common ground from which they can fine-tune existing cybersecurity policies when appropriate.
When most IT professionals are asked about the No. 1 issue associated with adopting any emerging IT platform, the answer is always the same: security. The paradox is that in the aggregate, containerized applications should be more secure because they are easier to update than legacy monolithic applications, which depend on cumbersome patch management processes. Right now, however, the DevSecOps processes that organizations would rely on to rip and replace containers that are either misconfigured or have encapsulated code with known vulnerabilities are still relatively immature.
In the meantime, the rate at which developers are now building containerized applications continues to accelerate. The expectation is those applications soon will be running on Kubernetes clusters, so eventually the DevSecOps process issue will be forced within most organizations. After all, as that backlog of containerized applications waiting to be deployed in a production environments steadily grows, the pressure on cybersecurity teams to find some way to secure those applications is only going to mount.