Security Observability with eBPF

Chapter 1. The Lack of Visibility

Kubernetes has become the de facto cloud operating system, and every day more and more critical applications are containerized and shifted to a cloud native landscape. This means Kubernetes is quickly becoming a rich target for both passive and targeted attackers. Kubernetes does not provide a default security configuration and provides no observability to discern if your pods or cluster has been attacked or compromised.

Understanding your security posture isn’t just about applying security configuration and hoping for the best. Hope isn’t a strategy. Just like the site reliability engineering (SRE) principle of service level objectives (SLOs) that “[identify] an objective metric to represent the property of a system,”¹ security observability provides us with a historical and current metric to represent the objective security properties of a system. Security observability allows us to “assess our current [security] and track improvements or degradations over time.”²

With security observability, we can quickly answer:

• How many pods are running with privileged Linux capabilities in my environment?

• Have any workloads in my environment made a connection to “known-bad.actorz.com”?

• Show me all local privilege escalation techniques detected in the last 30 days.

• Have any workloads other than Fluentd used S3 credentials?

Achieving observability in a cloud native environment can be complicated. It often requires changes to applications or the ...