...
As previously mentioned, Cert-Manager consumes Certificate CRD to issue certificates. But before first certificate is issued, Issuer or ClusterIssuer CRD has to be configured first. For basic use cases that's all. One can use veryrich functionality to configure issued certificate and use various types of issuers.
Underneath, out of Certificate CRD, Cert-Manager creates CertificateRequest CRD which is more suitable for M2M processing as it contains Certificate Singing Request (CSR). CertificateRequest CRD is further on consumed by Issuer which processes CSR stored there and in return puts signed certificate and trusted certs in CertificateRequest's status and marks CertificateReqeust as Ready. Cert-Manager notices such state change and from CertificateRequest marked as Ready creates K8s secret originally requested in Certificate CRD. Such K8s secret is ready to be mounted to K8s workload as any other secret.
Way forward
CertService was implemented some time back. It provides basic certificate enrollment functionality using CMPv2 over HTTP. Cause in ONAP we have a lot of components which issue certificates, it is wise to harmonize them and use forward just one of them. As a way forward, CertService should be a backend proxy service for K8s Cert-Manager. The same functionality which is currently implemented in CertService client should be implemented in Cert-Manager's external provider, except parts which are already implemented in Cert-Manager and are generic for all providers (e.g. input parameters validation, conversion to different format, etc). If possible the same input parameters which nowadays are used by CertService client should also be used by Certificate CRD. Following diagram presents new setup.
...