Preventing Bank Heists and AI Takeovers in Kubernetes
summary
Describes using KubeArmor policies to stop runtime attacks on AI workloads: validate models as OCI model signing before deploy, apply a Jupyter notebook policy scoped to app=JupyterHub that whitelists python, forces read‑only on /usr/bin and user bins, and blocks unknown binaries so remote code execution can’t install packages or modify models; protect GPUs by making /usr/lib/nvidia read-only to prevent driver tampering and cryptojacking; argues zero‑trust whitelists beat long blocklists.
AI-written summary · about
chapters (13)
- 0:00Introduction
- 1:56AI workloads in Kubernetes
- 2:40Bank heist security analogy
- 4:27Malicious AI scenarios
- 5:52Attack vectors in AI systems
- 7:17Jupyter notebooks risks
- 9:04Cube Armor runtime security
- 10:50Cube Armor for Jupyter Hub
- 12:55GPU access and cryptojacking
- 14:21GPU risks in containers
- 15:44Cube Armor for GPU libraries
- 16:26Key takeaways
- 17:07Q&A
related talks
21mSecurity Best Practices for AI on Kubernetes
28mKubeArmor: Applying Security Policies with Practical Examples in K8S
16mKeynote: Defending AI on Kubernetes: Red Team Playbook
25mSecuring AI Pipelines: Real-World Attacks on Kubernetes-Based AI Infrastructure
25mWhat We Learned Securing AI Agents at Scale on Multi-Tenant Kubernetes Clusters
22mSecuring Kubernetes
30mSecuring AI Workloads: Building Zero-Trust Architecture for LLM Applications
36mHow to Prevent Your Kubernetes Cluster From Being Hacked — Nico Meisenzahl and Philip Welz