Testes de Teste em Logs do Kibana: Uma Ferramenta CLI para Extraí-los com Autenticação e Scrubbing por Padrão

golikovichev 39 minutos atrás Testes de Teste em Logs do Kibana: Uma Ferramenta CLI para Extraí-los com Autenticação e Scrubbing por Padrão Simples 4 min 2K Segurança da Informação * Código Aberto * Testes de Sistemas de TI * Python * Tradução Autor do original: Mikhail Golikov A cada sprint, exportamos JSON do Kibana, percorremos centenas de registros e dizemos a nós mesmos que, mais tarde, os transformaremos em casos de teste.

Então, esse "mais tarde" nunca chega.

Os logs contêm chamadas reais de API. Endpoints reais, payloads reais, códigos de status reais da produção. Esta é a descrição mais próxima da especificação de como o sistema realmente se comporta. E quase nada disso se torna um teste automatizado. Porque traduzir manualmente leva mais tempo do que um sprint.

Estou cansado de "mais tarde". Eu escrevi o

secure-log2test , uma ferramenta CLI que lê a exportação do Kibana e gera um arquivo pytest pronto. Um comando. Testes funcionando.

A principal restrição, que definiu todo o design: nenhum dado deixa a máquina. Nenhuma chamada à API de LLM. Nenhuma nuvem. Tudo localmente.

Por que a restrição de privacidade é importante

Uma alternativa óbvia para construir a ferramenta: pedir a um modelo de linguagem que escreva testes a partir dos logs. Provavelmente funcionará. Exatamente até o momento em que alguém da segurança notar que os logs de produção com PII e a estrutura interna da API estão indo para um serviço externo.

Em um ambiente corporativo, essa conversa termina mal. Portanto, eu tornei isso impossível: não há chamadas de rede no núcleo.

Mas a maior parte da história de privacidade não é sobre chamadas de rede, mas sobre segredos dentro dos próprios registros. Os logs de produção vazam o tempo todo com

Authorization: Bearer ...

headers. Com

Cookie , com

X-API-Key . E cada vez mais com o corpo da requisição, que contém

password , refresh_token , client_secret ou como a equipe chamou seu campo de autenticação esta semana. Se os testes gerados carregarem esses valores, o conjunto de regressão se transforma em um dump de credenciais no disco, pronto para um commit acidental.

secure-log2test limpa três camadas antes que o arquivo de teste seja gravado:

• Uma lista estática de cabeçalhos de autenticação conhecidos (authorization, proxy-authorization, proxy-authenticate, cookie, set-cookie, x-api-key, x-auth-token, x-csrf-token, x-access-token, refresh-token, id-token, x-amz-security-token, authentication).

• Padrão Regex ( auth|token|secret|key|session|cookie|credential|bearer|password|passwd ), que captura nomes de cabeçalhos personalizados que as equipes inventam por conta própria.

• A mesma lógica percorre recursivamente o corpo da requisição JSON. Assim, valores como

  {"password": "..."}

, {"client_secret": "..."} , OAuth {"refresh_token": "..."} são substituídos por

REDACTED

na fase de parsing.

O marcador é um placeholder. As credenciais reais são injetadas em tempo de execução através de variáveis de ambiente ou fixtures.

Como funciona

pip install secure-log2test

secure-log2test data/sample_kibana_export.json --output tests_generated.py

pytest tests_generated.py -v

No repositório há uma exportação de exemplo, você pode ver a saída real sem levantar o Kibana.

Na entrada, o formato padrão do Kibana JSON hits.hits[*]._source (formato de qualquer pesquisa salva). Na saída, um arquivo pytest com uma função por registro de log:

def test_post_api_v1_orders_1(): response = requests.request( method="POST", url=BASE_URL + "/api/v1/orders", headers={"Authorization": "REDACTED", "Content-Type": "application/json"}, json={"item_id": 42, "password": "REDACTED"}, timeout=10, ) assert response.status_code == 201

Tanto o header Authorization quanto o campo password dentro do corpo são scrubbed. O dict original não é mutado.

Arquitetura: duas etapas

