---
title: "Mesmo nome, outro alvo"
slug: "mesmo-nome-outro-alvo"
date: "2026-10-20"
publishedAt: "2026-10-20T11:49:00-03:00"
author: "Rodrigo Jorge"
summary: "O agente analisou um objeto, mas o ambiente mudou antes da execução. Uma ação autorizada pelo nome pode atingir um substituto que nunca foi avaliado."
origem: "Análise"
status: "published"
---

**Rodrigo Jorge** · Preparado em 20 de outubro de 2026, às 11:49 (horário de Brasília, UTC-3). Horário de publicação a confirmar.

O alerta aponta para um Pod. O agente coleta evidências e propõe removê-lo. Enquanto a decisão aguarda execução, aquele Pod é excluído e outro é criado com o mesmo nome. A ordem pendente ainda diz para remover aquele nome.

Esse é um cenário hipotético. Nenhum erro de classificação é necessário para que a ação alcance o objeto errado. O contexto envelheceu entre a análise e a execução.

A documentação do Kubernetes distingue nome e UID. Um nome pode ser reutilizado depois da exclusão; cada objeto criado recebe um UID distinto. A inferência para uma integração de resposta é simples: guardar apenas nome e namespace não preserva a identidade histórica do alvo analisado.

Como CISO, eu pediria para ver o que atravessa essa passagem. O executor recebe só “remover o Pod `analise`” ou recebe também a identidade do objeto cuja remoção foi autorizada? Os nomes deste exemplo são ilustrativos, não identificadores de produção.

## A condição precisa chegar à API

O Kubernetes oferece um mecanismo específico para essa conferência: `DeleteOptions.preconditions`, com campos para UID e `resourceVersion`. A referência documenta que uma precondition não atendida impede a exclusão e retorna `409 Conflict`.

No cenário descrito, uma exclusão condicionada ao UID original não deve remover o substituto com outro UID. Isso não torna a decisão de excluir correta. Evita uma troca de alvo que uma ordem baseada apenas no nome não detectaria.

Minha proposta para o playbook é registrar, junto à ação, o cluster, o tipo do recurso, o namespace, o nome e o UID observado. O executor deve transmitir a condição à API, por um caminho cuja semântica tenha sido verificada. Não basta consultar o UID, comparar em código e depois enviar uma exclusão sem condição: o objeto ainda pode mudar entre a consulta e o pedido.

[Ver o diagrama: o nome permanece, a identidade muda](/assets/artigos/mesmo-nome-outro-alvo-pt.svg). Exemplo conceitual com identificadores abreviados, sem dados de incidente.

O UID resolve a distinção entre objetos, mas não demonstra que o mesmo objeto permaneceu no estado analisado. Se a decisão depende desse estado, é preciso avaliar também uma condição de versão adequada à operação. Campos chamados “versão” em outras APIs não têm necessariamente a mesma semântica.

Uma condição recusada deve devolver o fluxo à avaliação das evidências atuais. Não é motivo para retirar a condição e insistir. A nova análise pode ser automática se essa classe de ação já estiver delegada; uma aprovação humana não é obrigatória em toda mudança. O que não deve ser transferido silenciosamente é a autorização para outro alvo.

O ensaio de laboratório cabe no intervalo entre decidir e agir: substituir um objeto de teste por outro com o mesmo nome, executar a ordem antiga com a precondition e conferir que o substituto permanece. Guardar o pedido enviado e a resposta permite verificar se a integração realmente preservou a condição.

Para liberar esse fluxo, eu exigiria evidência de qual objeto foi analisado e qual poderia ser afetado pela chamada. “O nome confere” deixa essa pergunta em aberto.

### Referências

- [Kubernetes: Object Names and IDs](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/), consultado em 18 de outubro de 2026.
- [Kubernetes API: DeleteOptions](https://kubernetes.io/docs/reference/kubernetes-api/definitions/delete-options-v1-meta/) e [Preconditions](https://kubernetes.io/docs/reference/kubernetes-api/definitions/preconditions-v1-meta/), consultados em 18 de outubro de 2026.