Page Comparison

...

1. Create/Apply CSR (like other resources)
2. Approve CSR (new via /subresources/approval)
1. K8s signer will issue a certificate some time after approval of CSR takes place
2. To read about the new /subresources level, check Supporting subresources
3. Watch/monitor CSR to see when a .status is created
4. Return signed certificate obtained from CSR .status.certificate all the way back to etcd
5. DCM will read the certificate from etcd

See also: Sequence Diagram. 

With regards to DCM obtaining the signed user certificate per cluster (mostly point #5 above), for now it will be based on lazy-loading the certificates from etcd into MongoDB whenever the user requests a kubeconfig to be generated for the logical cloud cluster.

...

• 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-data field as a base64-encoded string).
• 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 data /decrypt data without exposing this key. However, it's unclear what this would look like when applied to a kubeconfig.

...

Regarding what happens outside of DCM (points #2, #3 and #4 above), and since the K8s signer issues a certificate some time after approval of a CSR takes place (making the whole process very much asynchronous.. in fact, this could also be done manually by humans), the Monitor has been chosen as the tool to track what happens to the CSR and trigger other actions.

Again, the The reader is referred to the the Sequence diagram to Diagram above to better understand how the Monitor, together with cluster etcd and rsync (cluster watcher) work together to detect that a CSR has been approved and has issued a certificate in its own .status.certificate subresource field. This certificate is then propagated back to the main etcd instance, where DCM can read from using the lazy-load method presented above.

...