Automating issuance with Kubernetes

Automating is a big topic here, it should have some documentation (wiki style).

My issue is that automating makes it either tedious or less secure than 1 year certificates when using Kubernetes; or am I missing something?

For Kubernetes, people traditionally create a Kubernetes Secret with the TLS certificate and use it then. Manually re-generating a certificate and updating that secret every year isn’t a lot of work. This means that if someone somehow gets your private key they cannot generate new valid certificates for your domain.

To be automated, one would need to have an external server running a cronjob with access to your Kubernetes cluster and your CSR certificate, so that means a really secure server and actually an additional server (you’re not supposed to have a Kubernetes Pod with access to the cluster on which it’s running).

Another hacky option may be to a Kubernetes Secret with the CSR and have each Pod (i.e. each service using your TLS certificate) to use it to get the TLS certificate at startup time. This delays start-up time but the real difficulty is ensuring that Pods restart somehow periodically. One hacky way to do that may be to force re-deploy a new version each 60 days. Also it means that if someone gets access to your server, it’s possible to get unlimited TLS cert generator for your domain.

as soon as someone gets access to any server which is tied to your domain they automatically get an unlimited cert generator, it doesnt need “Kubernetes” (whatever that may be) for it.

Why would these hypothetical bad guys need "new" valid certificates having stolen the private key? The existing certificates for your domain are public documents and those will work perfectly for them now that they've stolen your private key. Your only option here is to revoke all certificates for that key, throw away the key and regenerate everything.

I think your whole crazy design revolves around a misunderstanding of Public Key encryption and the surrounding infrastructure. I strongly advise you not to try to invent a completely different security mechanism but to instead embrace how the Web PKI is actually supposed to work, which means you should protect your Private Key and stop treating public documents like CSRs (Certificate Signing Requests) and Certificates as if they were secrets.

If you want Let's Encrypt certificate issuance and renewal to be handled by a separate "pod" that pod either needs access to the Private Key or to a CSR generated using that Private Key and a complete list of the names to be included on the certificate. The pods that provide a TLS service identified by the certificates need access to the Private Key and to a current valid certificate, but while the Private Key must be protected, the certificate is a public document and doesn't need to be kept in a "Kubernetes Secret" at all.

You’re right I should be a bit more explicit. I mean that it gives access not only to that private key, but also to a way to generate new public keys for any of your domains. Sure you’d have to change your private key and CSR if compromised, but for example with only the private key on the server, I can have different private/public key per subdomain. Here the attacker would basically have access to my private key and a way to generate public keys for my “verified” domain without needing a login that isn’t stored on the server.

Maybe that would help, but I think mostly the problem is still that you're confused, e.g. talking about attackers gaining "a way to generate public keys" when in fact the public and private key are of necessity generated together by the same algorithm.

If a hypothetical attacker controls your servers, they will be able to obtain TLS certificates from a self-service Certificate Authority, not just from Let's Encrypt but many others offer this service. It doesn't matter whether you insist on the most laborious certificate application process possible, they're not constrained by that.

Even if you insist on only entering your house by doing a six minute dance routine with a chorus and orchestral accompaniment, a bad guy can still just break a window, grab what they want and run off, they aren't obliged to hire an orchestra and do the dance routine just because that's how you like to do it.

1 Like

there first needs to be a safe way to pay for things online for that to be a reasonable option

for me its not about the price, its about not wanting to use risky payment methods like credit cards
(which were never a safe way to pay for things even offline) and wanting to avoid what appears to be an increasing risk of censorship in the face of increasingly ridiculous behaviour in web browsers.

especiallly for that first certificate when its testing the waters of trust

automating any of it here is not really option right now - there are multiple domains on the same server and its not some off-the-shelf preconfigured platform and any tools used for renewals would require quite a lot of trust and I cannot take the risk of users being blocked from any public page on any domain here via ordinary http.
I would need to fully understand the process before attempting to automate any of it.

I won’t break what users are using now on any of those domains just to enable tls on one of them

that first one would be testing the waters …

all or nothing was NEVER an option for anything that looks so risky.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.