kube-aws SSL certs are not production worthy

[pieterlange]

I've been snatching components from the kube-aws tool to make my own deployment workflow, but after the recent kubernetes blogpost i decided to re-evaluate kube-aws. Now, the tool has come a long way and it's the best off the shelf tool available but the big note on the docs should be enough to prevent a lot of people from using the tool:

PRODUCTION NOTE: the TLS keys and certificates generated by kube-aws should not be used to deploy a production Kubernetes cluster. Each component certificate is only valid for 90 days, while the CA is valid for 365 days. If deploying a production Kubernetes cluster, consider establishing PKI independently of this tool first.

Other than really pointing out to people that they'd need to secure (limit access, backup, ..) these assets themselves, what is the point of this limitation? I understand the TLS PKI underpins a lot of the security in the cluster, but is it really safer to let people figure out the solution to this problem for themselves?

[robszumski]

I agree with you on this, but I know its a balance of proper security and usability of the tool.

Now that we have reproducible assets, is there a flow for redeploying your certs?

[colhom]

@pieterlange I've added "Cluster PKI" to the production quality checklist.

Kubelet nodes should generate their own private keys and submit CSRs to a signing entity. In the near future, that remote signing (along with the approval queue) functionality will be built into the control plane. See Proposal for Kubelet TLS bootstrapping.

The approach of having Kubelet's generate their own keys and submit CSRs has a number of advantages over our current approach of pre-generating all the cryptographic assets.

• Worker nodes can generate unique cryptographic identity when they boot and join the cluster "on their own" (in response to autoscaling event, etc).

• Auditable record of new workers that wish to join the cluster, with an approval queue for new CSRs.

• Certificates can be created after the node has already been provisioned and booted, when metadata such as local IP address is on-hand. This means each Kubelet can generate it's own key pair which uniquely identifies that kubelet's IP address/ DNS name.

  Our current approach of generating the Kubelet TLS assets prior to worker instance creation means that a Kubelet certificate must be valid for any kubelet node This is not desirable!

• Kubelet private keys never leave the kubelet hosts. When a kubelet goes away, its key can be considered "gone forever", as it has never left that host.

[pieterlange]

Missed the work being done on this in kubernetes itself. Looks like that's the better approach! 👍

Our current approach of generating the Kubelet TLS assets prior to worker instance creation means that a Kubelet certificate must be valid for any kubelet node This is not desirable!

Certainly! Some kind of ACME (letsencrypt) process where the nodes self provision looks like a big improvement in this area.

[aaronlevy]

I'm going to close this as this is also captured in: #340

Please re-open if necessary.