Problem statement

ONAP has a lot of components which enroll certificates:

• Legacy AAF CertMan which uses SCEP protocol or own internal Certificate Authority - mostly used by AT&T and integrated with several ONAP components
• New CertService which uses CMPv2 to enroll certificates - integrated with ONAP bordering components to protect external traffic
• K8s Cert-Manager which is OOM way forward to enroll certificates for ONAP components

It is time to unify them and use forward just one of them.

K8s Cert-Manager Introduction

K8s Cert-Manager is an industry standard to issue X.509 certificates to K8s workloads. It provides simple, reliable, elastic and efficient way to issue certificates within K8s environment. Simple cause it relies on K8s custom resource definition (CRD) mechanism, reliable cause without secret created by Cert-Manager K8s workload won't start, elastic cause it can provide certificates from many sources, including external providers and efficient - cause it may deliver hundreds of certificates per day.

...

As previously mentioned, Cert-Manager consumes K8s workload's 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 very rich functionality to configure issued certificate and use various types of issuers.

...

ONAP has a lot of components which enrolls certificates:

• Legacy AAF CertMan which uses SCEP protocol or own internal Certificate Authority
• New CertService which uses CMPv2 to enroll certificates
• K8s Cert-Manager which is OOM way forward to enroll certificates for ONAP components

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 also by Certificate CRD. Following diagram presents new setup.

...