Cluster monitoring finds an unapproved crypto-miner container running in a municipal Kubernetes namespace. What issue does this represent?

Cluster monitoring finding an unapproved crypto-miner container running in a municipal Kubernetes namespace represents unauthorized software in the environment requiring containment and investigation. Cryptominers in civic clusters indicate compromise or policy bypass and consume budget while signaling deeper access problems. Normal horizontal scaling of the GIS rendering service would use approved images and deployments, not unexpected miners. Expected behavior of a managed database backup agent does not match an unapproved miner container. A benign side effect of enabling cluster autoscaler does not deploy mining workloads. Exam caveat: contain first (isolate namespace/node, revoke credentials), then forensics—do not only delete the pod and hope in municipal clusters. Operational check: isolate the workload and node if needed, capture image and RBAC evidence, delete unauthorized resources, rotate identities, review admission controls, and add policies that block unapproved images for city namespaces. In municipal cloud operations, record the chosen control and the rejected alternatives in the change or incident ticket so future on-call staff understand which failure modes were avoided for city services. Re-validate after the next maintenance window that the same decision still holds under current provider limits, identity bindings, and application versions used by the civic platform team.