Introducing OCCM in an Existing NF Deployment

4 Introducing OCCM in an Existing NF Deployment

This section describes the procedure to introduce OCCM in an existing NF deployment where certificates are managed manually. OCCM helps in automating certificate management.

You can move from manual management to automated manages in one of 2 ways:

Using existing key and certificate
Using a new key and certificate

Moving NFs from Manual Certificate Management to Automated Certificate Management with Existing Key and Certificate

Configure a key and certificate on OCCM. You must reuse the same Kubernetes secret and the content as used by NF with manually generated key and certificate. The NF configuration must not be updated.
OCCM monitors the existing key and certificate in the configured Kubernetes secret and renews it. The metrics attached to the key and certificate are generated.

Note:

The existing key and certificate are not validated against the configuration. However, the renewed certificate will be aligned with the configuration.

Moving NFs from Manual Certificate Management to Automated Certificate Management With new Key and Certificate

Configure a key and certificate on OCCM making sure to reuse the same Kubernetes secret as used by NF with manually generated key and certificate. Reusing the Kubernetes secret make sure that the NF configuration is not updated.
OCCM creates a new key and certificate in the configured Kubernetes secret and deletes the old key and certificate. The old key and certificate is deleted to generate OCCM metrics attached to the certificate creation.

Procedure

The operator can select the following values for the LCM Type field:

Manual (With existing key and certificate)
Automatic (With new key and certificate)

Manual

In Manual mode, existing certificates are configured at OCCM so that OCCM can manage the lifecycle of certificates. For example, the certificates that are already being used by NFs can be monitored by OCCM and further renewed by OCCM. In this case, the same Kubernetes secret and the content as used by NF with manually generated key and Certificate is reused by OCCM.

Note:

The existing Key and Cert are not validated against the configuration. Renewed certificate will be aligned with the configuration though.

Automatic

In Automatic mode, OCCM can create fresh certificates or override the existing certificate with a new one. For example, if NFs want to create a new key and certificate to override old one through OCCM, and monitor them, then a key and certificate can be created on OCCM using the same Kubernetes secret as used by NF with manually generated key and certificate
OCCM creates a new key and certificate in the configured Kubernetes secret and deletes the old key and certificate

Note:

While reusing the Kubernetes secret and content. you must ensure that the NF configuration is not updated.

Table 4-1 Dependency of LCM type on Kubernetes Secret

LCM Type	Description
Manual	Operator doesn't need to create a new secret. OCCM uses the existing Kubernetes secret.
Automatic	Operator can either create a new secret or use the existing Kubernetes secret with the Override Secret flag

Table 4-2 Behaviour of different LCM Types

LCM Type	Preexisting Kubernetes Secret	Override Secret Flag	Behaviour
Automatic	No	No Impact	Certificate is created irrespective of the override flag
Automatic	Yes	True or False	True: The Kubernetes secret is overridden False: An error is thrown because you must either use a new secret or set the override flag to true. This error is thrown upfront on the user interface or in the response if APIs are used.
Manual	No	NA	An error is thrown because OCCM expects a preconfigured Kubernetes secret. This error is thrown upfront on the user interface or in the response if APIs are used.
Manual	Yes	NA	Certificate configuration is created at OCCM for further certificate renewal and monitoring.

Moving Back to Manual Certificate Management

If the operator wants to move back to manual certificate monitoring, then they can delete the entry from the OCCM configuration. OCCM doesn't delete the secret when the entry is deleted and the certificate can be monitored manually (if operator used same secret location).
If user creates a separate secret during certificate management from OCCM and operator doesn't want to use the secret further, then operator can delete the entry from OCCM and must also delete the Kubernetes secret.