Why Containers are Susceptible to Ransomware (& How Zerto Can Help!)
No application is safe from ransomware. In 2022, IDC conducted a study to understand the evolving requirements for ransomware and disaster recovery preparation. This study uncovered a demand for data that has never been greater, and yet the vulnerability and risks to data integrity are escalating, with ransomware attacks growing in both severity and scale. The IDC study found that 79% of those surveyed activated a disaster response, 83% experienced data corruption from an attack, and nearly 60% experienced unrecoverable data.
This vulnerability is particularly alarming for organizations that are refactoring their applications for Kubernetes and containers. “Refactoring” an application means breaking it down into many different “services” which can be deployed and operated independently. This breakdown allows for a more efficient use of the application’s underlying hardware and increases scalability, as each “service” making up the app can scale as necessary without interrupting other services. While the benefits may seem great in theory, refactored applications must first overcome unexpected challenges.
Challenges with Refactoring Applications
Another IDC study that examined container adoption highlights this issue. The study shows that most containerized applications are refactored legacy applications, meaning they are already operational on either a bare-metal server or a virtual machine. Refactoring for containerized environments has proven to be complex, and the most-cited challenge was adapting existing processes to support the newly containerized applications. There’s a gap between the perceived benefits of containerization and the realization of those benefits. Those adopting containers expect improved security and operational efficiency, but they have quickly realized that data protection and security concerns are the biggest challenges after they refactor their applications to operate, usually using Kubernetes and containers.
Ensuring containerized applications are protected against ransomware, malware, and other security threats will have the most impact on repatriation (or reverting to how the application was running before). Those responsible for refactoring applications should specifically address the top container security risks by either working with native features or seeking integrations with a data protection solution that helps address these concerns.
Here are a couple of examples of Kubernetes vulnerabilities which can act as entry points to malicious actors:
- Pods are an integral part of Kubernetes deployments, as they host the containers running each application process. Inter-Pod communications run the risk of being attacked. In Kubernetes, each Pod has an IP address. A Pod can communicate with another Pod by directly addressing its IP address, but the recommended way is to use Services. A Service is a set of Pods, which can be reached by a single, fixed DNS name or IP address. Most applications on Kubernetes use Services to communicate with each other, which can expose access to the Pod or, since they are frequently restarted, creates a networking issue within the cluster.
- Supply Chain Attacks – containerized applications are designed to be automated, and this is true especially for updating code. Some Kubernetes deployments may be coded to keep pulling the “latest” Pod of an application without checking what updates were made or possible vulnerabilities exposed.
Heightening these known vulnerabilities is a skills and knowledge shortage of those who develop and deploy production applications with containers. An application lacking data protection and security as part of developer workflows leaves containerized applications susceptible to a myriad of vulnerabilities ransomware could exploit. To help mitigate against ransomware attacks, organizations need to not only carefully identify which applications should be refactored but consider the integration of data protection solutions early on. Developers should integrate data protection into their workflows, layering inherent security and recoverability into the application.
The IDC study indicates that organizations refactoring legacy applications to containerized ones are encountering a couple of other challenges. Legacy data protection won’t work with newly containerized apps without some heavy adjustments, but many related processes, such as analytics and security, also need to be modified. These efforts seem futile. Most concerning is that over half of respondents plan on reverting most of what they already containerized. This means undoing work, wasting both time and money. It’s interesting that the most likely candidates for repatriation are databases and other critical workloads, making the effort particularly painful because there is a strong connection between security concerns and criticality of these containerized applications.
Want to read more about the State of Ransomware for Kubernetes? Check out the IDC whitepaper The State of Ransomware and Disaster Preparedness.
CDP-As-Code
To keep their legacy and containerized applications safe at all stages of the supply chain, organizations need a solution to continuously protect them through the refactoring process and beyond.
Zerto for Kubernetes extends our enterprise-class virtual machine (VM) and cloud platform to cloud native applications that are built on containers. The native Kubernetes solution drives a “data protection as code” strategy, integrating backup and disaster recovery operations into the application development lifecycle from day one. This means that applications are born protected.
As more enterprises adopt containers and Kubernetes architectures for their applications, the reliance on microservices requires a solid data protection strategy. Continuous data protection (CDP) ensures your data protection strategy can keep up with the fast-paced world of containers.
True protection doesn’t just include persistent data. You must be able to protect, move, and recover a containerized application as one consistent entity, including all associated Kubernetes objects and metadata. Zerto for Kubernetes protects your applications’ persistent volumes as well as their associated entities, such as deployments, StatefulSets, Secrets, ConfigMaps, and Services.
Using Zerto for Kubernetes’ continuous data protection and journaling technology gives you the freedom to simply rewind to a previous checkpoint, delivering the lowest recovery point objective (RPO) available and minimizing any data loss. Zerto provides this outcome without utilizing any type of snapshot or interfering with the storage platform you have chosen.
When you combine Zerto’s industry-leading CDP and journaling technology, Zerto for Kubernetes provides the best disaster recovery and data protection for Kubernetes workloads whether running on-premises or in the cloud.
How To Escape Ransomware Today with Zerto for Kubernetes
Replicate and restore locally within a single cluster leveraging Zerto for Kubernetes. Quickly roll back and restore from any checkpoint in the journal without disrupting your current deployment.
Backup to a Cloud Bucket
It doesn’t hurt to back up a copy of a Kubernetes application which is optimally operating. Zerto for Kubernetes enables you to retain a copy of a Kubernetes application to an Azure Blob Storage or AWS S3 Bucket for the long-term.
Disaster Recovery & Data Protection All-In-One
In the event of an outage due to a ransomware attack completely taking your primary site down, Zerto for Kubernetes helps users fight back by performing a failover live operation. This directly brings the application online seamlessly at another location. Zerto for Kubernetes allows for this near real-time replication and recovery of Kubernetes applications to occur between two or more sites. Once you validate the application is running correctly at the desired point of recovery on another site, you can move the workload to production.
Strong security practices demand the frequent testing of disaster recovery solutions as well. The Zerto for Kubernetes failover test workflow can help check that box. Users can bring an application up on the secondary in an isolated namespace while the production version of the app continues to run unaffected.
This granular level of replication and recoverability has quite a few benefits aside from just validating that the recovery site works prior to an actual event. Consider use cases like using any of the available Zerto checkpoints to troubleshoot reported issues of an application in isolation, or to perform forensic analysis against hacker-impacted workload.
Find Safety in a New Cloud
Zerto for Kubernetes empowers you not only with the ability to recover to nearly any point in time but do so in a completely different cloud. Zerto for Kubernetes is compatible with all enterprise Kubernetes platforms, allowing data to move to where each of your applications needs to run without locking you into a specific storage platform or cloud vendor.
Where you deploy Zerto is entirely up to you: The control plane, called the Zerto Kubernetes Manager, can be deployed within a production cluster or within a DR or secondary cluster that’s typically in a different region from production. Alternatively, you can host the Zerto Kubernetes Manager in its own standalone cluster—even one running on a different cloud from everything else.
Remember, it is always best to test your disaster recovery capability without disrupting what’s running now. As mentioned earlier, Zerto for Kubernetes allows that exact functionality with failover tests. You can see your application running live in a completely different public cloud provider with just a few simple commands.
An increase in ransomware attacks coupled with the unique vulnerabilities of containerized apps makes disaster recovery a must for modern workflows. Without it, you might refactor your apps while inadvertently leaving your most critical workloads open to attack.
Ready to get hands on with Zerto for Kubernetes? Use our free hands-on labs to try it today: www.zerto.com/labs
Anthony Dutra 
