The EDR business model relies on a paradox: your security vendor needs your systems to stay vulnerable to keep their subscriptions active. If your kernel isn't mutable, their software is useless. Not only can it not be installed, but it has nothing to protect against. Talos Linux breaks that cycle. No Shell. No loadable kernel modules. No Writable Filesystem. We didn't just build a more secure OS; we removed the architecture that makes it insecure in the first place. You can't install EDR agents on Talos because, with an immutable and API-driven OS, the agent model is obsolete. Stop paying for better doormen. Use buildings that don't need them. #CyberSecurity #TalosLinux #CloudNative #Kubernetes #Infosec
That's not totally true and the framing conflates two different threat planes. Talos is an excellent host-hardening layer: no shell, no SSH, no writable filesystem. You've dramatically reduced the host attack surface. Respect for that. But the threat model doesn't stop at the OS. Containers still run workloads. And that's where runtime threats live: - A compromised container can still exfiltrate data, make C2 callbacks, or abuse K8s API permissions regardless of OS immutability - Kernel exploits (dirty pipe, runc escapes) don't care if the filesystem is read-only - Cryptominers, reverse shells, and credential theft happen inside the container, not on the host FS - East-west lateral movement between pods is invisible to Talos by design The agent model isn't obsolete, it just moved. eBPF-based runtime detection doesn't need to write to the filesystem. It hooks into the kernel at the syscall level, which works perfectly on immutable OS like Talos. Talos closes the front door. You still need visibility into what happens inside the building.
You can totally deploy various EDR on Talos (as Daemonset) since most of them are now eBPF based. Works just fine.
But there’s always compliance reason for EDR to at least exist in the cluster, what would you recommend in such case? Like a placeholder EDR simply install but do nothing?
Even with Talos if someone gained access to the kubeconfig file you can still technically add a malicious machine config file to the cluster that makes changes to those kernel files