Google Cloud 將 Wiz Runtime Sensor 納入 GKE 管理式附加元件

TL;DR

• The Wiz Runtime Sensor is a monitoring component from Wiz that watches what running containers actually do inside a Kubernetes cluster, at kernel level.
• Google Cloud announced it on 17 October 2026 as a managed add-on for Google Kubernetes Engine, in preview, for both Standard and Autopilot clusters.
• GKE installs the sensor, injects its credentials from Secret Manager and updates it outside the cluster version cycle.
• A custom organization policy can reject any new cluster created without the add-on, which moves enforcement to the platform team.
• The sensor reads system calls, processes, network connections and file access, with a fixed memory limit on each node, and sends that telemetry to the Wiz Security Graph.
• Preview status, the egress proxy path and the gap between a GKE-managed and a Helm-managed install are the first things an operator should verify.

Runtime security has been the awkward purchase in Kubernetes for years. Every cluster needs an agent, every agent needs a credential, and the team that owns the clusters is rarely the team that owns the agent's licence. Google Cloud and Wiz have now put the agent inside the platform itself.

The announcement is short and specific: the Wiz Runtime Sensor becomes a first-party add-on for GKE, in preview, covering Standard and Autopilot clusters, with GKE handling deployment, credential injection and updates. The detection engine is the visible part of the release. The release also moves credential handling and fleet enforcement into the platform, changing the operating model.

A Runtime Sensor Watches What Containers Do at Kernel Level

A container image can be scanned before it runs, and a manifest can be checked before it is admitted. Runtime observation covers processes that begin after an application launches.

The Wiz Runtime Sensor covers that window. It observes system calls, running processes, network connections and file access. The GKE documentation demonstrates a reverse-shell alert, while the Wiz engineering post lists reverse shells, binary execution from /tmp, image drift and privilege-escalation attempts. Processing happens on the node through an eBPF program, so the library does not need to be linked into the application.

Resource use is bounded on purpose. The sensor keeps a fixed memory limit on each node, which matters on a cluster where workload density changes through the day, and the announcement points at AI workloads and web services as the cases where that predictability helps.

The architecture figure published with the Google Cloud announcement (retrieved 28 October 2026, cloud.google.com/blog/products/identity-security/wiz-sensor-for-gke-turnkey-threat-detection-for-kubernetes), showing credential sync, sensor deployment and the threat telemetry path back to Wiz.

GKE Installs the Sensor and Pipes Credentials From Secret Manager

The part of this release that changes an operating model is the credential path. Distributing a vendor API key into a namespace as a Kubernetes Secret is the standard shortcut, and it is the step that turns a security product into a secret to rotate at scale.

Here the key lives outside the cluster. GKE uses its Secret Manager secret sync integration to hold the Wiz credentials in a central vault that only a dedicated service account can read, then retrieves them and injects them into the sensor pods. Updating a key in Secret Manager automatically re-synchronizes the Kubernetes Secret. Using updated registry or API credentials then requires a manual restart of the Runtime Sensor DaemonSet.

GKE documentation adds the mechanical detail: enabling the add-on creates the gke-managed-wiz namespace, installs the Runtime Sensor components there, and pulls the images from the Wiz private container registry.

Wiz's own view of the chain (retrieved 28 October 2026, wiz.io/blog/wiz-sensor-on-gke-1-click-runtime-protection-now-native): the GKE control plane, Google Cloud Secret Manager, the node-level eBPF engine and the Wiz Security Graph.

One gcloud Flag Enables It on a New or Existing Cluster

Enabling the sensor follows the path a platform administrator already knows. On a new cluster the announcement documents a single flag on the cluster create command, --addons=WizSensor=ENABLED, alongside the two Secret Manager references that name the registry secret and the API key.

On a running cluster the equivalent is --update-addons=WizSensor=ENABLED, and the prerequisites are explicit: Workload Identity Federation for GKE and Secret Manager secret sync have to be in place before any of it works. That pairing is the real gate, since 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 reaches Wiz while egress firewall rules stay intact.

Page capture of the GKE installation documentation (retrieved 28 October 2026, docs.cloud.google.com/kubernetes-engine/security/install-wiz-sensor-addon), which lists the prerequisites and the namespace the add-on creates.

An Organization Policy Makes Runtime Coverage a Create-Time Condition

