CNFs Cert Manager

Overview

The Cloud-Native Network Functions (CNFs) Pods communicate over secure channels using the gRPC (remote procedure call) framework. To establish secure gRPC communication, SSL/TLS keys and certificates must be generated in the cluster. As an added layer of security, and to avoid service disruptions that may occur due to expired SSL/TLS certificates, a rotation schedule should be implemented, regenerating SSL/TLS certificates at specified intervals. The CNFs Certificate Manager integrates with a cluster Certificate Authority (CA), to provide the CNFs Pods with CA signed certificates at a regularly scheduled interval.

This document guides you through installing the CNFs Cert Manager, and generating the required SSL/TLS certificates and keys.

Note: The gRPC channel is established over TCP service port 8750.

CA signing certificate

To sign CNFs component certificates, a self-signed certificate authority (CA) can be generated when installing the CNFs Cert Manager. The CA signing keypair is installed in the f5-cert-manager installing namespace as a Secret, and will be referenced by a ClusterIssuer ClusterIssuer resource. You can also provide a custom CA and specify the secret name in values yaml file. When the Cert Manager generates certificate signing requests (CSRs) for the CNFs Pods, it will use this CA to sign and return new Pod Certificates across all cluster namespaces.

• The lifetime of the autogenerated CA certificate is 360 days. The user has to track the expiry of the CA certificate.
• When the f5-cert-manager is uninstalled, the leaf certificates and secrets will stay and will be valid till they get expire without renewal. Once f5-cert-manager is re-installed or upgraded in the same namespace, by default, it will pick up the old or existing autogenerated CA secret and continue using it for generating and renewing the certificates.

Limitations to update the CA Secret

To handle CA update during runtime, following are the known limitations to be considered:

• Automatic rotation for the CA certificate in the Secret configured is not available.
• CA issuers will issue leaf certificates which will not expire though CA secret certificate expires.
• Updating the secret used for the CA certificate will not trigger re-issuance of leaf certificates.
• CA issuers do not validate that the CA configured is a valid CA.

Pod certificates

All communication endpoints will generate Certificate Signing Request (CSR) and receive a Certificate object when the Pod is installed. The Cert Manager will rotate, or generate new CSRs, based on the duration parameter set in the Pod’s Certificate object. See Rotation schedules in the next section.

Rotation schedules

The Rotation schedule for all the CNFs Pod’s certificates is configured for one hour.

Cluster namespace

It is recommended to install Cert Manager in a dedecated namespace, but it can run in any namespace. In this document, Cert Manager will install to the cnf-cert-manager namespace. As mentioned earlier, Cert Manager uses the ClusterIssuer object to sign certificate requests across all cluster namespaces. Prior to installing the Cert Manager in a new namespace, refer to the Changing namespaces section of this document.

Requirements

Ensure you have:

• Installed the CNFs Software.
• A Linux based workstation with Helm installed.

Important: Cert Manager requires the CRDs prefixed with f5-certmgr-.

Procedures

Cert Manager

Use the following steps to install the CNFs Cert Manager Pods.

1. Change into the directory containing the latest CNFs Software, and obtain the f5-cert-manager Helm chart version:

   In this example, the CNF files are in the cnfinstall directory:

   cd cnfinstall
   

   ls -1 tar | grep f5-cert-manager
   

   The command output should appear similar to the following:

   f5-cert-manager-0.23.14-0.0.1.tgz
   

2. Create a Helm values file named cert-manager-values.yaml, and set the image.repository parameters. In the example below, Helm pulls the Cert Manager images from repo.f5.com/images.

   Important: Due to ID 1251997, the first four image.repository parameters must include the uploaded image name.

   image:
     repository: repo.f5.com/images/cert-manager-controller
   
   webhook:
     image:
       repository: repo.f5.com/images/cert-manager-webhook
   
   cainjector:
     image:
       repository: repo.f5.com/images/cert-manager-cainjector
   
   startupapicheck:
     image:
       repository: repo.f5.com/images/cert-manager-ctl
   
   init_container:
     image:
       repository: repo.f5.com/images
   

3. In cert-manager-values.yaml file set the serviceAccount.create parameter:

   Note: The serviceAccount will not be created by default.

   serviceAccount:
     create: false
     name: default
   

