The pod is running, but something feels off. Logs show strange traffic. CPU spikes without clear cause. You suspect the sidecar. The term for this: Rasp Sidecar Injection. It’s not theory—it’s an attack pattern engineers face in production.
RASP stands for Runtime Application Self Protection. When deployed as a sidecar container, it monitors and intercepts application calls, blocks malicious input, and enforces policy at runtime. But Rasp Sidecar Injection flips this approach. Here, the attacker injects a rogue sidecar or manipulates an existing one, turning a security tool into a foothold. Instead of defense, the compromised sidecar now exfiltrates data, rewrites traffic, or hijacks service communication.
How Rasp Sidecar Injection Works
- The attacker gains deploy privileges in a cluster.
- They launch or alter a sidecar targeting the main app container.
- The sidecar hooks APIs, reads requests and responses, intercepts secrets from environment variables or token mounts.
- It sends the collected data out-of-band.
Because Kubernetes sidecars share the pod network namespace and can mount volumes, the blast radius is immediate. Network policy gaps, unrestricted service accounts, and weak admission controls make injection faster and harder to detect.