Portshift Takes Vulnerabilities Management to the Container Level
While tying security policies to IP addresses may have been a practice that worked well enough for some legacy applications, the nature of ethereal, short-lived, portable and highly-scalable containerized workloads can mean that IP addresses are no longer a reliable identifier. Furthermore, an IP address is most commonly connected with a running workload, and not the code connected with it as it makes its way through a continuous integration and continuous delivery (CI/CD) workflow. As such, Portshift provides an identity-based workload protection platform for containers and microservices that can assign digital identities to containers within the CI/CD phase, and has now extended this capability to deliver runtime policies for vulnerability remediation.
Portshift works together with the open source service mesh Istio to provide its identity-based security, which, in part, offers this ability to change policies dynamically. Earlier this year, the company launched its Policy Advisor functionality, which automates rule creation for communication between microservices and allows users to change rules on the go, according to different requirements. Now, Portshift is not only able to provide rule changes dynamically, but it connects this with a risk mitigation engine that “connects Kubernetes network policies with discovered vulnerabilities in production workloads, allowing it to mitigate the risk potential of vulnerable containers until its replacement with new version that removes the vulnerable component,” according to a company statement. Currently, Portshift provides security scanning by connecting with a number of security providers, including Clair, Aqua Security, and Twistlock.
The new functionality allows Portshift to handle security on a pod-by-pod basis and provides a granular policy enforcement not previously available, that goes beyond simply taking an entire application offline when a vulnerability is discovered.
“Currently, most solutions that handle vulnerabilities are stopping at the CI/CD level, meaning either the CI/CD approved and you’re fine, or it stopped you and you’re not deployed. This is a binary decision done offline in the CI/CD. We tried to bring it to the runtime level, meaning once you deployed, we can also enforce it,” said Portshift co-founder Zohar Kaufman, in an interview with The New Stack. “We connected our policies with the other characteristics of the pod, namely the vulnerabilities of the pod. Once we have the scanning results of a pod, we can make smart decisions regarding whether this pod can or can not run in production, for example, and whether we let it run, but limit the communications of a vulnerable pod to a sensitive assets like the financial database.”
When we last spoke with Portshift at Kubecon + CloudNativeCon last month, they highlighted this ability to offer greater granularity as one of the key features of Portshift. Kaufman again highlighted this aspect, noting, on an even more basic level, the use of workload identity at this granular level also lets users identify what workloads can run where, preventing something meant only to run in a testing environment from ever making its way to production. Taking this granular approach to handle vulnerabilities in individual pods was simply an obvious next step.
Kubecon + CloudNativeCon, Palo Alto Networks, Portshift is a sponsor of The New Stack.
Feature image via Pixabay.
