What is Sidecar Injection?

Sidecar Injection Explained

In Kubernetes, a Pod is the smallest deployable unit and can contain one or more containers that share the same network namespace, storage volumes, and lifecycle. A sidecar container is a secondary container deployed alongside the main application container within the same Pod. Legitimate sidecars handle cross-cutting concerns like network proxying (Envoy in Istio), log collection (Fluentd), or security monitoring - tasks that are not part of the application logic but are essential for infrastructure operations.

Sidecar injection is the mechanism that adds these containers automatically. Rather than requiring developers to manually define sidecars in every Pod manifest, Kubernetes uses mutating admission webhooks to intercept Pod creation requests and transparently modify the Pod specification to include the sidecar container before it is scheduled.

This is a powerful and elegant mechanism for infrastructure automation. It is also, from an attacker's perspective, one of the most effective techniques for achieving stealth, persistence, and privilege escalation within a compromised Kubernetes cluster.

How Sidecar Injection Works Under the Hood

Understanding the injection mechanism is essential for both defenders and attackers. The process relies on the Kubernetes admission control pipeline.

1. Pod Creation Request: A user or controller submits a Pod creation request to the Kubernetes API server (e.g., via kubectl apply or a Deployment rollout).
2. Authentication and Authorization: The API server authenticates the request and checks RBAC policies to confirm the caller has permission to create Pods in the target namespace.
3. Mutating Admission Webhooks: Before the Pod is persisted to etcd, the API server sends the Pod spec to any registered mutating admission webhooks. These webhooks can modify the Pod spec - adding containers, volumes, environment variables, annotations, or security contexts. This is where sidecar injection happens.
4. Validating Admission Webhooks: After mutation, the modified Pod spec passes through validating webhooks that can accept or reject the request but cannot modify it.
5. Pod Scheduling: The finalized Pod spec is written to etcd and the scheduler assigns it to a node. The kubelet on that node pulls the container images and starts all containers - including the injected sidecar.

The critical point is step 3. Any entity that can register or modify a mutating admission webhook, or that can directly patch Pod specifications and Deployment objects, can inject arbitrary containers into any workload in the cluster.

Sidecar Injection as an Attack Technique

An attacker who has gained a foothold inside a Kubernetes cluster - through a compromised pod, stolen service account token, or exploited application vulnerability - can abuse sidecar injection to escalate privileges, move laterally, and persist within the environment. The technique is particularly dangerous because the malicious container lives inside a Pod that the organization already trusts.

Prerequisite: Sufficient RBAC Permissions

Malicious sidecar injection requires the attacker to have one of the following:

• Pod or Deployment modification privileges: The ability to patch, update, or create Deployments, DaemonSets, StatefulSets, or Pods in a target namespace. This is the most common path - many service accounts are granted overly broad RBAC permissions like verbs: ["*"] on workload resources.
• Webhook configuration access: The ability to create or modify MutatingWebhookConfiguration objects. This is a cluster-level privilege that allows the attacker to register a rogue webhook that injects containers into every new Pod in targeted namespaces.
• Cluster-admin or equivalent: Overly permissive role bindings (such as granting cluster-admin to a service account) give attackers unrestricted access to all injection paths simultaneously.

In practice, overly permissive RBAC is extremely common. A Red Hat survey found that nearly 90% of organizations experienced at least one container or Kubernetes security incident in the past year, with RBAC misconfigurations being one of the top causes.

Attack Path 1: Patching Existing Workloads

The most straightforward approach. If the attacker has permissions to modify Deployments or StatefulSets, they can patch the Pod template to add a malicious container. When the Deployment controller detects the spec change, it triggers a rolling update - replacing existing pods with new ones that include the injected sidecar. The update looks like a normal deployment rollout in the cluster's audit logs.

The injected sidecar shares the Pod's network namespace (allowing it to intercept traffic on localhost), has access to the same mounted volumes (including service account tokens at /var/run/secrets/kubernetes.io/serviceaccount/), and inherits the Pod's security context. If the original Pod was running with elevated privileges, the sidecar inherits those privileges immediately.

Attack Path 2: Rogue Mutating Webhook

A more sophisticated and persistent approach. The attacker registers a new MutatingWebhookConfiguration that targets Pod creation events in specific namespaces (or cluster-wide). The webhook points to an attacker-controlled service (which could be running as a Pod within the cluster itself) that intercepts every Pod creation request and silently adds a malicious container to the spec before returning the modified Pod to the API server.

