111–120 of 275 posts
It's more about the setting of the ufw. Docker relies on their own NAT table, and setting ufw accordingly requires a bit of setup. That said, having a good setting from hosting provider is quite easier ans safer.
> If a rogue database user starts deleting stories, it would get noticed a whole lot faster than a database being dropped all at once. This feels like an odd statement. Surely a database being dropped all at once is about the loudest possible thing that could happen to a database-reliant application?
Yes, but eg it doesn't show up in bandwidth monitoring.
Earlier quoted context omitted.
And now Google is picking up the definition of footgun(1) from Hacker news! (1) https://i.imgur.com/pHlLFJA.png
Your screenshot shows an earlier date (25-Jun-2018) next to the definition.
The funny thing is there are definitions for it in wikionary and urbandictionary yet it is picking the HN one.
Earlier quoted context omitted.
No, they run databases that listen to localhost, and then use docker to forward that private binding to the public ip
No, they run database that listens to 0.0.0.0/0 and/or ::0/0 on a private isolated network interface (eth0 inside Docker namespace), then let Docker create a NAT to forward packets from a public network interface on the host to this database. The latter is a mistake. It doesn't ever make sense to expose hosted container ports to host, with the exception of public-facing stuff (like a webserver). The whole backoffice…
Yes they should’ve configured, checked, etc. But defaults sound be secure by default
I think docker/podman with firewalld behaves the same way. I was astonished when I found it out. I think you can however bind to localhost exclusively by using the ip in the argument: docker run -p 127.0.0.1:5555:5555 ....
I never really liked the whole container idea, but this is ridiculous.
Earlier quoted context omitted.
From 3.6 the default binding is localhost. That would be ook, except that if you mail the power, you listen to all interfaces. This will happen with Redis as well and is a problem with both docker and its dockerfile
Even on localhost, you should still use auth. One shouldn't naively assume someone can't break into your server.
So let’s start blaming every piece of software that listens to localhost, but is exposed by docker.
Not a fan of mongo, but the defaults are way better than before.
Docker needs to fix their defaults
It's not all that great blaming the victim. They clearly made the right moves with at least some of their configuration decisions and leaned on the underlying platform not being bonkers (but alas, it was: https://github.com/moby/moby/issues/4737 and https://github.com/moby/moby/issues/22054 ). Should they have hardened in all the other ways for defense in depth, e.g requiring authentication from localhost? Sure. Shou…
> Published ports > This creates a firewall rule which maps a container port to a port on the Docker host to the outside world. Source : https://docs.docker.com/config/containers/container-networki... Requiring authentication from localhost does not seem relevant to me, given that the creds would be stored somewhere, either in memory either in a file anyway, but exposing a port is not "binding on localhost". However…
That only works with local communication unless you use docker swarm. So byebye high availability.
If you're going to make suggestions, at least think about them from a production point of view.
Earlier quoted context omitted.
That might be true, but regardless of docker (or other, similar solutions), shouldn't MongoDB have had auth protection?
MySQL/MariaDB have a completely open root account too... although default firewall rules should prevent public access too, unless Docker likes to punch that hole open too. Yes, root account password and access permissions should be changed upon a fresh install, but the real issue here is Docker's "helpfulness" by opening ports without explicit permission. That's absurd, and has no reasonable excuse.
> Installation of MySQL creates only a 'root'@'localhost' superuser account that has all privileges and can do anything.
It's only a local account. Sure, it would be great to have a password on it, but it's not "a completely open root account".
Earlier quoted context omitted.
Staying away from it is still not the best strategy - at least learn and play with it to understand its strengths and weaknesses. > it seems to give a lot of engineers into thinking they know infra when they really don't Maybe, but technology changes over time - I don’t see many new projects choosing VMware over docker/OCI for new infrastructure deployment since you usually don’t need a full VM for applocations that…
I suppose my premise is that engineers often delude themselves into thinking that they know it well enough to implement docker when they dont. Id much rather prefer that the regular developers focus on the coding and leave those decisions to actual devops folks who can focus on getting this stuff right. But the simplicity of dockerfile lulls many into thinking if they run something with it it's production ready.
The biggest issue with docker is the false sense of security it seems to give a lot of engineers into thinking they know infra when they really don't. I stay away from this because I don't understand it fundamentally, and now this proves it's better to not think these new technologies are your friend unless you actually know what you're doing (which apparently most don't).
Staying away from it is still not the best strategy - at least learn and play with it to understand its strengths and weaknesses. > it seems to give a lot of engineers into thinking they know infra when they really don't Maybe, but technology changes over time - I don’t see many new projects choosing VMware over docker/OCI for new infrastructure deployment since you usually don’t need a full VM for applocations that…