CNFs Cert Manager¶
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 Pod certificates, a self-signed certificate authority (CA) signing certificate and key (keypair) can be generated when installing the CNFs Cert Manager. The CA signing keypair is installed in the cluster as a Secret, and will be referenced by a Kubernetes
ClusterIssuer object. 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.
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.
The table below lists the rotation schedule for each of the CNFs Pods.
*Cert rotation not supported.
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.
Ensure you have:
- Installed the CNFs Software.
- A Linux based workstation with Helm installed.
Important: Cert Manager requires the CRDs prefixed with f5-certmgr- provided in the f5-cnf-crds-n6lan tarball.
Use the following steps to install the CNFs Cert Manager Pods.
Change into the directory containing the latest CNFs Software, and list the f5-cert-manager Helm chart:
cd cnfinstall; ls -1 tar | grep cert-manager
Create a Helm values file named cert-manager-values.yaml, and set the
image.repositoryparameters. In the example below, Helm pulls the Cert Manager images from registry.com.
Important: Due to ID 1251997, the first four
image.repositoryparameters must include the uploaded image name.
image: repository: registry.com/cert-manager-controller webhook: image: repository: registry.com/cert-manager-webhook cainjector: image: repository: registry.com/cert-manager-cainjector startupapicheck: image: repository: registry.com/cert-manager-ctl init_container: image: repository: registry.com
If you enabled the Fluentd Logging collector, set the following parameters:
Note: Set the
image.repositoryparameter to your local container registry.
logging_sidecar: enabled: true image: repository: "registry.com" name: f5-fluentbit tag: v0.4.1 fluentd: host: f5-toda-fluentd.cnf-gateway.svc.cluster.local.
Create a new namespace for the Cert Manager Pods:
Note: A new namespace is not required, and used only for easier Pod management.
kubectl create ns cnf-cert-manager
Install the Cert Manager Pods:
helm install <release> tar/<helm-chart>.tgz -f <values>.yaml -n <namespace>
helm install f5-cert-manager tar/f5-cert-manager-0.5.10.tgz \ -f cert-manager-values.yaml -n cnf-cert-manager
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
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
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. You can utilize Cert Manager to create required certificates for OTEL to communicate with third party applications such as Prometheus. You can also manually create Kubernetes Secrets instead of using Cert Manager.
Copy the OTEL Certificate objects into a YAML file:
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: - email@example.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 1 hour, not configurable 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: - firstname.lastname@example.org 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 1 hour, not configurable duration: 8640h privateKey: rotationPolicy: Always encoding: PKCS1 algorithm: RSA size: 4096 revisionHistoryLimit: 10
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
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
If the Prometheus
schemeparameter is set to https (the default is http), you must also set the
insecure_skip_verifyparameter set to true. View the example ConfigMap template here.
Continue to the Next steps section.
Continue with the next step of the installation process described in the Getting Started guide:
- Fluentd Logging - Optional: Centralize logging data sent from each of the CNF Pods.
- OTEL Collectors - Optional: Collect and view statistics from the CNFs Pods.
- dSSM Database - Optional: Store session-state data for the AFM and TMM Pods.
- CNFs CWC - Required: Install the Cluster Wide Controller to enable gathering CNFs software telemetry.
Prior to reinstalling the CNFs Cert Manager to a different namespace, ensure you delete the currently installed Secrets.
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
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
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
Provide feedback to improve this document by emailing email@example.com.
- The list of commands used to create the Secrets.
- Introduction to gRPC
- Kubernetes Secrets