This is extremely stealthy because the injection happens automatically and invisibly for every new Pod. The webhook can be configured with namespace selectors to target only high-value namespaces, and the injected container can use an image that mimics a legitimate sidecar (like naming it istio-proxy or fluentd) to avoid detection during casual inspection.

Attack Path 3: DaemonSet Abuse

If the attacker can create DaemonSets, they can deploy a container that runs on every node in the cluster. While not technically sidecar injection (the container runs in its own Pod), the effect is similar - the attacker achieves cluster-wide presence. If the DaemonSet is given a hostPID, hostNetwork, or hostPath mount, it can interact directly with the host operating system on every node.

What an Injected Sidecar Can Do

Once a malicious sidecar is running inside a target Pod, the attacker has significant capabilities due to the shared namespace model of Kubernetes Pods.

Capability	How It Works
Traffic Interception	The sidecar shares the Pod's network namespace. It can listen on localhost, intercept HTTP/gRPC traffic between the application and other services, or proxy traffic through itself to capture credentials, API keys, and session tokens in transit.
Service Account Token Theft	Every Pod mounts a Kubernetes service account token at a known path. The sidecar can read this token and use it to authenticate to the Kubernetes API as the Pod's service account, inheriting whatever RBAC permissions that account has.
Secret and Volume Access	The sidecar has access to all volumes mounted into the Pod - including Kubernetes Secrets, ConfigMaps, and persistent volumes. Credentials, TLS certificates, database connection strings, and application configuration are all accessible.
Environment Variable Harvesting	Application containers often receive credentials and configuration via environment variables. While the sidecar cannot directly read another container's env vars, it can access them indirectly through the Kubernetes API (if the service account has sufficient permissions) or through the shared filesystem.
Data Exfiltration	The sidecar can establish outbound connections to exfiltrate stolen data - service account tokens, intercepted traffic, secrets, and application data - to an attacker-controlled endpoint, unless egress network policies are in place.
Persistence	If injected via a Deployment patch or webhook, the sidecar persists across Pod restarts, scaling events, and even cluster upgrades. The malicious container is part of the desired state - Kubernetes will actively ensure it keeps running.

Real-World Attack Chains

Malicious sidecar injection rarely happens in isolation. It is typically one stage in a larger attack chain that begins with initial access and escalates toward cluster compromise or cloud account takeover.

From Application Vulnerability to Cluster Breakout

A common attack chain in Kubernetes environments starts with exploiting an application vulnerability (such as SSTI, SSRF, or SQL injection) to gain command execution inside a pod. From there, the attacker checks the pod's service account permissions using kubectl auth can-i --list. If the service account has overly permissive RBAC - such as the ability to read secrets, create pods, or modify deployments - the attacker can escalate significantly.

With secret-reading permissions, the attacker can extract credentials stored in Kubernetes Secrets (often only base64-encoded, not encrypted). With pod-creation or deployment-modification permissions, they can inject sidecars into existing workloads or create new privileged pods that mount the host filesystem, ultimately breaking out of the container entirely. A service account with cluster-admin privileges - which is far more common than it should be - gives the attacker unrestricted control over the entire cluster.

To walk through this exact attack chain - from SSTI exploitation through RBAC abuse to Kubernetes breakout via a privileged pod with host volume mounts - try the Exploit Kubernetes Overly Permissive RBAC lab on Pwned Labs.

Service Mesh Hijacking

In clusters running a service mesh like Istio, every application pod already has an Envoy sidecar proxy handling mTLS encryption between services. If an attacker compromises the Istio control plane or gains permissions to modify the sidecar injection webhook, they can replace the legitimate Envoy proxy with a modified version that logs all decrypted traffic before re-encrypting and forwarding it. This gives the attacker visibility into every service-to-service communication in the mesh - effectively defeating the mTLS protection that the service mesh was deployed to provide.

Supply Chain Poisoning

Attackers have been observed targeting the container images used by legitimate sidecar injection systems. By compromising the image registry or the CI/CD pipeline that builds sidecar images, an attacker can ensure that every pod in the cluster receives a backdoored sidecar through the normal, trusted injection process. Security teams have no reason to suspect the injected container because it arrived through the expected mechanism.

Detection Strategies

Detecting malicious sidecar injection requires monitoring at multiple layers of the Kubernetes stack.

