I've hit a major roadblock with our current container security strategy. We're managing over 400 workloads across 12 EKS clusters, and every vendor seems to insist on injecting their agent into our containers. The problem is that we now have three different sidecars per pod for runtime protection, vulnerability scanning, and compliance. This has caused our base images to balloon from 200MB to over 800MB, and our node CPU overhead has increased by 15-20%. Recently, our staging cluster crashed under a load test due to improperly tuned resource limits for these agents, and the ops team is suggesting we disable security tools altogether. I've been hearing a lot about agentless security approaches that scan from the control plane or utilize eBPF without needing per-container deployments. Is anyone here successfully using agentless security at scale? What are the real trade-offs between detection coverage and operational efficiency?
4 Answers
There's no need for sidecars for vulnerability scanning. You can achieve this with more straightforward methods. DaemonSets work well for runtime security without the overhead of multiple agents. Keep it simple and efficient!
This reminds me of the early antivirus days where running multiple security tools just slowed everything down. It's counterproductive to have so many agents that your systems become unusable. We need to streamline rather than complicate security measures.
Right? It’s about balancing security with usability, not overloading with agents.
I think agentless solutions are the way to go. For Kubernetes at scale, any kind of agent sprawl leads to performance issues. We're using Orca Security, which scans from outside the cluster without impacting node performance. It has great coverage for vulnerabilities too!
Exactly! Having agents in every container is outdated and really bloats resources. We should be looking for smarter solutions.
Shifting security left is key. It's all about trust in your toolchain. Chainguard is a solid choice, but you need to ensure your repos and binaries are secure before they're packed into images. If your security team wants to scan what's live in production, just give them an SBOM (Software Bill of Materials) to audit. Moving away from Istio and sidecars is a smart move; consider using distroless images or eBPF for better performance without the bloat.
Totally agree! Setting up your clusters so that containers that don’t meet security standards can't even start is crucial. For instance, using Kyverno can prevent non-compliant containers from running. Don't give overly permissive capabilities to workloads and avoid running as root unless absolutely necessary.
100% agree with your points! Focus on tightening security standards will really help minimize the attack surface.
Absolutely! It's much more sensible to manage security at the node level rather than cluttering with sidecars.