TLS certs for handlers we run

[miekg]

For the log handler we have the tls-cert and tls-key flags that read a cert. It would be nice(r) if we just embed a ACME client that gets these certs from a CA.

Alternatively this could be outsourced, but then we would need to periodically re-read the key and cert from disk.

I think at this point I prefer ACME as I need to run my own CA anyhow.

[pires]

In my testbed, I'm outsourcing this to cert-manager, as detailed in the README.md.

If you're getting ACME support maybe you could explore caddy server?

[miekg]

[ Quoting <[email protected]> in "Re: [virtual-kubelet/systemk] TLS c..." ]

In my testbed, I'm outsourcing this to cert-manager, as detailed in the README.md.

Might be worth looking how that's done. Ideally I want that thing *also* to be run as a unit, which may or may not be managed by systemk. (I.e. systems bootstraps, see cert-manager, get's certs, enabled TLS on handlers)

If you're getting ACME support maybe you could explore caddy server?

If feel this is the more generic way solving this, i.e. even certmanager may support this (no idea if it does) /Miek

…

-- Miek Gieben

[pires]

I don't think you can run cert-manager without an API server given it requires CRDs to function - cert-manager uses Kubernetes object store as its storage backend.

Anyways, it seems you're hinting at first adding support for static pods #27.

[pires]

But you may be missing something here. Yes, you can use your own CA for signing systemk HTTPS endpoint but it must be validated by the API server (there's a flag for client CA certificate), meaning that CA must be known to the API server before systemk registers as a Node.

Also, and unless the CA is shared w/ Kubernetes, you can't use said CA to bootstrap TLS for authenticating systemk as a Node against the API server.

If I'm not missing anything, that seems like a lot of work for very little gain.

[miekg]

yes i'm looking to share the root-ca with k8s. I.e. I have step-ca running somewhere providing this. The problem is I don't like 'running somewhere' so it needs to run under systemk. Now for bootstrapping it may not run under systemk, but once that's done everything should be running in-cluster and manageable via kubectl

[pires]

OK so your goal is to have systemk setup the CA and then bring up the API server with that CA? If yes, that's totally doable. The problem later is how to join other systemk instances, maybe even kubelets, as the CA lives only on one machine.

[miekg]

OK so your goal is to have systemk setup the CA and then bring up the API server with that CA? If yes, that's totally doable.

yep!

[pires]

A suggestion is for this to be implemented as an opt-in vs opt-out feature.