Rodrigo Jorge · Preparado el 20 de octubre de 2026 a las 11:49 (hora de Brasilia, UTC-3). Hora de publicación por confirmar.
La alerta señala un Pod. El agente reúne evidencias y propone eliminarlo. Mientras la decisión espera a ejecutarse, ese Pod se elimina y se crea otro con el mismo nombre. La orden pendiente todavía indica que se elimine el Pod con ese nombre.
Este es un escenario hipotético. No hace falta un error de clasificación para que la acción afecte al objeto equivocado. El contexto quedó desactualizado entre el análisis y la ejecución.
La documentación de Kubernetes distingue entre nombre y UID. Un nombre puede reutilizarse después de eliminar un objeto; cada objeto nuevo recibe un UID distinto. La inferencia para una integración de respuesta es sencilla: guardar solo el nombre y el namespace no conserva la identidad del objeto que se analizó.
Como CISO, pediría ver qué información pasa de una etapa a la otra. ¿El executor recibe solo “eliminar el Pod analise” o también la identidad del objeto cuya eliminación se autorizó? Los nombres de este ejemplo son ilustrativos, no identificadores de producción.
La condición debe llegar a la API
Kubernetes ofrece un mecanismo específico para esta verificación: DeleteOptions.preconditions, con campos para UID y resourceVersion. La referencia documenta que una precondition que no se cumple impide la eliminación y devuelve 409 Conflict.
En el escenario descrito, una eliminación condicionada al UID original no debería eliminar al reemplazo con otro UID. Eso no hace correcta la decisión de eliminar. Evita un cambio de objetivo que una orden basada solo en el nombre no detectaría.
Mi propuesta para el playbook es registrar, junto con la acción, el cluster, el tipo de recurso, el namespace, el nombre y el UID observado. El executor debe transmitir la condición a la API por una vía cuya semántica se haya verificado. No basta con consultar el UID, compararlo en código y después enviar una solicitud de eliminación sin condición: el objeto todavía puede cambiar entre la consulta y la solicitud.
Ver el diagrama: el nombre permanece, la identidad cambia. Ejemplo conceptual con identificadores abreviados, sin datos de un incidente.
El UID permite distinguir entre objetos, pero no demuestra que el mismo objeto siga en el estado que se analizó. Si la decisión depende de ese estado, también hay que evaluar una condición de versión adecuada para la operación. Los campos llamados “versión” en otras API no tienen necesariamente la misma semántica.
Una condición rechazada debe devolver el flujo a la evaluación de las evidencias actuales. No es motivo para quitar la condición e insistir. El nuevo análisis puede ser automático si ese tipo de acción ya está delegado; no todo cambio exige aprobación humana. Lo que no debe transferirse silenciosamente es la autorización a otro objetivo.
La prueba de laboratorio se realiza entre la decisión y la ejecución: reemplazar un objeto de prueba por otro con el mismo nombre, ejecutar la orden anterior con la precondition y comprobar que el reemplazo sigue ahí. Guardar la solicitud enviada y la respuesta permite verificar si la integración realmente conservó la condición.
Para autorizar este flujo, exigiría evidencia de qué objeto se analizó y cuál podría verse afectado por la llamada. “El nombre coincide” deja esa pregunta sin resolver.
Referencias
- Kubernetes: Object Names and IDs, consultado el 18 de octubre de 2026.
- Kubernetes API: DeleteOptions y Preconditions, consultados el 18 de octubre de 2026.