TL;DR
Um modelo de linguagem explica bem um pod que caiu se recebe o que um humano olharia: os eventos, o estado com o exit code, as últimas linhas do log anterior e a configuração de recursos e probes. O risco está no que vem junto. No nosso teste, o describe escondeu o valor que vinha de um Secret, mas mostrou em texto puro a senha de uma variável literal; e o log trouxe o token inteiro, porque a aplicação o escreveu. Mande eventos, estado e configuração; mande o log só mascarado; nunca mande Secrets, o bloco Environment do describe nem o kubeconfig.
O que mandar
| O quê | Por quê | De onde |
|---|---|---|
| Eventos do pod | Warning e Normal em ordem de tempo; é onde aparecem OOMKilled, probes, pull de imagem e agendamento. | kubectl get events --field-selector involvedObject.name=POD |
| Estado e último término | State, Last State, Reason e Exit Code: o número que separa memória de erro da aplicação. | describe pod, sem o bloco Environment |
| Trecho do log anterior | As últimas linhas antes da queda, já mascaradas. | logs --previous --tail=100 com o filtro abaixo |
| Requests, limits e probes | A configuração que explica metade dos erros. | describe pod (blocos Limits, Requests, Liveness, Readiness) |
O que nunca mandar
| O quê | Por quê |
|---|---|
| Valores de Secret | kubectl get secret -o yaml entrega os valores em base64, que qualquer um decodifica. |
| O bloco Environment do describe | Variável passada como valor literal aparece em texto puro, como a senha dentro de uma URL de banco. |
| Log sem filtro | A aplicação escreve o que quiser, inclusive tokens e URLs com senha. |
| kubeconfig e tokens de acesso | Dão acesso ao cluster inteiro; não fazem parte de nenhum diagnóstico de pod. |
O que vazou no teste
Um pod de teste com duas variáveis: DATABASE_URL com a senha escrita no manifesto, e GATEWAY_TOKEN lida de um Secret. A aplicação imprime as duas ao subir, como muita aplicação faz em modo de depuração. Os valores são fictícios.
kubectl -n loja describe pod pagamentos Environment:
DATABASE_URL: postgres://loja:senha-em-texto@db:5432/loja
GATEWAY_TOKEN: <set to the key 'token' in secret 'gateway'> Optional: falseO describe protegeu o valor do Secret e entregou a senha literal. O log entregou os dois:
kubectl -n loja logs pagamentosconectando com DATABASE_URL=postgres://loja:senha-em-texto@db:5432/loja
token=tok_ex_9f8a7b6cOs comandos, já filtrados
describe sem o bloco Environment
kubectl -n loja describe pod pagamentos \
| sed '/^ Environment:/,/^ Mounts:/{/^ Mounts:/!d;}'log com senha de URL e tokens mascarados (use --previous se o container reiniciou)
kubectl -n loja logs pagamentos --tail=100 \
| sed -E 's#(://[^:/@ ]+:)[^@ ]+@#\1***@#g; s#((token|senha|password|secret|key)[=:] ?)[^ &"]+#\1***#Ig'conectando com DATABASE_URL=postgres://loja:***@db:5432/loja
token=***avisoO filtro cobre formatos comuns, não todos. E o describe ainda mostra o Command do container, que pode ter segredo se alguém o colocou na linha de comando. Leia o que vai sair antes de mandar.
A correção definitiva fica na aplicação e no manifesto: segredo só por Secret (secretKeyRef ou volume), nunca como valor literal no manifesto, e nenhum log imprimindo credencial.
Perguntas frequentes
O describe esconde os Secrets?
Em parte. Variáveis que vêm de secretKeyRef aparecem como "<set to the key ... in secret ...>", sem o valor. Mas variáveis passadas como valor literal no manifesto aparecem em texto puro. No nosso teste, a URL do banco com a senha apareceu inteira no describe.
Mascarar o log resolve?
Reduz o risco, não zera. O filtro deste guia pega os formatos comuns (senha em URL, token=, password=), mas uma aplicação pode escrever segredo em qualquer formato. O mais seguro é a aplicação não logar segredo nenhum.
O que o provedor de IA faz com o que eu mando?
Depende do provedor e do contrato da sua conta. Leia a política de uso de dados da API que você usa, principalmente retenção e uso para treinamento, antes de mandar dados de produção.
Como o Kubepier trata isso?
O diagnóstico por IA do Kubepier usa a sua própria chave de API (Anthropic ou OpenAI) e explica o erro a partir dos eventos e do log do pod. Por isso vale para ele o mesmo cuidado deste guia: o que a aplicação escreve no log vai junto para o provedor que você escolheu.