That sounds cool and kind of makes sense. I’m going to go learn more about this.
Comment on SSL certificates for things inside the lab
plateee@piefed.social 4 days ago
I do DNS challenges with let’s encrypt for either host fqnds (for my kubes cluster) or wildcard for the few other services.
The trick is to do a subdomain off of a domain that you own (e.g. thing.lan.mydomain.com) this way, you can scope the DNS to only *.lan.mydomain.com if you’re conscious about scoped api security.
Using let’s encrypt is nice because you can have a valid ssl chain that android, iOS, windows, and Linux all trust with their default trusts without having to do something with a custom CA (ask me how awful that process can be).
xSikes@feddit.online 4 days ago
4am@lemmy.zip 4 days ago
Wildcard is actually good these days because you don’t have to set up DNS entries for your hostnames.
It’s not security, just obscurity - but in the age of crawlers, it’s helpful.
Also, you can use it internally for services on LAN and because LetsEncrypt is a CA everyone trusts, you don’t need to register a local CA (like a FreeIPA instance) with all your devices- which sometimes isn’t possible.
plateee@piefed.social 4 days ago
IIRC for my setup it’s a bit of both. My DNS API key is scoped to only handle the specific subdomain updates instead of my entire DNS account.
I still use a wildcard for that subdomain for non-kubernetes systems, but the cert plugins for kubes is excellent at handling a LE cert per lan fqdn.
This was my biggest reason to move to Let’s Encrypt. I have a Hashicorp Vault instance in my homelab for secrets and I tried using it for an internal CA (like how the lab at work is set up), but trying to get on every device and add the full Vault chain to each individual system’s trust store was massive pain in the ass.