https://rancher.com/ logo
Join Slack
Powered by
This message was deleted.
# k3s
a
This message was deleted.
w
f
Thanks. Looks quite advanced. Was thinking more about something like https://k3s.rocks/https-cert-manager-letsencrypt/
w
yeah, I'm using DNS01 challenges so I can get a wildcard cert
f
I'm thinking about doing the same. So I need something like you have at the end. Didn't even know about encryptedData, that looks handy. I guess. Wouldn't it be the same to manually store env vars in k3s? It's not like they would be used locally anyway
w
the encryptedData is from Sealed Secrets
I commit the encrypted "sealed secret" to git, apply it and the Sealed Secrets operator creates a decrypted k8s secret
I'm using a gitops approach, everything gets committed to git then applied (I'm using ArgoCD)
f
Yes I understand the basics of them, and say for development it sounds very nice, but it's not like I would test the cert stuff locally, or?
w
not sure what you mean
f
The keys, could they not be environment variables in the cluster? I'm new to this
w
so env vars can be stored in a configmap or a secret. either way, if I commit them in clear text in git then everyone on the internet can see them
f
Why commit them, can't secrets be set on the cluster?
You have to set a key to decrypt them on the cluster anyway, or do you not?
w
core principle of gitops is everything gets committed before being applied
yes, I have the Sealed Secrets master key stored in a password mgr
when I rebuild the cluster I create that manually
f
Hmm. So instead of commiting an environment key, which would require the value to be stored on the cluster, you commit a encoded value, which require a decode key on the cluster?
w
yup, the Sealed Secrets operator handles it automatically
f
So from the git point of view, it's not that much different, right? It's a kind of placeholder, which won't work without some manual value on the cluster
w
yup
there's other approaches, like Hashicorp Vault
or SOPS
f
The big benefit though, is for development. Where you could have same value on dev, as in prod, and you prevent developers from throwing secrets around in variables. Similar to Azure KeyVault, or AWS Key Management Service. Which is really great. But I'm not going to use my DNS keys for dev, that was what I meant
w
fairy nuff
f
A benefit of having environment variables as placeholders is that sharing the whole setup to others might be smoother, or sharing to other deploys. I'm not sure how that would work. Again, new to this. Argo CD looks nice. I've been pondering about how to deploy my own stuff. Since I use GitHub I've been considering GitHub Actions + ghcr, but without making my images public I would need to auth ghcr, and it becomes silly complicated
Public images isn't a big deal though, as they won't have anything secret in them, beside already public code. Perhaps it's just fine
w
yup, depends on what your objectives are. I'm building a homelab to self host a bunch of stuff
f
Same ish here. Not much "lab" though. But I don't mind having GitHub build things for me. Wonder how that is for private repos, where everything is private, and suddenly the image is public. Can it be easily found by some search. Private doesn't mean secret though, just don't want others to see my most horrendous stuff
w
I think you can have a private image too
just need to provide the container runtime with creds or put them in a registry proxy
or only publish to your local registry
f
Yeah, need creds
I've done this before. Just not in k3s
w
👍
f
Thanks a bunch for the info. Time to see if I can deploy some stuff 🙂
w
np. best of luck!
the k8s-at-home project has lots of great repos to crib off
👍 1
3 Views
Open in Slack
PreviousNext
Powered by