Zero trust for cloud-native workloads: Mitigating future Log4j incidents

In my previous blog post, I introduced the brief history of zero trust, the core pillars of a zero-trust model, and how to build a zero-trust model for cloud-native workloads. In this blog post, you will learn how Calico can help mitigate vulnerabilities, such as the recent zero-day Log4j vulnerability, with its zero-trust workload security approach.

Zero trust: A quick refresher

The starting point for building a zero-trust security model is understanding your attack and protect surface. The outcome of designing your security plan should be eliminating the attack surface completely.

Enterprises are realizing that the best approach to mitigating breaches and protecting their sensitive assets from both internal and external threats is by applying the three principles of zero trust to their security plan. These three principles are:

  1. Always use least-privilege access
  2. Always authenticate and authorize before providing access
  3. Always assume breach

While stakeholders are busy creating design architectures, collecting asset information, and considering tools required to achieve their zero trust goals, there are also new challenges that some decision-makers should consider. As microservices are becoming the de facto standard for application developers, it has introduced new technologies and methodologies for communicating with legacy systems. For these microservices, securing the entire gamut from build time to runtime, including securing workloads for ingress and egress access, is crucial for zero trust. To help you achieve this, I’ll illustrate the techniques necessary by using the Log4j vulnerability as an example.

Log4j and its vulnerability

It was truly The Nightmare before Christmas when the zero-day Log4j vulnerability was announced late last year. Log4j is a logging utility for Java-based applications that programmers can use so that user activity and application performance can be monitored. A security researcher from Alibaba’s cloud team found and reported a zero-day vulnerability (Log4shell) in the utility, and this led to panic among millions of users with applications getting hacked by attackers trying to steal data, install malware, and carry out other malicious activities. This could be performed using arbitrary/remote code execution (ACE/RCE) where hackers can remotely target endpoints running Apache’s Log4j logging framework.

Tigera’s developer advocate, Reza Ramezanpour, sheds more details on how the Log4j vulnerability works and how to protect containerized environments from Log4j or similar vulnerabilities using Calico’s security policies. You can follow the steps in his blog post to spin up a demo lab to see how the Log4j attack happens.

How does the Log4j vulnerability affect workloads?

Since the Log4j utility is used extensively by many popular applications running Java, your workloads may be running some form version of the Log4j library. Without the proper security policies in place to block communication to a threat actor’s LDAP server (which is most likely used in this case), your workloads could be a target for placing crypto mining software without your knowledge. It could also result in data exfiltration, where an attacker can use payload information to find out user credentials and secret keys in a public cloud (e.g., AWS EC2).

How can Tigera help?

Calico is Tigera’s active Cloud Native Application Protection Platform (CNAPP) that can detect, mitigate, and protect cloud-native applications from security incidents like the Log4shell vulnerability. Depending on the choice of installation, Calico can help security and DevOps engineers work with platform teams and other stakeholders to carve out custom security policies and egress access controls for zero-trust workload security.


What we see in this example screenshot from Calico Cloud’s image scanner is how it can automatically detect the Log4j package, with the version number, the container image, and the vulnerability ID associated with this package. As far as similar zero-day threats are concerned, Calico also uses machine learning to detect anomalies and other Indicators of Compromise (IoCs) to actively protect against runtime threats.


Let’s assume that we have identified multiple hosts running the affected version of the Apache logging utility. Traditionally, it would take multiple days or weeks to isolate or place these workloads in a DMZ and then manually apply patches and fixes. An ideal cloud-native solution will give you the ability to immediately identify the relevant workloads and pinpoint the affected workloads. This could be achieved with a combination of network segmentation and identity-aware microsegmentation. Both these techniques are a fundamental requirement for a zero-trust model.

Calico gives teams the ability to administer security policies and break them down into tiers, depending on team responsibilities (platform, security, application, etc.). This naturally isolates workloads based on the granular policies and achieves microsegmentation since the policies themselves use labels and selectors.


To protect against vulnerabilities such as Log4j, there is no one silver bullet. This is where we turn to a solid implementation of the zero-trust approach – —always start with ‘default-deny’. When we know that by default, Kubernetes lets all the pods communicate with each other without any restrictions—just like how a zero trust network access solution gives access to users on a per-need basis—then workloads should be given a similar restriction, and the only way to start is by implementing ‘default-deny’ for all resources. Calico was built upon the core principles of a defense-in-depth strategy where once you identify and locate the vulnerabilities in your network, you can automatically fire up security policies to deny traffic to and from the affected workloads. As part of remediation efforts, security enforcers should be looking at blocking, quarantining, or terminating the impacted pods.


With this holistic approach during build, deployment, and runtime in a cloud-native environment, platform and DevOps teams can work in concert with security teams for a robust zero-trust workload protection model.

Want to see how your organization fares in the zero-trust journey for cloud-native applications? Take our Zero Trust for Cloud-Native Workloads Maturity Assessment to find out now.

Join our mailing list

Get updates on blog posts, workshops, certification programs, new releases, and more!