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).