• Parsing ( core/ parser.py ). Pydantic v2 valida e normaliza os registros. Os registros com campos ausentes recebem padrões seguros em vez de falhar. Registros inválidos são descartados com um aviso, não silenciosamente. A edição é executada como um Pydantic field_validator , para que não possa ser ignorada acidentalmente.
• Geração ( core/ generator.py ). A lista validada passa por um template Jinja2 ( templates/test_ module.py .j2 ) e aterrissa como um arquivo .py . O template é o único lugar que sabe como o pytest se parece. Quer um formato diferente (httpx em vez de requests, unittest em vez de pytest, cenários k6)? Você muda o template, não mexe no parser.

Ciclo de feedback que deu v1.0.1

O primeiro lançamento do PyPI foi como v1.0.0 em 11 de maio. Em questão de horas, um usuário externo alimentou a ferramenta com uma exportação do Grafana Loki com cirílico do backend russo. O parser abriu o arquivo sem um argumento encoding explícito. No Linux, tudo funciona (utf-8 por padrão). No Windows, a mesma chamada falha com UnicodeDecodeError , porque o Windows usa cp1252 por padrão.

O bug foi relatado, eu reproduzi, corrigi em um dia. v1.0.1 foi lançado em 13 com encoding="utf-8-sig" explícito no file open. Eu adicionei um teste de regressão que simula o ambiente cp1252 para que o mesmo bug não volte.

O que aprendi: cada framework que processa a entrada fornecida pelo usuário precisa de um teste de encoding adversarial. O caminho feliz é trivial. O bug reside na lacuna entre "o que minha máquina de desenvolvimento faz por padrão" e "o que o shell do Windows faz por padrão".

O que os testes cobrem

59 testes no momento da v1.1.0, para o parser e o gerador:

• Entrada válida, registros malformados, campos ausentes, exportações vazias.
• Edição de cabeçalho por lista estática. Edição de cabeçalho por padrão regex. Cabeçalhos personalizados da equipe como X-Custom-Token , capturados pelo padrão.
• Body-edição walker: campos de senha, tokens de atualização OAuth, dicts aninhados, listas de dicts, pass-throughs não-dict.
• Coerção de duração float (Kibana às vezes emite 134.0 em vez de 134 ).
• Renderização de template, serialização de payload, nomeação de testes.
• Argumentos CLI, criação de caminho de saída.
• Teste smoke CI, que executa o CLI end-to-end na exportação de amostra e analisa o Python gerado através de ast.parse .
• O CI roda no Python 3.10, 3.11, 3.12 e 3.13 através do GitHub Actions.

Restrições honestas

• Apenas formato de exportação JSON do Kibana / Elasticsearch. O Grafana Loki Explore está sendo rastreado na issue #4.
• Entrada de arquivo único. Modo batch de vários arquivos no roadmap.
• Saída: apenas pytest. JSON / CSV para pipelines downstream está sendo rastreado na issue #5.
• Carrega todo o arquivo na memória. Não para exportações de vários gigabytes.
• Não constrói sequências de requisições e não define dependências.
• Não substitui o projeto manual de testes. Acelera a primeira passagem.
• Os testes gerados são um ponto de partida. Você os revisa, define a URL base através do env, adiciona setup/teardown onde necessário. Mas você começa com um código funcionando, não com um arquivo limpo e uma pilha de logs.

Para onde está indo

v1.1 adicionará asserções de corpo de resposta e correspondência de schema opcional (issue #1). v1.2 fornecerá regras de edição personalizadas através de um arquivo de configuração (issue #2). Duas good first issue slots estão abertos agora mesmo, se você quiser pegar.

Tentar

pip install secure-log2test

Repositório (MIT):

github.com/golikovichev/secure-log2test

Se sua exportação do Kibana for diferente do esperado, abra uma issue com uma amostra redigida. O parser é a parte mais fácil de estender.

Tags: qa testing python open source logging Hubs: Segurança da Informação Código Aberto Testes de Sistemas de TI Python 0 2 0 4K+ Alcance em 30 dias 1 Karma Golikov Mikhail @golikovichev Engenheiro de QA Inscrever-se Comentar Melhores do dia Semelhantes Mostrar os melhores de todos os tempos