What do you (or does your org do) to ensure that you’re not using maliciously-modified containers after pulling a new docker image?
I don’t run a complex setup as it seems you do, but if I pull a new Docker container, I closely monitor my pfsense firewall logs. A lot of times, I’ll deploy a recently released container on a small test server and just observe as I run it through it’s paces. Also, I like containers that have a rather established history. I look at things like stars, how they handle bug complaints, etc. Even when updates come out, unless it’s a dire security patch, I’ll wait until all the early adopters work out the bugs and do my work for me. Early adopters are a valuable resource.
I guess you could say it all comes down to calculated risk.
Monitoring firewall logs would show calls to suspicious IPs and domains after you pulled the Docker container. A MiTM attack is usually conducted between two communicating parties, rather than inside the server itself. The attacker intercepts traffic as it travels across a network or service path. MiTM are not always done exterior of the server, but usually. Strong ciphers are your friend. Although MiTM and PIC events can overlap, a PIC is usually an attacker gaining unauthorized access to a system. A PIC compromise occurs outside the public facing server, through a stolen administrator password, compromised developer workstation, exposed API key, or hijacked cloud account. Securing API, devices, frequent password rotation are good practices. Again, not always exterior of the server, but usually.