Segurança de runtime no GKE com Wiz: avaliação do sensor eBPF em Standard e Autopilot

Segurança de runtime no GKE com Wiz: como avaliar um sensor eBPF gerenciado

Uma imagem aprovada no pipeline não responde, sozinha, se um processo inesperado iniciou dentro de um contêiner ou se um workload estabeleceu uma conexão suspeita depois do deploy. Esse é o espaço da segurança de runtime: observar o comportamento durante a execução, complementando a análise de vulnerabilidades e de configuração. O Wiz combina abordagens agentless e um sensor baseado em eBPF para esse propósito. (wiz.io)

Em 16 de outubro de 2026, o Google anunciou o Wiz Runtime Sensor como add-on gerenciado do Google Kubernetes Engine — GKE — em Preview, para Standard e Autopilot. O gerenciamento inclui implantação e atualizações do sensor, independentes do ciclo de atualização do cluster. Preview não deve ser tratado como disponibilidade geral. (cloud.google.com)

A decisão de adoção exige mais do que verificar se os Pods ficaram verdes. Este artigo propõe uma avaliação baseada em cobertura, qualidade da detecção, impacto operacional e capacidade de recuperação. Os cenários e critérios apresentados são recomendações de engenharia, não resultados de benchmark.

1. O que o sensor observa — e o que precisa ser comprovado

O eBPF, historicamente associado a extended Berkeley Packet Filter, permite executar programas verificados em pontos de instrumentação do kernel Linux. Ele é utilizado em observabilidade, rede e segurança; não é, por si só, um produto de detecção. A interpretação dos eventos depende da implementação que consome esses sinais. (docs.kernel.org)

O Wiz Runtime Sensor acompanha processos, conexões, atividade de arquivos e chamadas de sistema. Isso oferece uma perspectiva diferente da inspeção de artefatos em repouso: comportamento observado, e não somente exposição potencial. (docs.cloud.google.com)

Na avaliação, separe três perguntas:

1. Coleta: a atividade relevante foi observada no nó correto?
2. Detecção: uma regra classificou essa atividade e produziu um alerta útil?
3. Resposta: uma ação autorizada foi executada, com evidências e impacto aceitável?

Não considere uma capacidade comercial de bloqueio como automaticamente habilitada no add-on. Solicite confirmação sobre licença, configuração, plataforma suportada e comportamento de falha. Comece com observação; avalie respostas automáticas em uma etapa separada.

2. Arquitetura e limites de responsabilidade

O fluxo conceitual é:

Processo no contêiner → instrumentação eBPF no nó → sensor → comunicação autenticada → plataforma Wiz → investigação e resposta

O fluxo de credenciais é separado:

Secret Manager → sincronização de Secrets → componentes do sensor

O anúncio descreve a integração entre gerenciamento pelo GKE, distribuição de credenciais e envio de telemetria. Não é necessário inserir um sidecar em cada aplicação para representar esse modelo. (cloud.google.com)

Um DaemonSet é o controller Kubernetes utilizado para manter Pods de serviços locais nos nós selecionados. Sua cobertura depende de elegibilidade, agendamento e estado dos Pods; não equivale a um Deployment com um número fixo de réplicas. (kubernetes.io)

Para esta avaliação, distribua responsabilidades explicitamente:

Gerenciado deve significar menos trabalho repetitivo, não ausência de supervisão.

3. Standard e Autopilot: compare o caminho de instalação

