3 ms·
> The annoying part is getting it mounted in every pod that needs it and needs to consume it Yes, I suppose, in that it does need to be available to the pod.
by deathanatos 3y ago
> The annoying part is getting it mounted in every pod that needs it and needs to consume it
Yes, I suppose, in that it does need to be available to the pod.
This is one of those problems you're solving regardless of Kubernetes. I think a few lines of YAML to say "pull this secret into this Pod" is pretty acceptable to trying to figure out how it ends up on a VM with Ansible, or do I pull it from SSM, etc.
> Node has its own way of doing it, Java has its own way of doing it, etc etc and they all have their own little ideosyncracies that you have to worry about.
Yes… all the world doesn't use the same HTTP/TLS libs. That's just dealing with encryption, period, though; you've got this regardless of whether the CA is internal, or you're on k8s, etc.
Java, though is particularly annoying, most of its ecosystem stubbornly refuses to use the same formats for key material as the rest of the world does, necessitating a translation into its format. That is annoying, but nonetheless that's a Java-ism.
- SOLAR_FIELDS 3y agoIf you’re just running certs with a public CA you don’t have to worry about this though. It’s only if you’re rolling self-signed or an internal root CA. I think there’s a use case to be made here for running internal services on public certs. Obviously it won’t work for every use case but if your services are low traffic I don’t really see an issue of doing that and could save end users a lot of headache as they don’t have to worry about anything and you as the operator only have to worry about automating the DNS challenge