5 ms·

While it's true that nginx is secure by default, this image adds extra best-practice security addons on top of the out-of-the-box security. Rate limiting, fail2

• GordonS 6y ago
  Wouldn't you generally want all that stuff on the Docker host though? EDIT: or running as separate containers on the host - the point is that these are security provisions you want to apply across all containers, not just for Nginx.
  • andybak 6y ago
    OK. Just as I thought I understood the Docker world view... Surely all the complexity should be inside the container and the surrounding host should be as vanilla as possible. Isn't the idea to push the complexity into the layer where builds are reproducible and state is controllable? I am probably misunderstanding something here. I'm fairly new to this.
    • hermitmaster 6y ago
      You’re correct. All the traffic should be routed to the nginx endpoint and the host should be vanilla.
      • zepearl 6y ago
        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.
        • kenniskrag 6y ago
          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.
          • rudasn 6y ago
            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?
            • hermitmaster 6y ago
              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.
              • unionpivo 6y ago
                This is overkill for 90% of projects out there.
        • deleted 6y ago
          [deleted]
        • deleted 6y ago
          [deleted]
        • deleted 6y ago
          [deleted]
    • uponcoffee 6y ago
      It violates a lot of principles of using containers. There's no separation of concerns here, builds aren't reproducible, it hijacks logging for its own setup, appears to allow RCE of php files on another host in the event it is compromised (does it make sense to store/bundle php files in this container if it's not meant to handle php?)... Etc
      • andybak 6y ago
        Sorry - I'm not clear what the referent of the word "it" is here? You mean Bunkerized is violating these principles? Or the approach the gp suggests?
        • uponcoffee 6y ago
          The linked repo. I mostly agree with you that most of this should be in containers; I should have been more clear to what part of your comment I was addressing. In regards to docker worldview, this project currently doesn't follow best practices. And while I agree mostly with this statement: > Surely all the complexity should be inside the container The caveat being that complexity should be split up into separate concerns. Otherwise there's little difference between the host and container aside from an extra layer of abstraction. For example, this repo should probably be split into several containers: cert management should probably be its own container, which a shared volume for certs); php should be rolled into its own container, and php files should reside there; logging shouldn't be handled at the container level; firewall concerns (namely fail2ban) probably should be handled at by the host, or in a container with appropriate permissions; etc
    • rhizome 6y ago
      I believe the conventional wisdom is for one process per container.
      • diarrhea 6y ago
        That is pretty much what Docker enforces,too (so it's baked in, not just happens to be best practice). You can run multiple processes in a container, e.g. using `&`, but that gets ugly so fast you'll notice you're trying to square the circle.
        • GoblinSlayer 6y ago
          Bash is a user interface, not a service runner. If tini could run several processes, what can possibly go wrong?
        • TheDong 6y ago
          No, it is not baked in. Did you know the linux kernel requires you to set an init? If you check what you were booted with (/proc/cmdline), it probably includes something like `init=/usr/lib/systemd/systemd`. Docker requires you to set a single entrypoint not because it's "baked in", but because that's the way linux works: when you create a new namespace, you run a single program as its pid1, just like when you boot linux, a single program is pid1. It's very easy to set pid1 of a docker container to runit or various other process runners to run multiple processes. Arguing otherwise is no different than arguing that linux only supports running one process because if you set "init=/bin/bash" at the cmdline, it gets ugly real fast to run a multi-process system off it.
    • sgk284 6y ago
      You're correct and absolutely want it all wrapped up in a container (or multiple containers, depending on preferences). And yes, you want the host as vanilla as possible. Generally just running the orchestration layer (Kubernetes, Swarm, Nomad) and maybe some logging / metrics stuff (and, depending on who you ask, sshd).
  • lmeyerov 6y ago
    I'd want either in docker for host, or network/cdn/elb/etc if not on host
  • sgk284 6y ago
    I think the assumption is that nginx is your frontend server / load balancer, so all external requests go through it.
• superkuh 6y ago
  Rate limiting what? Banning what login process to nginx with fail2ban? And what's "weird behavior"? Blocking what groups from access? Users are uploading files and you need to virus scan them? These are problems that don't actually exist by default for most situations. They imply a need for, well, something like Bunkerized-Nginx. But the need necessarily implies something less secure than a simple repo nginx install. In most cases this is the tail wagging the dog.