[-] WiseCookie69@alien.top 1 points 11 months ago

ArgoCD. If there's something that doesn't come with a Helm chart, i just wrap it into bjw-s' common chart (https://github.com/bjw-s/helm-charts/tree/main/charts) and call it a day.

[-] WiseCookie69@alien.top 1 points 1 year ago

If they're VMs, just install the kernel you want - keeping them updated is your responsibility anyways. If they're containers (Virtuozzo), you're not gonna change the kernel anyways.

[-] WiseCookie69@alien.top 1 points 1 year ago

Normal background noise. You expose stuff to the public and in return you make friends with a bunch of bots.

[-] WiseCookie69@alien.top 1 points 1 year ago

Granted I use Kubernetes, but here you go:

  • I run stuff with user namespaces, so even a root process within the container is unprivileged on the host
  • I isolate namespaces via NetworkPolicies
    • Even my Nextcloud instance has no business to check upstream for updates (i have renovate for that)
  • I use securityContexts to make my containers as unprivileged as possible
    • drop all capabilities
    • enforce a read-only container filesystem
    • enforce running as a specific UID/GID (many maintainers are lazy and just run their stuff as root)
[-] WiseCookie69@alien.top 1 points 1 year ago

Been an OVH customer for 10+ years. Always been a solid choice.

[-] WiseCookie69@alien.top 1 points 1 year ago

Ahh, good old IRC. Look into something like InspIRCd. It should already allow you to restrict channel creation to registered accounts. Then combine that with something like Atheme or Anope IRC Services. I couldn't find any PAM modules, but Atheme should at least support an external database (back in the day we used a mysql backend).

[-] WiseCookie69@alien.top 1 points 1 year ago

Look at K3s. Since a while it has built-in support for Tailscale (can also use Headscale).

Alternatively, it doesn't really matter how or where your nodes are located, if you add a VPN to allow them to talk to each other.

Your main issue would be storage. But that's easily fixed with a topology aware CSI and then keeping your stateful workloads either wherever they got their volumes provisioned, or forcing them to be provisioned on your home servers.

[-] WiseCookie69@alien.top 1 points 1 year ago

I'd argue it's up there :) In the end you're quite limited with what you can do as an unprivileged user.

Granted it's not for Docker, but Kubernetes, but userns is userns. This Kubernetes blog post even has a short demo :) https://kubernetes.io/blog/2023/09/13/userns-alpha/

[-] WiseCookie69@alien.top 1 points 1 year ago

run the container as a non root user (some containers won't work so they need to be run as root user)

To avoid issues with containers, could also make use of user namespaces: https://docs.docker.com/engine/security/userns-remap/

Allows a process to have root privileges within the container, but be unprivileged on the host.

[-] WiseCookie69@alien.top 1 points 1 year ago

What is your worst case, if someone gains access to your stuff? We can't answer that. That doesn't necessarily depend on your applications, but more in the data behind them.

Can be everything. From nothing to financial ruin through identity theft.

[-] WiseCookie69@alien.top 1 points 1 year ago

I host it to have my own data under my own roof.

  • Nextcloud (everything from pictures, over tax stuff to my keepass database)
  • Matrix server (even more important with every government on this planet pushing against encrypted messengers)
  • PiHole, that i can also use via DoH from my phone
  • Traccar instance to keep an eye on my car, when it's in for service / maintenance / when i'm abroad
  • ...

I've worked in the hosting industry. I've witnessed an internal breach, where an employee abused access over a few corners and fetched files matching a certain pattern from all customer VPSes (Virtuozzo container based VPSes have their root filesystem accessible from the host)

view more: next ›

WiseCookie69

joined 1 year ago