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

To move 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

To move 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 Creation Mode field:

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

Manual

In Manual mode, OCCM is configured to manage the lifecycle of existing the 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 certificate 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 overwrite the existing certificate with a new one. For example, if NFs want to create a new key and certificate to overwrite 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

Table 4-1 Dependency of Creation Mode on Kubernetes Secret

Creation Mode Description

Manual

Creation Mode	Description
Manual	Manual mode must be selected to continue using the existing key and certificate which are used by NF in the manual management. Operator needs to configure the same Kubernetes secret as used by the NF configuration.
Automatic	Automatic mode must be selected to generate a new key and certificate. OCCM generates a fresh key pair and certificate and creates a new Kubernetes secret. You must configure the Kubernetes secret details. Operator can also choose to overwrite an existing secret with the generated key pair and certificate by setting the `Overwrite Secret` flag to true and configuring the existing secret details.

Manual mode must be selected to continue using the existing key and certificate which are used by NF in the manual management.

Operator needs to configure the same Kubernetes secret as used by the NF configuration.

Automatic

Automatic mode must be selected to generate a new key and certificate. OCCM generates a fresh key pair and certificate and creates a new Kubernetes secret. You must configure the Kubernetes secret details.

Operator can also choose to overwrite an existing secret with the generated key pair and certificate by setting the Overwrite Secret flag to true and configuring the existing secret details.

Table 4-2 Behaviour of different Creation Modes

Creation Mode	Preexisting Kubernetes Secret	overwrite Secret Flag	Behaviour
Automatic	No	No Impact	Certificate is created irrespective of the overwrite 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 overwrite 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 the operator doesn't want to use the secret further, then operator can delete the entry from OCCM and must also delete the Kubernetes secret.