When the CryptOS Manager and Web come online, they should get their own serving and identity certificates from a real CryptOS CA rather than a self-signed or third-party certificate. This is the dogfooding story: the management plane of the PKI is itself secured by the PKI.
There are two deployment shapes.
When it is not running on Kubernetes, the Manager and Web should bootstrap themselves on startup, enroll with a CryptOS CA, and obtain a real issued certificate.
When it is running on Kubernetes, the assumption is that the cluster has already been set up with CryptOS as its PKI (see #113) before the Manager and Web are deployed, so cert-manager (see #110) issues their certificates. In that case they inherit CryptOS-backed PKI through the cluster instead of bootstrapping themselves.
Either way the result is a "yes, we use it too" setup where the management app runs on certificates CryptOS issued.
Not scheduled. The bootstrap and enrollment mechanism for the non-Kubernetes case, how it trusts the CA to begin with, renewal, and the exact interaction with the cluster PKI are still open.
When the CryptOS Manager and Web come online, they should get their own serving and identity certificates from a real CryptOS CA rather than a self-signed or third-party certificate. This is the dogfooding story: the management plane of the PKI is itself secured by the PKI.
There are two deployment shapes.
When it is not running on Kubernetes, the Manager and Web should bootstrap themselves on startup, enroll with a CryptOS CA, and obtain a real issued certificate.
When it is running on Kubernetes, the assumption is that the cluster has already been set up with CryptOS as its PKI (see #113) before the Manager and Web are deployed, so cert-manager (see #110) issues their certificates. In that case they inherit CryptOS-backed PKI through the cluster instead of bootstrapping themselves.
Either way the result is a "yes, we use it too" setup where the management app runs on certificates CryptOS issued.
Not scheduled. The bootstrap and enrollment mechanism for the non-Kubernetes case, how it trusts the CA to begin with, renewal, and the exact interaction with the cluster PKI are still open.