moonpiedumplings

I don't know what the commenter you replied to is talking about, but systemd has it's own firewalling and sandboxing capabilities. They probably mean that they don't use docker for deployment of services at all.

Here is a blogpost about systemd's firewall capabilities: https://www.ctrl.blog/entry/systemd-application-firewall.html

Here is a blogpost about systemd's sandboxing: https://www.redhat.com/en/blog/mastering-systemd

Here is the archwiki's docs about drop in units: https://wiki.archlinux.org/title/Systemd#Drop-in_files

I can understand why someone would like this, but this seems like a lot to learn and configure, whereas podman/docker deny most capabilities and network permissions by default.

Is your flux config public?

1. Corporations really, really love being admin on everybody elses devices. See kernel level anticheat.

2. I feel like people have gotten zero trust (I don't need to trust anybody) confused with "I don't trust anybody".

3. I was listening to a podcast by packet pushers and they were like "So you meet a vendor, and they are like, 'So what do you think zero trust means? We can work with that'".

I don't really understand why this is a concern with docker. Are there any particular features you want from version 29 that version 26 doesn't offer?

The entire point of docker is that it doesn't really matter what version of docker you have, the containers can still run.

Debian's version of docker receives security updates in a timely manner, which should be enough.

You are adding a new repo, but you should know that the debian repos already contain docker (via docker.io) and docker-compose.

I use authentik, which emables single sign on (the same account) between services.

Authentik is a bit complex and irritating at times, so I would recommend voidauth or kanidm as alternatives for most self hosters.

No, they added a beta vpn feature.

Does it require docker installed and being in the docker group, with the docker daemon running?

Just an FYI, having the ability to create containers and do other docker is equivalent to root: https://docs.docker.com/engine/security/#docker-daemon-attack-surface

It's not really accurate to say that your playbooks don't require root to run when they basically do.

Yeah. I'm seeing a lot a it in this thread tbh. People are stylizing themselves to be IT admins or cybersec people rather than just hobbyists. Of course, maybe they do do it professionally as well, but I'm seeing an assumption from some people in this thread that its dangerous to self host even if you don't expose anything, or they are assuming that self hosting implies exposing stuff to the internet.

Tailscale in to you machine, and then be done with it, and otherwise only have access to it via local network or VPN.

Now, about actually keeping the services secure, further than just having them on a private subnet and then not really worrying about them. To be explicit, this is referring to fully/partially exposed setups (like VPN access to a significant number of people).

There are two big problems IMO: Default credentials, and a lack of automatic updates.

Default credentials are pretty easy to handle. Docker compose yaml files will put the credentials right there. Just read them and change them. It should be noted that you still should be doing this, even if you are using gui based deployment

This is where docker has really held the community back, in my opinion. It lacks automatic updates. There do exist services like watchtower to automatically update containers, but things like databases or config file schema don't get migrated to the next version, which means the next version can break things, and there is no guarantee between of stability between two versions.

This means that most users, after they use the docker-compose method recommended by software, are manually, every required to every so often, log in, and run docker compose pull and up to update. Sometimes they forget. Combine this with shodan/zoomeye (internet connected search engines), you will find plenty of people who forgot, becuase docker punches stuff through firewalls as well.

GUI's don't really make it easy to follow this promise, as well. Docker GUI's are nice, but now you have users who don't realize that Docker apps don't update, but that they probably should be doing that. Same issue with Yunohost (which doesn't use docker, which I just learned today. Interesting).

I really like Kubernetes because it lets me, do automatic upgrades (within limits), of services. But this comes at an extreme complexity cost. I have to deploy another software on top of Kubernetes to automatically upgrade the applications. And then another to automatically do some of the database migrations. And no GUI would really free me from this complexity, because you end up having to have such an understanding of the system, that requiring a pretty interface doesn't really save you.

Another commenter said:

20 years ago we were doing what we could manually, and learning the hard way. The tools have improved and by now do most of the heavy lifting for us. And better tools will come along to make things even easier/better. That’s just the way it works.

And I agree with them, but I think things kinda stalled with Docker, as it's limitations have created barriers to making things easier further. The tools that try to make things "easier" on top of docker, basically haven't really done their job, because they haven't offered auto updates, or reverse proxies, or abstracted away the knowledge required to write YAML files.

Share your project. Then you'll hear my thoughts on it. Although without even looking at it, my opinion is that if you have based it on docker, and that you have decided to simply run docker-compose on YAML files under the hood, you've kinda already fucked up, because you haven't actually abstracted away the knowledge needed to use Docker, you've just hidden it from the user. But I don't know what you're doing.

You service should have:

• A lack of static default credentials. The best way is to autogenerate them.
  • You can also force users to set their own, but this is less secure than machine generated imo
• Auto updates: I don't think docker-compose is going to be enough.

Further afterthoughts:

Simple in implementation is not the same thing as simple in usage. Simple in implementation means easy to troubleshoot as well, as there will be less moving parts when something goes wrong.

I think operating tech isn't really that hard, but I think there is a "fear" of technology, where whenever anyone sees a command line, or even just some prompt they haven't seen before, they panic and throw a fit.

EDIT and a few thoughts:

adding further thoughts to my second afterthought, I can provide an example: I installed an adblocker for my mom (ublock origin). It blocked a link shortening site. My mom panicked, calling me over, even though the option to temporarily unblock the site was right there, clear as day.

I think that GUI projects overestimate the skill of normal users, while underestimating the skill of those who actually use them. I know people who use a GUI for stuff like this because it's "easier", but when something under the hood breaks, they are able to go in and fix it in 5 minutes, whereas an actual beginner could spend a two weeks on it with no progress.

I think a good option is to abstract away configuration with something akin to nix-gui. It's important to note that this doesn't actually make things less "complex" or "easier" for users. All the configs, and dials they will have to learn and understand are still there. But for some reason, whenever people see "code" they panic and run away. But when it's a textbox in a form or a switch they will happily figure everything out. And then when you eventually hit them with the "HAHA you've actually been using this tool that you would have otherwise ran away from all along", they will be chill because they recognize all the dials to be the same, just presented in a different format.

Another afterthought: If you are hosting something for multiple users, you should make sure their passwords are secure somehow. Either generate and give them passwords/passphrases, or something like Authentik and single sign on where you can enforce strong passwords. Don't let your users just set any password they want.

Not at all. In fact I remember the day my server was hacked because I’d left a service running that had a vulnerability in it.

Was this server on an internal network?

I like Incus a lot, but it's not as easy to create complex virtual networksnas it is with proxmox, which is frustrating in educational/learning environments.

This is untrue, proxmox is not a wrapper around libvirt. It has it's own API and it's own methods of running VM's.