• Audit Log Analysis: Monitor Kubernetes audit logs for unexpected PATCH operations on Deployments, StatefulSets, and DaemonSets that add new containers. Alert on any modification to MutatingWebhookConfiguration resources, as creating or altering a webhook is a high-privilege action that should be rare and tightly controlled.
• Pod Spec Drift Detection: Compare running pod specifications against the expected definitions in source control or the Helm chart. Any container that exists in a running pod but is not defined in the original manifest is a strong indicator of injection.
• Image Allowlisting: Enforce policies (via OPA Gatekeeper, Kyverno, or a validating admission webhook) that only permit containers from a trusted registry and a predefined list of images. Unknown images in pods should trigger an alert.
• Network Anomaly Detection: Unexpected outbound connections from pods - especially to external IP addresses - can indicate data exfiltration by an injected sidecar. Egress monitoring and network policies are essential.
• Service Account Permission Auditing: Regularly audit which service accounts have permissions to modify workloads or webhook configurations. Suspicious activity related to potential service account token theft has been observed in 22% of cloud environments.

Prevention and Mitigation

Preventing malicious sidecar injection requires enforcing the principle of least privilege across RBAC, admission control, and network policies.

Lock Down RBAC

The most critical control. Service accounts should never be granted cluster-admin or wildcard (*) permissions. Pods should run with service accounts that have the minimum permissions required for their function. The ability to create or modify Deployments, DaemonSets, and MutatingWebhookConfigurations should be restricted to a small number of tightly audited identities. Every unnecessary permission is a potential injection vector.

Enforce Pod Security Standards

Use Kubernetes Pod Security Standards (or a policy engine like OPA Gatekeeper or Kyverno) to enforce restrictions on Pod specifications. Block privileged containers, host namespace access (hostPID, hostNetwork, hostIPC), and host path volume mounts. These restrictions limit what an injected sidecar can do even if the injection itself succeeds.

Protect the Admission Control Pipeline

• Restrict webhook management: Only cluster administrators should be able to create or modify MutatingWebhookConfiguration and ValidatingWebhookConfiguration resources.
• Verify webhook integrity: Ensure webhook endpoints use TLS with certificate validation. An attacker on the container network with NET_RAW capability can attempt MITM attacks against unencrypted webhook traffic.
• Audit webhook configurations: Regularly review registered webhooks and verify they point to expected, legitimate services.

Network Policies

Apply default-deny egress policies per namespace and only allow outbound traffic to explicitly required destinations. This limits an injected sidecar's ability to exfiltrate data or communicate with an attacker-controlled command and control server. Without egress restrictions, any compromised container has unrestricted outbound network access.

Image and Supply Chain Security

Sign container images and enforce signature verification at admission time. Use a private registry with strict access controls. Regularly scan sidecar images (including service mesh proxies) for vulnerabilities and unexpected modifications. Monitor CI/CD pipelines that build these images for signs of compromise.

Related Labs

Practice Kubernetes security concepts related to sidecar injection and pod security:

• Exploit Kubernetes Overly Permissive RBAC - Exploit SSTI to gain pod access, abuse overly permissive RBAC to escalate privileges, and break out of Kubernetes through a privileged pod with host volume mounts.

Frequently Asked Questions

What is sidecar injection in Kubernetes?

Sidecar injection is a mechanism that automatically adds a secondary container to a Pod at creation time, typically through a mutating admission webhook. Legitimately, it is used for service mesh proxies, logging, and monitoring. From an offensive perspective, it is a technique for injecting malicious containers into trusted workloads to intercept traffic, steal credentials, and maintain persistence.

What permissions does an attacker need for malicious sidecar injection?

The attacker needs either the ability to modify workload resources (Deployments, StatefulSets, DaemonSets, or Pods) in the target namespace, or the ability to create or modify MutatingWebhookConfiguration resources at the cluster level. Overly permissive RBAC - particularly service accounts with wildcard permissions or cluster-admin bindings - is the most common enabler.

Why is sidecar injection hard to detect?

Injected sidecars run inside Pods that the organization already trusts. If the injection is done via a Deployment patch, it appears as a normal rolling update. If done via a webhook, it happens invisibly on every new Pod. The malicious container can be named to mimic legitimate sidecars (like istio-proxy) and use images from the organization's own registry if the supply chain is compromised.

How does sidecar injection relate to container breakout?

Sidecar injection and container breakout are often stages in the same attack chain. An attacker who gains RBAC permissions through an initial pod compromise can inject a privileged sidecar (or create a new privileged pod) that mounts the host filesystem, effectively breaking out of the container environment and gaining access to the underlying node. From there, they can access other pods, steal node-level credentials, and move laterally across the cluster.

What is the most important defense against malicious sidecar injection?

Strict RBAC enforcement. If service accounts cannot modify workloads or webhook configurations, the injection cannot happen. Combine this with pod security standards (blocking privileged containers and host mounts), image allowlisting, default-deny network policies, and continuous audit log monitoring for the most effective defense-in-depth posture.