Google Cloud adds Wiz runtime security to GKE clusters

Google Cloud has introduced a preview add-on for Google Kubernetes Engine that brings Wiz Runtime Sensor threat detection to Standard and Autopilot GKE clusters.

Managed as a first-party GKE feature, the add-on is designed to reduce the work involved in deploying runtime security tools across Kubernetes environments. GKE handles sensor deployment, credential injection and lifecycle updates, while Wiz provides the underlying eBPF-based runtime monitoring.

Runtime security is an increasing concern for organisations running containerised workloads, particularly as attacks move faster and static scanning tools fail to catch threats that emerge while applications are running. The add-on is aimed at security and platform engineering teams that would otherwise have to install and maintain third-party agents across large cluster fleets.

Google Cloud said the integration is intended to address several operational challenges, including managing agent installations across dozens or hundreds of clusters, the risk of distributing API keys through Kubernetes Secrets, and the lack of central policy controls to ensure every cluster has runtime protection enabled before workloads receive traffic.

Credential handling

A central part of the integration is its use of Google Cloud Secret Manager. Instead of requiring teams to distribute Wiz API keys across cluster namespaces, the add-on uses GKE secret sync to pull credentials from a central off-cluster store that only a dedicated service account can access.

GKE then retrieves those credentials and injects them into the Runtime Sensor pods, according to Google Cloud. When a key is updated in Secret Manager, the change is synchronised to the sensor without requiring a cluster restart or manual intervention.

The managed approach also extends to lifecycle management. Platform operators can enable the add-on through the gcloud command-line tool or the GKE API, while the GKE control plane handles deployment of sensor components, pod management and node configuration.

Fleet controls

Google Cloud and Wiz are also positioning the add-on as a governance tool for large organisations. Security leaders can use custom organisation policy constraints to reject the creation of GKE clusters that do not have the Runtime Sensor add-on enabled, providing a way to enforce coverage across a Kubernetes estate.

The policy mechanism is intended to prevent gaps in protection, including when new or unauthorised clusters are created without runtime monitoring. In practice, it gives platform teams a built-in control point at the cluster creation and update stages.

For organisations with tightly controlled outbound network policies, the managed sensor also supports HTTP and mutual TLS proxy configurations. This allows telemetry to be sent back to Wiz while staying within egress firewall rules, Google Cloud said.

Runtime monitoring

At a technical level, the sensor monitors system calls, running processes, network connections and file access at kernel level. It is designed to detect activity such as reverse shells, privilege escalation attempts, container escapes and unsafe outbound connections, according to Google Cloud.

The software uses a fixed memory limit on each node and is intended to keep CPU usage low even when workload activity is high. That may be relevant for AI workloads and web services, where resource consumption can change quickly as demand shifts.

The sensor also has a separate update cycle from the broader GKE cluster and node lifecycle. Google Cloud said it can roll out new versions and detection rules published by Wiz without requiring GKE version upgrades, node pool recreation or workload disruption.

Broader platform

The integration also feeds GKE runtime telemetry into the Wiz Security Graph, linking the sensor to Wiz's wider AI Application Protection Platform. This allows security teams to correlate live runtime activity with background security scans and determine whether vulnerable code is actually running in memory, Google Cloud said.

The approach is intended to help teams distinguish between theoretical and active risks, while also supporting real-time threat detection and response. The system can also gather diagnostic data when a threat is identified to support investigation.

The launch reflects closer collaboration between cloud infrastructure providers and security software vendors as customers seek tighter integration rather than standalone tools. For Kubernetes users, the main appeal is likely to be the ability to enforce runtime monitoring through existing platform controls instead of relying on separate deployment processes and manually managed credentials.

Google Cloud said the sensor can be enabled when creating a new cluster or switched on for an existing one, provided Workload Identity Federation for GKE and Secret Manager secret sync are in place.