> I don't think it's worth doing all these tweaks. I feel like i can understand this point of view, since following all of that advice indeed would be cumberso

> I don't think it's worth doing all these tweaks. I feel like i can understand this point of view, since following all of that advice indeed would be cumbersome. However, at the same time you definitely have to consider what it is that you're running on your infrastructure. A small internal system or even an ERP that's not exposed to the internet will probably give you more leeway in regards to being able to ship stuff now, without spending bunches of time locking everything down, especially if you build all of the containers yourself. On the other hand, a large finance application that is publically accessible and needs to weather thousands of attacks daily will probably need a rather different approach. Overall, however, i'd say that it's good to have lists of tips like these, because figuring out all of it alone would take a whole lot of time. That said, even in the more relaxed environments, it's generally a good idea to consider at least some of them, for example: > Unless you are very confident with what you are doing, never expose the UNIX socket that Docker is listening to: /var/run/docker.sock Being an early adopter of Docker, i once made this mistake on a throwaway VPS. It took less than 24 hours for it to be mining crypto. That said, the socket can be a good option for tools like Portainer (which implementations like Podman miss out on), yet it definitely should never be exposed publically. As always, security isn't a boolean of on/off, but rather is a sliding scale of sorts - figure out the risks that you're likely to be facing and choose the appropriate means to combat them. Of course, it would be better if Docker provided safer defaults, too.