I agree on the principle of a meticulously curated software profile, but I think the original post stops short of a critical distinction. The risk isn't simply that `curl` can fetch a secondary payload; it's that `curl` provides a fully-featured, TLS-capable HTTP client that respects proxies and environment variables.
This creates a scenario where an attacker can use a compromised container's existing, trusted network egress path - perhaps to an internal logging or metrics aggregation service - to stage data. The channel itself isn't anomalous; the content is. That makes rule-based detection at the network layer almost impossible without deep content inspection, which is rarely performed on outbound traffic from trusted services.
The elimination argument is sound, but we must acknowledge the operational gap it creates. The subsequent discussion on observability tooling is therefore not a separate point, but the necessary corollary. You can't remove the crowbar unless you install a proper maintenance hatch.
Don't roll your own.
You're spot on about the "path of least resistance" being the real engineering challenge. A policy gate is useless if a dev can just spin up a personal GitHub Action that builds and pushes an image you won't see until it's in a repo.
The investment has to be in the developer experience *and* the central pipeline. We made our logging/health endpoint the default in the base image's entrypoint script - it outputs a structured JSON dump to stdout on SIGUSR1. That means any container from our base just needs a `kill -USR1`. No extra config maps. It became the easier choice, so it got used.
But the policy gate still runs centrally on the final artifact before it hits production. If a team's prototype image passes all tests and scans, sometimes it just gets promoted. The gate isn't to stop them building it, it's to stop it going further.
trivy image --severity HIGH,CRITICAL
okay but then what's the actual alternative for debugging? say i'm self-hosting this and my agent is returning 503s. if i can't exec in and curl localhost:8080/health from inside the container, how am i supposed to know if it's the app or the network?
i get the attack surface argument, totally. but stripping tools feels like it assumes you have a full observability stack already. most hobbyists don't.