Autopilot restringe workloads privilegiados por padrão. Instalações de parceiros que precisam de exceções podem depender de allowlists aprovadas. O catálogo de parceiros identifica o caminho Wiz/wiz-sensor/*; esse mecanismo não deve ser confundido com a integração gerenciada. (docs.cloud.google.com)

O add-on gerenciado dispensa a allowlist manual. A documentação exige GKE 1.36.4-gke.1495000 ou posterior e Workload Identity Federation for GKE. As opções adicionais de configuração documentadas limitam-se ao proxy; outras personalizações exigem considerar Helm. (docs.cloud.google.com)

O Autopilot pode ajustar requests para respeitar requisitos da plataforma. Portanto, compare o manifesto solicitado com o Pod admitido, especialmente ao estimar capacidade e custo. (docs.cloud.google.com)

Inclua na matriz de teste sistema operacional, arquitetura, versão do kernel, runtime, workloads com sandbox, aceleradores e nós Spot quando existirem. Trate qualquer combinação não validada como lacuna, não como cobertura presumida.

4. Preparação e habilitação controlada

Identidade, credenciais e rede

Use Workload Identity Federation for GKE para conceder acesso a APIs do Google Cloud por identidade de workload, sem distribuir chaves de contas de serviço do Google. Essa federação não elimina as credenciais específicas exigidas por serviços externos. (docs.cloud.google.com)

Antes dos comandos, conclua a preparação indicada no guia oficial: credenciais do registry e da API Wiz no Secret Manager, acesso da identidade de sincronização e conectividade de saída. O namespace gerenciado é gke-managed-wiz; a identidade de sincronização utiliza wiz-sensor-secretsync-sa. (docs.cloud.google.com)

Recomendações para a mudança:

• Separe o operador que habilita o add-on de quem administra credenciais.
• Conceda acesso aos segredos necessários, evitando permissões amplas por conveniência.
• Não grave tokens no Git, em values de Helm ou nos logs do pipeline.
• Revise DNS, saída para registry, autenticação e endpoints do tenant separadamente.
• Valide certificados e Transport Layer Security — TLS — sem desabilitar sua verificação.
• Documente retenção, residência e classificação da telemetria antes de enviá-la.

A sincronização do Secret Manager materializa Kubernetes Secrets. Portanto, mantenha controles de acesso também no cluster; centralizar a origem não remove a cópia sincronizada. (docs.cloud.google.com)

Habilitação em um cluster existente

O exemplo pressupõe que os segredos e suas permissões já existem. Substitua todos os valores replace-me. Os comandos utilizam opções documentadas do Google Cloud CLI; não representam provisionamento completo da rede ou do tenant. (docs.cloud.google.com)

export CLUSTER_PROJECT_ID='replace-me'
export SECRET_PROJECT_ID='replace-me'
export CLUSTER_NAME='replace-me'
export LOCATION='replace-me'

gcloud container clusters update "$CLUSTER_NAME" \
  --project="$CLUSTER_PROJECT_ID" \
  --location="$LOCATION" \
  --enable-secret-sync \
  --enable-secret-sync-rotation

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

Use uma versão da CLI que reconheça essas opções. Não mantenha Helm e add-on gerenciado concorrendo pela mesma implantação. Para migração, defina uma janela, inventarie a instalação anterior e valide a cobertura após a troca.

O uso de latest acompanha a versão mais recente do segredo; a referência também aceita versões numéricas. Escolha entre rotação dinâmica e promoção explícita conforme o processo de mudança. (docs.cloud.google.com)

5. Workload de avaliação: YAML completo e sem ataque real

O manifesto abaixo cria um alvo benigno para verificar inventário, execução de processo e escrita de arquivo. Não instala o sensor e não garante um alerta Wiz. O servidor http.server do Python é adequado aqui como ferramenta de laboratório, não como servidor de aplicação de produção. (docs.python.org)

Salve como runtime-eval.yaml:

apiVersion: v1
kind: Namespace
metadata:
  name: runtime-eval
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: runtime-eval
  namespace: runtime-eval
spec:
  replicas: 2
  selector:
    matchLabels:
      app: runtime-eval
  template:
    metadata:
      labels:
        app: runtime-eval
    spec:
      automountServiceAccountToken: false
      terminationGracePeriodSeconds: 20
      securityContext:
        runAsNonRoot: true
        runAsUser: 10001
        runAsGroup: 10001
        fsGroup: 10001
        seccompProfile:
          type: RuntimeDefault
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: ScheduleAnyway
          labelSelector:
            matchLabels:
              app: runtime-eval
      containers:
        - name: target
          image: python:3.13-alpine
          imagePullPolicy: IfNotPresent
          command: [python, -m, http.server]
          args: ['8080', --bind, 0.0.0.0, --directory, /tmp]
          ports:
            - name: http
              containerPort: 8080
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop: [ALL]
          resources:
            requests:
              cpu: 250m
              memory: 256Mi
              ephemeral-storage: 128Mi
            limits:
              cpu: 500m
              memory: 512Mi
              ephemeral-storage: 256Mi
          startupProbe:
            httpGet:
              path: /
              port: http
            periodSeconds: 2
            failureThreshold: 30
          readinessProbe:
            httpGet:
              path: /
              port: http
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /
              port: http
            periodSeconds: 10
          volumeMounts:
            - name: scratch
              mountPath: /tmp
      volumes:
        - name: scratch
          emptyDir:
            sizeLimit: 64Mi
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: runtime-eval
  namespace: runtime-eval
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: runtime-eval
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: isolate-runtime-eval
  namespace: runtime-eval
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

O que adaptar e por quê

• Isolamento: a NetworkPolicy não declara permissões de entrada ou saída. Sua aplicação depende do suporte de rede do cluster; tráfego do nó para probes tem tratamento específico. A política não controla o download da imagem pelo nó. (kubernetes.io)
• Privilégios: execução sem root, capabilities removidas e filesystem raiz somente leitura reduzem permissões do alvo. O volume /tmp continua gravável para o teste. Não copie esse contexto para o sensor: suas necessidades são diferentes. (kubernetes.io)
• Saúde: startup, readiness e liveness verificam, respectivamente, inicialização, prontidão e necessidade de reinício. (kubernetes.io)
• Disponibilidade: duas réplicas e distribuição preferencial por hostname ajudam no exercício. ScheduleAnyway não garante separação; o PodDisruptionBudget limita certas interrupções voluntárias, não falhas de zona. (kubernetes.io)
• Recursos: os números são valores didáticos, não sizing do sensor. Requests influenciam agendamento; limites restringem consumo. Ajuste após medição. (kubernetes.io)

A tag da imagem é mutável. Para repetibilidade, registre o digest aprovado e utilize-o na avaliação formal. Não exponha esse servidor por Ingress ou LoadBalancer.

Execute a validação benigna:

kubectl apply -f runtime-eval.yaml
kubectl rollout status deployment/runtime-eval -n runtime-eval
kubectl get pods -n runtime-eval -o wide

kubectl exec -n runtime-eval deployment/runtime-eval -- \
  python -c "from pathlib import Path; Path('/tmp/runtime-eval-marker').write_text('authorized-test'); print('runtime-eval-marker')"

Esse comando executa em uma das réplicas. Registre Pod, nó e horário; repita explicitamente por Pod quando precisar testar ambos. Procure a atividade na investigação disponível, mas não classifique a ausência de alerta para uma escrita inofensiva como falha de detecção. Para validar ameaças, use simulações autorizadas e documentadas pelo fornecedor em ambiente isolado.

6. Protocolo de avaliação e critérios de aprovação

Proponho três fases: baseline sem sensor, sensor em observação e exercícios controlados. Mantenha carga, dados, topologia e duração comparáveis.

Calcule cobertura usando apenas nós elegíveis identificados na matriz, mas publique também os excluídos. Caso contrário, um indicador de 100% pode esconder workloads fora do escopo.

Teste cargas com muitas execuções curtas, conexões frequentes, acesso intenso a arquivos e alta densidade de Pods. Não use apenas consumo médio: compare p95 e p99 de latência, picos de memória e reinicializações. Defina previamente um Service Level Objective — SLO, ou objetivo de nível de serviço, para interromper o experimento se a aplicação degradar.

Inclua falha de comunicação com o backend. Pergunte e teste o que ocorre com buffering, descarte, reconexão e ações de resposta. Não presuma retenção local ilimitada ou funcionamento offline completo.

7. Cenário próximo de produção

Considere uma plataforma fictícia de pedidos: API e workers no Standard; integrações menores no Autopilot; PostgreSQL e Redis como dependências gerenciadas.

Problema → a equipe deseja investigar processos inesperados sem operar instalações diferentes e não rastreadas em cada cluster.

Solução → avaliar o add-on em um cluster representativo de cada modalidade, com o mesmo conjunto de casos de teste e responsáveis.

Implementação → começar em homologação, comparar baseline, testar rotação e autoscaling, avançar para um cluster de produção de baixo impacto e só então ampliar.

Resultado esperado → produzir um dossiê com cobertura, limitações, custo incremental e procedimento de recuperação. Não assumir redução percentual de incidentes antes de medi-la.

Para produção, recomendo distribuir aplicações críticas entre zonas, testar capacidade durante manutenção e preservar seus backups e procedimentos de restauração. Para o sensor, avalie cobertura por nó e continuidade de telemetria; aumentar réplicas de um Deployment de aplicação não resolve lacunas de um DaemonSet.

8. Observabilidade, segurança e FinOps

Dois painéis, duas perguntas

Monte um painel de saúde do mecanismo: sensores esperados, disponíveis, reinícios, consumo, falhas de autenticação, sincronização e comunicação.

Monte outro de efetividade de segurança: simulações detectadas, latência, contexto suficiente, falsos positivos confirmados e tempo de triagem. Trate ausência de telemetria como condição própria, não como ausência de ameaça.

Use métricas de plataforma e os sinais oficialmente expostos pelo produto. Não invente endpoints Prometheus ou nomes de métricas Wiz. Para correlacionar com logs e traces existentes, padronize cluster, namespace, workload, Pod e janela temporal.

Privilégios e dados

Recomendo revisar RBAC — Role-Based Access Control — e IAM — Identity and Access Management — separadamente. Restrinja leitura de Secrets, acesso ao namespace gerenciado, permissões de instalação e capacidade de criar identidades equivalentes. Revise também quais argumentos de processo, caminhos e metadados podem conter dados sensíveis.

Não trate um sensor privilegiado como justificativa para relaxar as políticas dos workloads de negócio. Mantenha segmentação e controles de admissão independentes.

Custos

O add-on não tem cobrança adicional do GKE, mas exige licença Wiz e consome recursos; Secret Manager tem cobrança própria. (docs.cloud.google.com)

No estudo de FinOps, contabilize licença, capacidade incremental, saída de rede, NAT ou proxy, segredos, logs, retenção e tempo de operação. Compare custo por nó protegido e por workload crítico coberto. Meça também picos de nós durante upgrades; não dimensione apenas pelo estado estável.

Se utilizar Spot, inclua testes de interrupção e retorno da cobertura. Avalie nós regulares como referência antes de misturar variáveis de preço, churn e performance.

9. Upgrades, rotação, governança e rollback

Versione a intenção de configuração e as evidências em GitOps, mas não os segredos. Evite patches manuais em recursos reconciliados pelo serviço. Antes da adoção, esclareça mecanismos disponíveis para acompanhar versões, testar atualizações e obter suporte.

Há uma divergência relevante nas fontes: o anúncio enfatiza sincronização automática, enquanto o guia operacional exige reinício do DaemonSet após mudanças nas credenciais. Adote a instrução operacional conservadora e valide a rotação ponta a ponta. (cloud.google.com)

Organization Policy permite governar operações sobre recursos com restrições customizadas. Recomendo testar escopo, exceções e impacto em criação e atualização antes de impor a política à organização. Política de configuração não substitui monitoramento contínuo de saúde. (docs.cloud.google.com)

Para rollback, defina dois caminhos:

1. Credencial/configuração: restaurar uma versão válida e verificar autenticação e retorno da telemetria.
2. Impacto do sensor: aprovar uma suspensão temporária, registrar a lacuna e aplicar controles compensatórios.

A sintaxe de atualização permite desabilitar o add-on:

gcloud container clusters update "$CLUSTER_NAME" \
  --project="$CLUSTER_PROJECT_ID" \
  --location="$LOCATION" \
  --update-addons=WizSensor=DISABLED

A operação pode depender das políticas da organização. Desabilitar não é downgrade de versão nem recuperação de eventos perdidos; trate como mudança de segurança autorizada. (docs.cloud.google.com)

10. Troubleshooting orientado a evidências

Comece pelos comandos de inspeção Kubernetes, sem imprimir conteúdo de Secrets. describe, logs e eventos ajudam a distinguir agendamento, inicialização e execução. (kubernetes.io)

kubectl get nodes -o wide
kubectl get pods -n gke-managed-wiz -o wide
kubectl get daemonsets -n gke-managed-wiz
kubectl get secrets -n gke-managed-wiz
kubectl get events -n gke-managed-wiz --sort-by=.metadata.creationTimestamp

# Substitua pelo nome real do Pod.
export SENSOR_POD='replace-me'
kubectl describe pod "$SENSOR_POD" -n gke-managed-wiz
kubectl logs "$SENSOR_POD" -n gke-managed-wiz --all-containers=true --tail=200
kubectl logs "$SENSOR_POD" -n gke-managed-wiz --all-containers=true --previous

A tabela é um roteiro de hipóteses, não um diagnóstico automático. Não resolva problemas de admissão Autopilot liberando privilégios indiscriminadamente.

11. Desenvolvimento, produção e alternativas

Em desenvolvimento, uma réplica e testes curtos podem bastar para aprender o fluxo. Em produção, exija redundância das aplicações, capacidade, alertas de perda de cobertura, credenciais rotacionadas, testes de atualização e rollback ensaiado.

Evite especialmente: requests omitidos, credenciais hardcoded, ausência de health checks nos alvos, falta de observabilidade, exposição pública desnecessária e promoção de um laboratório sem revisão.

O add-on é um candidato quando padronização e redução de manutenção pesam mais que personalização. Helm merece avaliação quando a configuração necessária não cabe no caminho gerenciado. A escolha deve incluir responsabilidade pelo suporte e pelo ciclo de vida. (docs.cloud.google.com)

Como alternativa, o Falco oferece detecção de runtime baseada em regras e enriquecimento com metadados Kubernetes. Compare liberdade de regras e integrações com o trabalho necessário para operação, atualização e resposta. Não presuma que uma instalação privilegiada disponível no Standard será admitida no Autopilot. (falco.org)

Não adote o add-on apenas para preencher um checklist. Se Preview for incompatível com requisitos contratuais, se a telemetria não puder sair do ambiente ou se a equipe não conseguir operar a triagem, reavalie o desenho. Controles de identidade, imagens, rede e auditoria continuam necessários; não prometa que substituem observação de runtime.

Resumo prático

• Diferencie o add-on gerenciado da instalação via Helm.
• Valide Standard e Autopilot com matrizes próprias.
• Comprove coleta, detecção e resposta separadamente.
• Meça impacto na aplicação, não somente consumo do sensor.
• Teste credenciais, autoscaling, upgrades e falhas de comunicação.
• Negocie custos e limites de suporte antes de expandir.
• Registre exclusões e mantenha rollback autorizado.

Conclusão

Uma avaliação madura transforma o sensor em uma capacidade operacional verificável: cobertura conhecida, evidências úteis e recuperação ensaiada. Para DevOps, isso significa mudanças rastreáveis; para SRE, impacto controlado nos serviços; para Platform Engineering, um padrão reutilizável com exceções explícitas.

O objetivo não é demonstrar que um agente consegue iniciar. É demonstrar que a plataforma consegue detectar o que importa, preservar a confiabilidade e explicar com precisão onde sua proteção termina.