3 ms·

> An internal CA is also, while achievable with cert-manager these days, not exactly trivial to set up. …it's not exactly hard, though? Install cert-manager, a

> An internal CA is also, while achievable with cert-manager these days, not exactly trivial to set up. …it's not exactly hard, though? Install cert-manager, and it's all of 3 resources? 1 self-signing Issuer, one Certificate (the CA cert), and then an Issuer that issues certs under that CA cert. Then any service that wants an internal cert adds a Certificate issued by that Issuer.

SOLAR_FIELDS 3y ago
Simple if you’re already familiar with cert-manager. The annoying part is getting it mounted in every pod that needs it and needs to consume it, which is the point the original article made. 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.
- 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 ago
    If 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

SOLAR_FIELDS 3y ago

Simple if you’re already familiar with cert-manager. The annoying part is getting it mounted in every pod that needs it and needs to consume it, which is the point the original article made. 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.

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 ago
  If 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