Securing K8s Pods from Within | Rahul Jadhav @Cloud Native SecurityCon


The basic unit of execution is a pod.It mounts the service account tokens and k8s secrets. The binaries in the containers have equal, direct access to it

For Kubernetes, the basic unit of execution is a pod. All the binaries in all the containers have equal access to the volume mount points and thus have direct access to the service account tokens and k8s secrets that the pod mounts.

Almost all Kubernetes attacks exploit/leverage this fact. The only thing an attacker has to ensure is to inject a binary into the pod using a known/unknown vulnerability in any of the binaries within any of the containers.

Once the attacker injects a malicious binary, it has unrestricted access to the secrets in predefined volume mount points (we are making it so easy for the attacker!). Typically only a few binaries within the pod need access to the tokens/secrets. The access should be restricted to such a list of processes/binaries, and an automated framework should derive this list.

This is easier said than done, taking into consideration that the app is updated every few weeks, i.e., the security posture changes with the app updates. The sessions aim to highlight runtime security risks that are inherent to k8s design and possible solutions to alleviate some of these concerns.

Rahul is a dev/maintainer of KubeArmor (runtime security engine).

00:00:30 Why securing pods matter?
00:02:11 Static vs Admission vs Runtime
00:03:31 Restricting Pod Behaviour
00:04:34 Pod Security Context
00:07:13 Zero Trust Runtime Security

💻 Learn more about AccuKnox
Help Docs:
Get help with AccuKnox queries
Policy Templates:
💬 Follow AccuKnox on social media
✅ Subscribe to Accuknox's YouTube channel