4 ms·

That means you designed your architecture incorrectly; get an internal CA and automate it, then pod can just have long term root CA embedded in it.

by adql 3y ago

SOLAR_FIELDS 3y ago
That’s kind of the same problem as mentioned here though, you still have to mount that root CA in all your pods. An internal CA is also, while achievable with cert-manager these days, not exactly trivial to set up.
- diarrhea 3y ago
  I’ve had good success with step-ca. It was easy enough to be called trivial actually!
  - SOLAR_FIELDS 3y ago
    I actually used smallstep when I rolled my own CA as well. They have nice tooling.The most annoying part of the whole ordeal is dealing with cert formats IMO
- deathanatos 3y ago
  > 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
- pojzon 3y ago
  Im surprised ppl dont do double tls termination with ebpf certs between pods. Your customer sees one cert at the LB level. LB talks to ingress which also has own cert by CAM. And any other pod on the cluster uses mtls via ebpf.
  - SOLAR_FIELDS 3y ago
    Do you have any more details on the latter half of the setup? The first half is trivial and almost every cloud provider offers that as a managed product. Does the internal one involve some sort of service mesh?

That means you designed your architecture incorrectly; get an internal CA and automate it, then pod can just have long term root CA embedded in it.

by adql 3y ago

That means you designed your architecture incorrectly; get an internal CA and automate it, then pod can just have long term root CA embedded in it.

SOLAR_FIELDS 3y ago

That’s kind of the same problem as mentioned here though, you still have to mount that root CA in all your pods. An internal CA is also, while achievable with cert-manager these days, not exactly trivial to set up.

diarrhea 3y ago
I’ve had good success with step-ca. It was easy enough to be called trivial actually!
- SOLAR_FIELDS 3y ago
  I actually used smallstep when I rolled my own CA as well. They have nice tooling.The most annoying part of the whole ordeal is dealing with cert formats IMO
deathanatos 3y ago
> 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
pojzon 3y ago
Im surprised ppl dont do double tls termination with ebpf certs between pods. Your customer sees one cert at the LB level. LB talks to ingress which also has own cert by CAM. And any other pod on the cluster uses mtls via ebpf.
- SOLAR_FIELDS 3y ago
  Do you have any more details on the latter half of the setup? The first half is trivial and almost every cloud provider offers that as a managed product. Does the internal one involve some sort of service mesh?