GKE runtime security with Wiz: evaluating the eBPF sensor on Standard and Autopilot

GKE runtime security with Wiz: how to evaluate a managed eBPF sensor

An image approved by a delivery pipeline does not, by itself, tell you whether an unexpected process started inside a container or whether a workload established a suspicious connection after deployment. Runtime security addresses that gap by observing execution, complementing vulnerability and configuration analysis. Wiz combines agentless approaches with an eBPF-based sensor for this purpose. (wiz.io)

On October 16, 2026, Google announced the Wiz Runtime Sensor as a managed Google Kubernetes Engine — GKE — add-on in Preview, supporting Standard and Autopilot. The integration manages sensor deployment and updates independently of cluster upgrades. Preview should not be confused with general availability. (cloud.google.com)

Adoption requires more evidence than healthy Pods. This guide proposes an evaluation based on coverage, detection quality, operational impact, and recovery. Its scenarios and acceptance criteria are engineering recommendations, not benchmark results.

1. What the sensor observes—and what you must prove

eBPF, historically associated with extended Berkeley Packet Filter, enables verified programs to run at instrumentation points in the Linux kernel. It supports networking, observability, and security use cases, but it is not a detection product by itself. Event interpretation depends on the implementation consuming those signals. (docs.kernel.org)

The Wiz Runtime Sensor monitors processes, connections, file activity, and system calls. This provides a different perspective from inspecting artifacts at rest: observed behavior rather than potential exposure alone. (docs.cloud.google.com)

Separate three questions during evaluation:

1. Collection: was the relevant activity observed on the correct node?
2. Detection: did a rule classify it and produce a useful alert?
3. Response: did an authorized action execute with sufficient evidence and acceptable impact?

Do not assume that advertised blocking capabilities are automatically enabled by installing the add-on. Confirm licensing, configuration, supported platforms, and failure behavior. Start with observation and evaluate automated response separately.

2. Architecture and operational ownership

The conceptual telemetry path is:

Container process → node-level eBPF instrumentation → sensor → authenticated communication → Wiz platform → investigation and response

Credentials follow a separate path:

Secret Manager → Secret synchronization → sensor components

The announcement describes this integration between GKE management, credential delivery, and telemetry transmission. This model does not require placing a sidecar in every application. (cloud.google.com)

A DaemonSet is the Kubernetes controller used to maintain node-local service Pods on selected nodes. Coverage depends on eligibility, scheduling, and Pod health; it is not equivalent to a Deployment with a fixed replica count. (kubernetes.io)

Establish ownership before the pilot:

Managed should mean less repetitive work—not less accountability.

3. Standard versus Autopilot: distinguish deployment paths

