-
Notifications
You must be signed in to change notification settings - Fork 65
Certificate management using cert-manager #14
Comments
/assign |
/milestone Next |
I like this suggestion, but I don't think this should be tied to this bootstrap provider. To decide where it should belong, questions like "what other types of bootstrap providers may be created in the future/are being started now? do those providers have a need for cert management too?" |
we are starting to see some CAPI cert-manager adoption, but I don't think this is the right repository for it. Let's revisit if there is more evidence that this is the right place for cert-manager. Alternatively it would be really cool if you could open a new issue that shows how cert-manager fits into this repo and we can discuss there. /close |
@chuckha: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
While perhaps not for a 0.1 release (or even for this provider?), we should look at implementing certificate management as a first-class citizen.
Storing certs in the spec is bad, storing certs in secrets is better, using a CA to manage certs is best.
Ideally, there is a full PKI hierarchy with a single root CA with intermediary CA's per Cluster/Node.
This would have the following characteristics:
a) Keys are never transmitted over the wire or stored outside the node using them following PKI best practices
b) user-data size would be reduced, and arbitrary certificates could be created.
See kubernetes-sigs/cluster-api-provider-aws#847 and kubernetes/kubeadm#1631
The text was updated successfully, but these errors were encountered: