Guest post originally published on the Tigera blog by Giri Radhakrishnan

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 to mitigate vulnerabilities, such as the recent zero-day Log4j vulnerability, with a 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 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 to identify and isolate workloads running Log4j

To identify and isolate workloads running Log4j, you need a solution that helps 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. This solution should detect, mitigate and protect:


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 you’re doing with your zero-trust security posture for cloud-native workloads? Use this free zero trust maturity assessment tool to find out.