...
- The existing user's private key (which was originally used to sign the CSRs for each cluster) has been previously generated by DCM locally and stored in and only in MongoDB
- The private key does not leave MongoDB at any point until:
- after the kubeconfig has been fully generated and returned back to the user/client as an HTTP response (the private key is in the kubeconfig's user's
client-key-datafield as a base64-encoded string).
- after the kubeconfig has been fully generated and returned back to the user/client as an HTTP response (the private key is in the kubeconfig's user's
- The certificates issued by the clusters are transported from the cluster, to rsync, and back to DCM over etcd, which then stores them in MongoDB as well.
- A high-security implementation could leverage the Trusted Platform Module (TPM) present in most edge deployments to store the private key and sign /encrypt data without exposing this key. However, it's unclear what this would look like when applied to a kubeconfig.
...