Google Cloud makes Wiz Runtime Sensor a managed GKE add-on in preview

Google Cloud has made Wiz's kernel-level runtime sensor available as a managed add-on for Google Kubernetes Engine, according to a dev.to writeup of the announcement. Unveiled on 17 October 2026 and currently in preview, the add-on works on both Standard and Autopilot clusters. GKE takes responsibility for deploying the sensor, injecting its credentials and updating it, absorbing operational chores that traditionally fell on whichever team happened to hold the security vendor's licence.

What the sensor observes

Container security has long split into what you can check before a workload runs — image scans and admission policies — and what happens after an application launches. The Wiz Runtime Sensor covers the second window. As the dev.to report describes, it monitors system calls, running processes, network connections and file access on each node, with the processing done through an eBPF program so nothing has to be linked into the application itself.

The documented detection cases include reverse shells, binaries executed out of /tmp, image drift and privilege-escalation attempts. Resource consumption is deliberately bounded: the sensor runs under a fixed memory limit per node, a property the announcement highlights for AI workloads and web services where node density fluctuates through the day.

Credentials stay outside the cluster

The part of the release that changes the operating model is the credential path. The usual shortcut — dropping a vendor API key into a namespace as a Kubernetes Secret — turns a security product into another secret to rotate at fleet scale. Here the credentials live in Secret Manager, readable only by a dedicated service account, and GKE pulls them in and injects them into the sensor pods.

Rotating a key in Secret Manager automatically re-synchronises the Kubernetes Secret, though the dev.to writeup notes that using updated registry or API credentials still requires a manual restart of the sensor's DaemonSet. Enabling the add-on creates a dedicated gke-managed-wiz namespace and pulls images from Wiz's private container registry.

Enabling it is a single flag

Activation follows the path a platform administrator already knows. New clusters take one flag on the create command, --addons=WizSensor=ENABLED, alongside two Secret Manager references naming the registry secret and the API key. Running clusters use the equivalent --update-addons form.

The prerequisites are explicit and, as the dev.to piece points out, they are the real gate: Workload Identity Federation for GKE and Secret Manager secret sync must both be in place, because a cluster without workload identity cannot present the service account the vault checks. For teams that restrict outbound traffic, the announcement documents standard HTTP and mutual TLS proxy configurations so telemetry can reach Wiz without opening egress rules.

Coverage enforced at cluster creation

Fleet-wide enforcement is where runtime security programmes usually fail: clusters someone spins up without the agent arrive unprotected. The add-on addresses this through a custom Organization Policy Service constraint — scoped to container.googleapis.com/Cluster, applied on CREATE and UPDATE methods — that requires the sensor to be enabled. Applied at organization, folder or project level, it refuses any cluster created without runtime protection, and because it also evaluates updates, later attempts to switch the add-on off are checked too.

Telemetry feeds the Wiz Security Graph

The sensor's output flows into the Wiz Security Graph, where runtime activity is correlated with image scans, cloud posture and identity data. The practical payoff is prioritisation: image scanning tells you which vulnerable libraries exist in an image, while runtime evidence shows which of them are actually loaded and executing. Diagnostic data is collected when a threat fires, so an investigation starts with evidence attached.

Updates to the sensor and its detection rules roll out independently of GKE patch version upgrades, per the GKE documentation cited in the writeup, so rule changes do not wait for a cluster maintenance window.

What to verify first

The dev.to report flags three items operators should check before relying on the integration: the preview status itself, the egress proxy path in restricted networks, and the behavioural gap between a GKE-managed install and a Helm-managed one.

Why it matters

Runtime security agents have always carried a hidden tax: someone has to install them, store their credentials, keep them updated and remember to cover every new cluster. Folding the agent into the platform layer removes most of that overhead, and the organization policy converts coverage from a per-team habit into an API-enforced condition of cluster creation. For Autopilot users in particular, a managed kernel-level sensor answers a need that was previously awkward to meet, while the Secret Manager integration keeps vendor credentials out of cluster-bound secrets entirely.