Autopilot restricts privileged workloads by default. Partner deployments requiring exceptions can rely on approved allowlists. The partner catalog identifies Wiz/wiz-sensor/*; that admission mechanism should not be confused with the managed integration. (docs.cloud.google.com)

The managed add-on does not require a manual allowlist. Its documented prerequisites include GKE 1.36.4-gke.1495000 or later and Workload Identity Federation for GKE. Documented optional configuration is limited to proxy settings; evaluate Helm for other customization. (docs.cloud.google.com)

Autopilot can adjust resource requests to meet platform requirements. Compare the submitted manifest with the admitted Pod when estimating capacity and cost. (docs.cloud.google.com)

Include operating system, architecture, kernel version, runtime, sandboxed workloads, accelerators, and Spot nodes where applicable. Treat any unvalidated combination as a coverage gap rather than an assumed success.

4. Prepare and enable the integration safely

Identity, credentials, and networking

Use Workload Identity Federation for GKE to authorize workload access to Google Cloud APIs without distributing Google service account keys. Federation does not remove credentials required by external services. (docs.cloud.google.com)

Before running commands, complete the official preparation workflow: registry and Wiz API credentials in Secret Manager, synchronization identity access, and outbound connectivity. The managed namespace is gke-managed-wiz; synchronization uses wiz-sensor-secretsync-sa. (docs.cloud.google.com)

Recommended change controls:

• Separate add-on administration from credential administration.
• Grant access to required secrets rather than broad permissions for convenience.
• Keep tokens out of Git, Helm values, and pipeline logs.
• Review DNS, registry access, authentication, and tenant endpoints independently.
• Validate certificates and Transport Layer Security — TLS — without disabling verification.
• Agree on telemetry retention, residency, and classification before transmission.

Secret Manager synchronization creates Kubernetes Secrets. Maintain cluster-side access controls: centralizing the source does not eliminate the synchronized copy. (docs.cloud.google.com)

Enable an existing cluster

This example assumes that secrets and permissions already exist. Replace every replace-me value. It uses documented Google Cloud CLI options; it does not provision networking or the Wiz tenant. (docs.cloud.google.com)

export CLUSTER_PROJECT_ID='replace-me'
export SECRET_PROJECT_ID='replace-me'
export CLUSTER_NAME='replace-me'
export LOCATION='replace-me'

gcloud container clusters update "$CLUSTER_NAME" \
  --project="$CLUSTER_PROJECT_ID" \
  --location="$LOCATION" \
  --enable-secret-sync \
  --enable-secret-sync-rotation

gcloud container clusters update "$CLUSTER_NAME" \
  --project="$CLUSTER_PROJECT_ID" \
  --location="$LOCATION" \
  --update-addons=WizSensor=ENABLED \
  --wiz-sensor-registry-secret-uri="projects/${SECRET_PROJECT_ID}/secrets/wiz-image-pull-secret/versions/latest" \
  --wiz-sensor-api-key-secret-uri="projects/${SECRET_PROJECT_ID}/secrets/wiz-api-key-secret/versions/latest"

Use a CLI version that recognizes these options. Avoid running Helm and the managed add-on as competing owners of the same deployment. For migration, schedule a change window, inventory the previous installation, and validate coverage after the transition.

The latest reference follows the latest secret version; numeric versions are also supported. Choose dynamic rotation or explicit promotion according to your change process. (docs.cloud.google.com)

5. A complete evaluation workload without a live attack

The following manifest creates a benign target for inventory, process execution, and file-write validation. It does not install the sensor or guarantee a Wiz alert. Python's http.server is useful here as a laboratory tool, not as a production application server. (docs.python.org)

Save it as runtime-eval.yaml:

apiVersion: v1
kind: Namespace
metadata:
  name: runtime-eval
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: runtime-eval
  namespace: runtime-eval
spec:
  replicas: 2
  selector:
    matchLabels:
      app: runtime-eval
  template:
    metadata:
      labels:
        app: runtime-eval
    spec:
      automountServiceAccountToken: false
      terminationGracePeriodSeconds: 20
      securityContext:
        runAsNonRoot: true
        runAsUser: 10001
        runAsGroup: 10001
        fsGroup: 10001
        seccompProfile:
          type: RuntimeDefault
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: ScheduleAnyway
          labelSelector:
            matchLabels:
              app: runtime-eval
      containers:
        - name: target
          image: python:3.13-alpine
          imagePullPolicy: IfNotPresent
          command: [python, -m, http.server]
          args: ['8080', --bind, 0.0.0.0, --directory, /tmp]
          ports:
            - name: http
              containerPort: 8080
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop: [ALL]
          resources:
            requests:
              cpu: 250m
              memory: 256Mi
              ephemeral-storage: 128Mi
            limits:
              cpu: 500m
              memory: 512Mi
              ephemeral-storage: 256Mi
          startupProbe:
            httpGet:
              path: /
              port: http
            periodSeconds: 2
            failureThreshold: 30
          readinessProbe:
            httpGet:
              path: /
              port: http
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /
              port: http
            periodSeconds: 10
          volumeMounts:
            - name: scratch
              mountPath: /tmp
      volumes:
        - name: scratch
          emptyDir:
            sizeLimit: 64Mi
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: runtime-eval
  namespace: runtime-eval
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: runtime-eval
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: isolate-runtime-eval
  namespace: runtime-eval
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Important fields and production cautions

• Isolation: the NetworkPolicy grants no ingress or egress permissions. Enforcement requires cluster networking support; node-originated probe traffic has specific treatment. This policy does not govern image pulls performed by the node. (kubernetes.io)
• Privileges: non-root execution, dropped capabilities, and a read-only root filesystem reduce target permissions. /tmp remains writable for the test. Do not apply this security context to the sensor, which has different requirements. (kubernetes.io)
• Health: startup, readiness, and liveness probes check initialization, readiness, and whether a restart is needed. (kubernetes.io)
• Availability: two replicas and preferred hostname spreading support the exercise. ScheduleAnyway does not guarantee separation; the PodDisruptionBudget limits certain voluntary disruptions, not zone failures. (kubernetes.io)
• Resources: these are illustrative values, not sensor sizing guidance. Requests affect scheduling; limits constrain consumption. Adjust them after measurement. (kubernetes.io)

The image tag is mutable. Record the approved digest and use it for the formal evaluation. Do not expose this server through an Ingress or LoadBalancer.

Run the benign validation:

kubectl apply -f runtime-eval.yaml
kubectl rollout status deployment/runtime-eval -n runtime-eval
kubectl get pods -n runtime-eval -o wide

kubectl exec -n runtime-eval deployment/runtime-eval -- \
  python -c "from pathlib import Path; Path('/tmp/runtime-eval-marker').write_text('authorized-test'); print('runtime-eval-marker')"

This executes in one replica. Record the Pod, node, and timestamp; target each Pod explicitly when both replicas must be tested. Look for the activity in available investigation views, but do not classify the lack of an alert for a harmless write as a detection failure. Validate threats using authorized, vendor-documented simulations in an isolated environment.

6. Evaluation protocol and acceptance criteria

Use three phases: a baseline without the sensor, observation with the sensor, and controlled exercises. Keep load, data, topology, and duration comparable.

Calculate coverage against eligible nodes identified in the compatibility matrix, but report excluded nodes separately. Otherwise, a 100% coverage indicator can conceal out-of-scope workloads.

Include workloads with frequent short-lived processes, connection churn, heavy file activity, and high Pod density. Do not rely on averages alone: compare p95 and p99 application latency, peak memory, and restarts. Define a Service Level Objective — SLO and a stop condition before the experiment.

Test backend communication failure as well. Ask about—and verify—buffering, event loss, reconnection, and response behavior. Do not assume unlimited local retention or full offline functionality.

7. A production-like scenario

Consider a fictional order-processing platform: APIs and workers on Standard, smaller integrations on Autopilot, and managed PostgreSQL and Redis dependencies.

Problem → the team wants to investigate unexpected processes without maintaining inconsistent, untracked sensor deployments across clusters.

Solution → evaluate the add-on on a representative cluster of each type, using the same test cases and ownership model.

Implementation → start in staging, compare against the baseline, exercise rotation and autoscaling, move to one lower-impact production cluster, and expand only after review.

Expected outcome → an evidence package describing coverage, limitations, incremental cost, and recovery. Do not promise a percentage reduction in incidents before measuring it.

For production, distribute critical applications across zones, test maintenance-time capacity, and retain application backup and restoration procedures. For the sensor, evaluate node coverage and telemetry continuity. Adding application Deployment replicas does not repair a DaemonSet coverage gap.

8. Observability, security, and FinOps

Two dashboards for different questions

Build a mechanism health dashboard covering expected and available sensors, restarts, consumption, authentication failures, synchronization, and communication.

Build a separate security effectiveness dashboard covering detected simulations, latency, investigative context, confirmed false positives, and triage time. Treat missing telemetry as its own failure condition—not as evidence that no threat exists.

Use platform metrics and signals officially exposed by the product. Do not invent Wiz Prometheus endpoints or metric names. Standardize cluster, namespace, workload, Pod, and time-window identifiers when correlating with existing logs and traces.

Privileges and sensitive data

Review RBAC — Role-Based Access Control — and IAM — Identity and Access Management — independently. Restrict Secret reads, managed namespace access, installation permissions, and the ability to create equivalent identities. Assess whether process arguments, paths, and metadata could contain sensitive information.

A privileged sensor is not a reason to relax business workload policies. Keep network segmentation and admission controls independent.

Cost analysis

The GKE add-on has no additional add-on fee, but requires a Wiz license and consumes resources; Secret Manager charges apply separately. (docs.cloud.google.com)

Include licensing, incremental capacity, network egress, NAT or proxy services, secrets, logs, retention, and engineering time in the FinOps model. Compare cost per protected node and per covered critical workload. Measure upgrade-time node peaks rather than sizing only for steady state.

If Spot capacity is involved, test interruption and coverage recovery. Establish regular-node behavior first, before combining price, churn, and performance variables.

9. Updates, rotation, governance, and rollback

Version configuration intent and evaluation evidence through GitOps, but never commit credentials. Avoid manual patches to service-reconciled resources. Before adoption, clarify available mechanisms for tracking versions, testing updates, and obtaining support.

The sources contain an important discrepancy: the announcement emphasizes automatic synchronization, while the operational guide requires restarting the DaemonSet after credential changes. Follow the conservative operational instruction and validate rotation end to end. (cloud.google.com)

Organization Policy supports custom constraints on resource operations. Test scope, exceptions, and effects on creation and updates before enforcing a policy organization-wide. A configuration policy does not replace continuous health monitoring. (docs.cloud.google.com)

Define two rollback paths:

1. Credentials or configuration: restore a valid version, then verify authentication and telemetry recovery.
2. Sensor impact: authorize temporary suspension, record the coverage gap, and apply compensating controls.

The cluster update syntax supports disabling the add-on:

gcloud container clusters update "$CLUSTER_NAME" \
  --project="$CLUSTER_PROJECT_ID" \
  --location="$LOCATION" \
  --update-addons=WizSensor=DISABLED

Organization policies can affect whether the operation is permitted. Disabling is neither a version downgrade nor recovery of lost events; treat it as an authorized security change. (docs.cloud.google.com)

10. Evidence-driven troubleshooting

Start with Kubernetes inspection commands without printing Secret contents. Pod descriptions, logs, and events help distinguish scheduling, initialization, and execution problems. (kubernetes.io)

kubectl get nodes -o wide
kubectl get pods -n gke-managed-wiz -o wide
kubectl get daemonsets -n gke-managed-wiz
kubectl get secrets -n gke-managed-wiz
kubectl get events -n gke-managed-wiz --sort-by=.metadata.creationTimestamp

# Replace with the actual Pod name.
export SENSOR_POD='replace-me'
kubectl describe pod "$SENSOR_POD" -n gke-managed-wiz
kubectl logs "$SENSOR_POD" -n gke-managed-wiz --all-containers=true --tail=200
kubectl logs "$SENSOR_POD" -n gke-managed-wiz --all-containers=true --previous

This is a hypothesis-driven investigation guide, not an automatic diagnosis. Do not solve Autopilot admission problems by granting unrestricted privileges.

11. Development, production, and alternatives

In development, one replica and short exercises may be sufficient to learn the workflow. Production requires application redundancy, capacity planning, coverage-loss alerts, credential rotation, update tests, and rehearsed rollback.

Avoid omitted requests, hardcoded credentials, missing target health checks, weak observability, unnecessary public exposure, and promoting laboratory configuration without review.

The add-on is a candidate when standardization and reduced maintenance matter more than customization. Evaluate Helm when required configuration does not fit the managed path. Include support ownership and lifecycle responsibility in that decision. (docs.cloud.google.com)

Falco is an alternative offering rule-based runtime detection with Kubernetes metadata enrichment. Compare rule and integration flexibility against the operational work needed for deployment, updates, and response. Do not assume that a privileged installation working on Standard will be admitted on Autopilot. (falco.org)

Do not adopt the add-on merely to satisfy a checklist. Reconsider the design if Preview conflicts with contractual requirements, telemetry cannot leave the environment, or the team cannot sustain triage. Identity, image, network, and audit controls remain necessary; do not claim they replace runtime observation.

Practical summary

• Distinguish the managed add-on from Helm deployment.
• Validate Standard and Autopilot with separate compatibility matrices.
• Prove collection, detection, and response independently.
• Measure application impact, not only sensor consumption.
• Exercise credentials, autoscaling, upgrades, and communication failures.
• Agree on costs and support boundaries before expansion.
• Document exclusions and maintain an authorized rollback path.

Conclusion

A mature evaluation turns the sensor into a verifiable operational capability: known coverage, useful evidence, and tested recovery. For DevOps, that means traceable changes. For SRE, it means controlled service impact. For Platform Engineering, it means a reusable standard with explicit exceptions.

The goal is not to demonstrate that an agent can start. It is to prove that the platform can detect what matters, preserve reliability, and explain exactly where its protection ends.