I don't agree (based on the fact that the host can run multiple images/VMs). In my opinion first of all the host should be secured (Firewall & Fail2ban etc...).
To distribute security to the single images/VMs increases complexity and the likeliness that some image/VM will miss some security filter, and leaves the host itself unprotected (e.g. network time sync & ssh & other stuff will probably be running, any update to the host's SW might result in unexpected services running, etc...).
An additional (dedicated) layer of security in the images/VMs would of course still be ok.
But you can also use a container as first contact and redirect to other containers. You can bind a network device to a container.
For example a reverse proxy container which redirects to a gitea container or a wordpress container depending on the request. The reverse proxy container can also centralize the security with certificate handling or fail2ban.
You still need access to the host, via ssh for example, to start the containers and do some basic maintenance. Won't you have fail2ban installed on the host since your ssh port would be open?
If you need direct access to the host, it’s probably a non production environment or you’re doing containers wrong. Kubernetes clusters provisioned with Terraform, for example, should almost never require ssh access to workers nodes.
To distribute security to the single images/VMs increases complexity and the likeliness that some image/VM will miss some security filter, and leaves the host itself unprotected (e.g. network time sync & ssh & other stuff will probably be running, any update to the host's SW might result in unexpected services running, etc...).
An additional (dedicated) layer of security in the images/VMs would of course still be ok.