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.

...

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.

...