4. If you enabled the Fluentd Logging collector, set the following parameters:

   Note: Set the image.repository parameter to your local container registry.

   logging_sidecar:
     enabled: true
     image:
       repository: "repo.f5.com/images"
   
     fluentd:
       host: f5-toda-fluentd.cnf-gateway.svc.cluster.local.
   

5. Create a new namespace for the Cert Manager Pods using the following command syntax:

   Note: A new namespace is not required, and used only for easier Pod management.

   kubectl create ns <namespace>
   

   For example:

   kubectl create ns cnf-cert-manager
   

6. Install the Cert Manager Pods using the following command syntax:

   helm install <release> tar/<helm-chart>.tgz \
   -f <values>.yaml -n <namespace>
   

   For example:

   helm install f5-cert-manager tar/f5-cert-manager-0.23.14-0.0.1.tgz \
   -f cert-manager-values.yaml -n cnf-cert-manager
   

7. Verify the status of the Cert Manager Pods:

   kubectl get pods -n cnf-cert-manager
   

   In this example, the f5-cert-manager, f5-cert-manager-cainjector, and f5-cert-manager-webhook are Running.

   NAME                                          READY   STATUS    
   f5-cert-manager-cainjector-5cfbf4ff75-drmh7   1/1     Running   
   f5-cert-manager-cbfc74b4d-kskjx               1/1     Running   
   f5-cert-manager-webhook-58bf4b7b76-bcn4p      1/1     Running   
   

8. Verify the status of the ClusterIssuer:

   kubectl get clusterissuer -n cnf-cert-manager
   

   In this example, the ClusterIssuer is READY:

   NAME                  READY
   default-cert-issuer   True 
   

Open Source Cert Manager

Either F5s Cert Manager or Open Source Cert Manager can be used to obtain and manage the certificates. For more information on how to configure and use an open source cert manager, see Open Source Cert Manager guide.

OTEL Collectors

The OTEL Collectors receive data from the CNFs Pods and forward it to 3rd party visualization applications such as Prometheus. Cert Manager creates SSL/TLS certificates for the receiving side of the OTEL Collectors, but not for the sending side.

F5s Cert Manager or OSS cert manager can be used to create required certificates for OTEL to communicate with third party applications such as Prometheus. You can also use the steps below to manually create Kubernetes Secrets instead of using Cert Manager.

1. Copy the OTEL Certificate objects into a YAML file:

   • Copy the following certificate objects while Open source cert manager is not used.

     apiVersion: cm.f5co.k8s.f5net.com/v1
     kind: Certificate
     metadata:
       name: external-otelsvr
     spec:
       subject:
         countries:
           - US
         provinces:
           - Washington
         localities:
           - Seattle
         organizations:
           - F5 Networks
         organizationalUnits:
           - PD
       emailAddresses:
         - clientcert@f5net.com
       commonName: f5net.com
       # SecretName is the name of the secret resource that will be automatically created and managed by this Certificate resource.
       # It will be populated with a private key and certificate, signed by the denoted issuer.
       secretName: external-otelsvr-secret
       # IssuerRef is a reference to the issuer for this certificate.
       issuerRef:
         name: default-cert-issuer
         kind: ClusterIssuer
       duration: 8640h
       privateKey:
         rotationPolicy: Always
         encoding: PKCS1
         algorithm: RSA
         size: 4096
       revisionHistoryLimit: 10
     ---
     apiVersion: cm.f5co.k8s.f5net.com/v1
     kind: Certificate
     metadata:
       name: external-f5ingotelsvr
     spec:
       subject:
         countries:
           - US
         provinces:
           - Washington
         localities:
           - Seattle
         organizations:
           - F5 Networks
         organizationalUnits:
           - PD
       emailAddresses:
         - clientcert@f5net.com
       commonName: f5net.com
       # SecretName is the name of the secret resource that will be automatically created and managed by this Certificate resource.
       # It will be populated with a private key and certificate, signed by the denoted issuer.
       secretName: external-f5ingotelsvr-secret
       # IssuerRef is a reference to the issuer for this certificate.
       issuerRef:
         name: default-cert-issuer
         kind: ClusterIssuer
       duration: 8640h
       privateKey:
         rotationPolicy: Always
         encoding: PKCS1
         algorithm: RSA
         size: 4096
       revisionHistoryLimit: 10
     

   • While an open source cert manager is used, copy the following certificate objects into a YAML file.

     Note: Ensure the apiVersion matches with the oss cert-manager and the issuer or clusterissuer matches with the one created for oss cert-manager. Please replace the values with your actual configurations.

     apiVersion: cert-manager.io/v1           
     kind: Certificate
     metadata:
       name: external-otelsvr
     spec:
       subject:
         countries:
           - US
         provinces:
           - Washington
         localities:
           - Seattle
         organizations:
           - F5 Networks
         organizationalUnits:
           - PD
       emailAddresses:
         - clientcert@f5net.com
       commonName: f5net.com
       # SecretName is the name of the secret resource that will be automatically created and managed by this Certificate resource.
       # It will be populated with a private key and certificate, signed by the denoted issuer.
       secretName: external-otelsvr-secret
       # IssuerRef is a reference to the issuer for this certificate.
       issuerRef:                            
         name: default-cert-issuer
         kind: ClusterIssuer
       # Lifetime of the Certificate is 360 days.
       duration: 8640h
       privateKey:
         rotationPolicy: Always
         encoding: PKCS1
         algorithm: RSA
         size: 4096
       revisionHistoryLimit: 10
     ---
     apiVersion: cert-manager.io/v1
     kind: Certificate
     metadata:
       name: external-f5ingotelsvr
     spec:
       subject:
         countries:
           - US
         provinces:
           - Washington
         localities:
           - Seattle
         organizations:
           - F5 Networks
         organizationalUnits:
           - PD
       emailAddresses:
         - clientcert@f5net.com
       commonName: f5net.com
       # SecretName is the name of the secret resource that will be automatically created and managed by this Certificate resource.
       # It will be populated with a private key and certificate, signed by the denoted issuer.
       secretName: external-f5ingotelsvr-secret
       # IssuerRef is a reference to the issuer for this certificate.
       issuerRef:
         name: default-cert-issuer
         kind: ClusterIssuer
       # Lifetime of the Certificate is 360 days.
       duration: 8640h
       privateKey:
         rotationPolicy: Always
         encoding: PKCS1
         algorithm: RSA
         size: 4096
       revisionHistoryLimit: 10
     