Fleet-wide enforcement is where most runtime programmes fail. A team enables the agent on the clusters it knows about, and the cluster somebody spins up on a Friday afternoon arrives without it.

The add-on is designed to close that gap through Organization Policy Service custom constraints. The announcement publishes the constraint itself: a resource type of container.googleapis.com/Cluster, the method types CREATE and UPDATE, and a condition that the cluster's addon configuration has the sensor enabled. Apply it at the organization, folder or project level and a cluster created without runtime protection is refused.

Read that constraint as a governance instrument. It makes agent installation an API-enforced rule that platform teams can apply when clusters are created or updated.

A Wiz console view from the vendor's own post (retrieved 28 October 2026, wiz.io/blog/wiz-sensor-on-gke-1-click-runtime-protection-now-native) showing a sensor deployment reported by GKE with its active sensor pods.

Two practical notes about the constraint. It evaluates the cluster's add-on configuration at create and update time, so a later change to that configuration is checked as well as a brand new cluster. Applying it at the folder level covers the environments nobody remembers to check, which is where most coverage gaps start.

Telemetry Reaches the Wiz Security Graph and Answers a Narrower Question

Detection rules answer specific questions about runtime activity. Image scanning identifies vulnerable libraries in an image and supplies posture context. Runtime evidence shows which of those libraries are loaded and executing in memory.

The announcement frames the Wiz Security Graph as the place where those two views meet: cluster runtime activity correlated with image scans, cloud posture and identity. The practical effect is prioritisation around vulnerable code that is loaded and running.

Diagnostic data is collected when a threat fires, so an investigation starts with evidence attached.

Page capture of the Google Cloud announcement (retrieved 28 October 2026, cloud.google.com/blog/products/identity-security/wiz-sensor-for-gke-turnkey-threat-detection-for-kubernetes), the source of the enablement flags and the organization policy above.

Independent Updates Keep Detection Rules Ahead of the Cluster Version

Agent lifecycle is the operational tax of runtime security. Every agent image is a new thing to test, and every change usually waits for a maintenance window.

GKE documentation states the arrangement directly: "Any updates to the Runtime Sensor components are independent of GKE patch version upgrades." The announcement adds that sensor versions and detection rules published by Wiz roll out without GKE version bumps, node pool recreation or workload disruption.

That independence cuts both ways, and a platform team should decide which way it wants before enabling anything. A detection engine that updates on the vendor's schedule keeps pace with new attack behaviour. It also changes what runs on your nodes outside your release calendar, which is a governance question for a regulated environment.

Netics editorial visual: the split between what the managed add-on now owns and what stays with the platform team.

The Preview Label, the Proxy and the Helm Alternative Are the First Checks

Three details decide whether this is a production option this quarter.

The first is the preview status. GKE documentation places the feature under the Pre-GA terms of service, which means the usual "available as is" language and limited support commitments. A regulated workload can wait, and the wait is cheap because nothing forces an early decision.

The second is egress design. A sensor that cannot reach Wiz reports nothing, so the proxy configuration is part of the architecture and belongs in the firewall request early. The third is the install path. The Helm chart remains available, offers more configuration freedom, and leaves the components unmanaged by GKE, with issues reported to Wiz. Choose per estate: the add-on for fleet coverage, the chart for clusters that need tuning.

Consider a hypothetical case. Imagine a Paris platform team running forty clusters across three environments and two cloud projects. The add-on plus one organization constraint covers the fleet in a week, and the two clusters running bespoke networking stay on the chart.

Netics editorial visual: the preview status, the egress path and the install path, the three checks that come before any rollout.

Where Runtime Coverage Fits Beside the Configuration Review

Runtime detection complements the controls that decide what a workload may do before it starts. Admission policies, least-privilege service accounts, network rules and the sensor work together to record configured boundaries and activity inside them.

The add-on makes that layer cheaper to run, and the enforcement constraint makes it harder to forget. Both are good news for a small platform team that has been maintaining three copies of an agent across a growing fleet.

The open question is what the platform team gives up in exchange for the managed lifecycle: a vendor-owned update channel on every node, and a detection engine that lives outside the cluster's own release process. That trade is reasonable for most estates, and it deserves an explicit answer taken on purpose. This level of hardening belongs in security audit and hardening work, and the credential-handling argument connects to the earlier analysis of hardening a Fortinet estate with AI assistance.

Originally published on the Netics blog.