mrvitej.in

Archive · Kubernetes

Log4Shell and Your Containers

CVE-2021-44228 affects Java applications using Log4j 2. How to find and fix it across images.

1 min read

  • Log4j 2.17.0
  • CVE-2021-44228
  • Trivy
  • Kubernetes 1.23

On 9 and 10 December 2021 a critical remote code execution flaw in Apache Log4j 2 (CVE-2021-44228, “Log4Shell”) was disclosed. Follow-up fixes came quickly, so the target version has moved: as of 20 December use Log4j 2.17.0 (2.15.0 and 2.16.0 were not enough).

Find affected workloads:

# which images are running in the cluster
kubectl get pods -A -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' | sort -u

# scan an image for the vulnerable library
trivy image --severity CRITICAL myorg/api:3.4 | grep -i log4j

Remember log4j can hide in fat JARs, so scan the image contents, not only your pom.xml.

Actions, in order:

  1. Upgrade Log4j to 2.17.0 and rebuild images.
  2. Redeploy, then confirm the running pods use the new image digest.
  3. Where you cannot patch yet, block outbound traffic from pods with a NetworkPolicy; the attack needs the server to call out.
  4. Check logs for jndi: strings.

Vendor products such as Elasticsearch or Kafka tooling may need their own patches.