2. Install the Certificate objects to the OTEL Collector namespace:

   In this example, the Certificates install to the cnf-gateway namespace:

   kubectl apply -f otel-certificates.yaml -n cnf-gateway
   

3. The output should indicate the Certificates are created:

   certificate.cm.f5co.k8s.f5net.com/external-otelsvr created
   certificate.cm.f5co.k8s.f5net.com/external-f5ingotelsvr created
   

4. If the Prometheus scheme parameter is set to https (the default is http), you must also set the insecure_skip_verify parameter set to true. View the example ConfigMap template here.

5. Continue to the Next steps section.

Next steps

Continue with the next step of the installation process described in the Getting Started guide:

1. Fluentd Logging - Required: Centralize logging data sent from each of the CNF Pods.
2. OTEL Collectors - Optional: Collect and view statistics from the CNFs Pods.
3. dSSM Database - Optional: Store session-state data for the AFM and TMM Pods.
4. CNFs CWC - Required: Install the Cluster Wide Controller to enable gathering CNFs software telemetry.

Changing Namespaces

Prior to reinstalling the CNFs Cert Manager to a different namespace, ensure you delete the currently installed Secrets.

1. Uninstall the Cert Manager:

   helm uninstall <release> -n <namespace>
   

   In this example, the Cert Manager release named f5-certificate-manager is in the cnf-cert-manager namespace.

   helm uninstall f5-cert-manager -n cnf-cert-manager 
   

2. List the Cert Manager Secrets:

   kubectl get secrets -n cnf-cert-manager
   

   NAME                         TYPE                DATA
   ca-key-pair                  kubernetes.io/tls   2 
   f5-cert-manager-webhook-ca   Opaque              3
   

3. Delete the Secrets:

   kubectl delete secret ca-key-pair -n cnf-cert-manager
   

   kubectl delete secret f5-cert-manager-webhook-ca -n cnf-cert-manager
   

   The command output should indicate the Secret is deleted.

   secret "ca-key-pair" deleted
   

   secret "f5-cert-manager-webhook-ca" deleted
   

Feedback

Provide feedback to improve this document by emailing cnfdocs@f5.com.

Supplemental Information

• The list of commands used to create the Secrets.
• Introduction to gRPC
• Kubernetes Secrets