CNFs Secrets

Overview

The Cloud-Native Network Functions (CNFs) BIG-IP Controller, Edge Firewall, and Traffic Management Microkernel (TMM) Proxy Pods communicate over a secure channel using the gRPC (remote procedure call) framework. The BIG-IP Controller’s HTTPs based validation service also requires SSL/TLS keys and certificates to secure validation requests. To secure the gRPC channel, and validation service requests, SSL/TLS keys and certificates must be generated and stored as Secrets in the cluster.

_images/spk_info.png Note: The gRPC channel is established over TCP service port 8750.

This document guides you through understanding, generating and installing Secrets for the gRPC channels and the validation service.

Validity period

SSL/TLS certificates are valid for a specific period of time, and once they expire, secure connections fail when attempting to validate the certificate. When creating new SSL/TLS certificates for the gRPC channel, it is recommended that you choose a period of one year, or two years to avoid connection failures.

Example SSL Certificate validity period:

Validity
    Not Before: Jan 1  10:30:00 2021 GMT
    Not After : Jan 1  10:30:00 2022 GMT

Updating Secrets

When planning to replace previously installed Secrets, you must restart the BIG-IP Controller and TMM Proxy Pods to begin using the new Secrets. To replace existing Secrets, refer to the Restarting section of this guide.

_images/spk_warn.png Important: Restarting the Service Proxy TMM Proxy Pods impacts traffic processing.

Validation service

The CNFs validation service ensures that CNFs CRs such as the F5BigTcpSetting, F5BigUdpSetting, and F5BigFastl4Setting profiles are not eligible for deletion when referenced by traffic management CRs such as the F5BigContextSecure. When attempting to delete a referenced CR, the BIG-IP Controller blocks the deletion and sends an error message similar to the following:

Error from server: error when deleting "tcp.yaml": admission webhook "f5validate.f5net.com" denied the request: 
TCP CR: tcp-client-side cannot be deleted as it is referenced in Secure Context CR: cnf-context-secure

Requirements

Ensure you have:

  • A Robin cluster.
  • A Linux workstation with OpenSSL installed.

Procedures

Select one of the procedures below to generate the SSL/TLS keys and certificates that will be stored in the cluster as Secrets.

_images/spk_info.png Note: F5 recommends obtaining certificate authority (CA) signed certificates for production environments. The required Subject Alternative Names (SANs) can be found in step 4 of the Using OpenSSL procedure.

Using cert-gen

Use the cert-gen utility to automatically generate the CNFs Secrets.

_images/spk_warn.png Important: The cert-gen utility requires the make command to generate the secrets.

  1. Change into the directory with the CNF files:

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

    cd cnfinstall

  2. Extract the cert-gen utility:

    tar xvf f5-cert-gen-0.3.0.tgz

  3. Generate the Secrets:

    _images/spk_warn.png Important: The syntax for the f5-validation-svc SAN requires appending the namespace of the BIG-IP controller. In this example, the syntax includes the cnf-gateway namespace.

    sh cert-gen/gen_cert.sh -s=cnf -a=f5-validation-svc.cnf-gateway.svc

  4. Create a new namespace for the CNF Pods:

    robin namespace add cnf-gateway

  5. Install the Secret key and certificate objects:

    kubectl apply -f keys-secret.yaml -n cnf-gateway
kubectl apply -f certs-secret.yaml -n cnf-gateway

    The command responses should state the Secrets have been created:

    secret/keys-secret created
secret/certs-secret created

  6. The new Secrets will now be used to secure CNFs Pod communications.

Using OpenSSL

Use the openssl utility to manually generate the CNFs Secrets.

_images/spk_info.png Note: Download the list of commands used to generate the Secrets here. Review step 4 below before running these commands.

  1. Change into the directory with the CNF files:

    cd <directory>

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

    cd cnfinstall

  2. Create a new directory for the gRPC Secret keys and certificates, and change into the directory:

    mkdir <directory>

    cd <directory>

    In this example, a new directory named grpc_secrets is created and changed into:

    mkdir grpc_secrets

    cd grpc_secrets

  3. Create the gRPC Certificate Authority (CA) signing key and certificate:

    _images/spk_info.png Note: Adapt the number of -days the certificate will be valid, and the -subj information for your environment.

    openssl genrsa -out grpc-ca.key 4096

    openssl req -x509 -new -nodes -key grpc-ca.key -sha256 -days 365 -out grpc-ca.crt \
-subj "/C=US/ST=WA/L=Seattle/O=F5/OU=Dev/CN=ca"

  4. The following code creates a new file named server.ext with the required SSL/TLS attributes:

    _images/spk_warn.png Important: The syntax for the f5-validation-svc SAN requires appending the namespace of the BIG-IP controller. In this example, the syntax includes the cnf-gateway namespace.

    echo "[req_ext]" > server.ext
echo " " >> server.ext
echo "subjectAltName = @alt_names" >> server.ext
echo " " >> server.ext
echo "[alt_names]" >> server.ext
echo " " >> server.ext
echo "DNS.1 = grpc-svc" >> server.ext
echo "DNS.2 = grpc-pccd-svc" >> server.ext
echo "DNS.3 = grpc-ipsd-svc" >> server.ext
echo "DNS.4 = otel-collector" >> server.ext
echo "DNS.5 = f5-validation-svc.cnf-gateway.svc" >> server.ext

    The server.ext file should contain the following SSL/TLS attributes:

    [req_ext]

subjectAltName = @alt_names

[alt_names]

DNS.1 = grpc-svc
DNS.2 = grpc-pccd-svc
DNS.3 = grpc-ipsd-svc
DNS.4 = otel-collector
DNS.5 = f5-validation-svc.cnf-gateway.svc

  5. Create the gRPC server SSL/TLS key, certificate signing request (CSR), and signed certificate for the Controller and TMM channel:

    _images/spk_info.png Note: Adapt the number of -days the certificate will be valid, and the -subj information for your environment.

    openssl genrsa -out grpc-server.key 4096

    openssl req -new -key grpc-server.key -out grpc-server.csr \
-subj "/C=US/ST=WA/L=Seattle/O=F5/OU=PD/CN=f5net.com"

    openssl x509 -req -in grpc-server.csr -CA grpc-ca.crt -CAkey grpc-ca.key \
-CAcreateserial -out grpc-server.crt -extensions req_ext -days 365 -sha256 \
-extfile server.ext

  6. Create the gRPC server SSL/TLS key, certificate signing request (CSR), and signed certificate for the Controller, TMM and OTEL channel:

    _images/spk_info.png Note: Adapt the number of -days the certificate will be valid, and the -subj information for your environment.

    openssl genrsa -out grpc-otel-server.key 4096

    openssl req -new -key grpc-otel-server.key -out grpc-otel-server.csr \
-subj "/C=US/ST=WA/L=Seattle/O=F5/OU=PD/CN=f5net.com"

    openssl x509 -req -in grpc-otel-server.csr -CA grpc-ca.crt -CAkey grpc-ca.key \
-set_serial 101 -outform PEM -out grpc-otel-server.crt -extensions req_ext -days 365 \
-sha256 -extfile server.ext

  7. The following code creates a new file named client.ext with the required SSL/TLS attributes:

    echo "[req_ext]" > client.ext
echo " " >> client.ext
echo "subjectAltName = @alt_names" >> client.ext
echo " " >> client.ext
echo "[alt_names]" >> client.ext
echo " " >> client.ext
echo "email.1 = clientcert@f5net.com" >> client.ext

    The client.ext file should contain the following SSL/TLS attributes:

    [req_ext]

subjectAltName = @alt_names

[alt_names]

email.1 = clientcert@f5net.com

  8. Create the gRPC client key, CSR and signed certificate for the Controller and TMM channel:

    _images/spk_info.png Note: Adapt the number of -days the certificate will be valid, and the -subj information for your environment.

    openssl genrsa -out grpc-client.key 4096

    openssl req -new -key grpc-client.key -out grpc-client.csr \
-subj "/C=US/ST=WA/L=Seattle/O=F5/OU=PD/CN=f5net.com"

    openssl x509 -req -in grpc-client.csr -CA grpc-ca.crt -CAkey grpc-ca.key \
-set_serial 101 -outform PEM -out grpc-client.crt -extensions req_ext -days 365 \
-sha256 -extfile client.ext

  9. Create the Edge Firewall (pccd) gRPC client key, CSR and signed certificate:

    _images/spk_info.png Note: Adapt the number of -days the certificate will be valid, and the -subj information for your environment.

    openssl genrsa -out grpc-pccd-client.key 4096

    openssl req -new -key grpc-pccd-client.key -out grpc-pccd-client.csr \
-subj "/C=US/ST=WA/L=Seattle/O=F5/OU=PD/CN=f5net.com"

    openssl x509 -req -in grpc-pccd-client.csr -CA grpc-ca.crt -CAkey grpc-ca.key \
-set_serial 101 -outform PEM -out grpc-pccd-client.crt -extensions req_ext -days 365 \
-sha256 -extfile client.ext

  10. Create the Intrusion Prevention (ipsd) gRPC client key, CSR and signed certificate:

    _images/spk_info.png Note: Adapt the number of -days the certificate will be valid, and the -subj information for your environment.

    openssl genrsa -out grpc-ipsd-client.key 4096

    openssl req -new -key grpc-ipsd-client.key -out grpc-ipsd-client.csr \
-subj "/C=US/ST=WA/L=Seattle/O=F5/OU=PD/CN=f5net.com"

    openssl x509 -req -in grpc-ipsd-client.csr -CA grpc-ca.crt -CAkey grpc-ca.key \
-set_serial 101 -outform PEM -out grpc-ipsd-client.crt -extensions req_ext -days 365 \
-sha256 -extfile client.ext

  11. Create the gRPC client key, CSR and signed certificate for the Controller, TMM and OTEL channel:

    _images/spk_info.png Note: Adapt the number of -days the certificate will be valid, and the -subj information for your environment.

    openssl genrsa -out grpc-otel-client.key 4096

    openssl req -new -key grpc-otel-client.key -out grpc-otel-client.csr \
-subj "/C=US/ST=WA/L=Seattle/O=F5/OU=PD/CN=f5net.com"

    openssl x509 -req -in grpc-otel-client.csr -CA grpc-ca.crt -CAkey grpc-ca.key \
-set_serial 101 -outform PEM -out grpc-otel-client.crt -extensions req_ext -days 365 \
-sha256 -extfile client.ext

  12. Create the custom resource (CR) validation server key, CSR and signed certificate:

    _images/spk_info.png Note: Adapt the number of -days the certificate will be valid, and the -subj information for your environment.

    openssl genrsa -out validation-server.key 4096

    openssl req -new -key validation-server.key -out validation-server.csr \
-subj "/C=US/ST=WA/L=Seattle/O=F5/OU=PD/CN=f5net.com"

    openssl x509 -req -in validation-server.csr -CA grpc-ca.crt -CAkey grpc-ca.key \
-set_serial 101 -outform PEM -out validation-server.crt -extensions req_ext -days 365 \
-sha256 -extfile server.ext

  13. The following code performs a Base64 encoding of the keys and certificates:

    openssl base64 -A -in grpc-ca.crt -out grpc-ca-encode.crt
openssl base64 -A -in grpc-server.crt -out grpc-server-encode.crt
openssl base64 -A -in grpc-client.crt -out grpc-client-encode.crt
openssl base64 -A -in grpc-pccd-client.crt -out grpc-pccd-client-encode.crt
openssl base64 -A -in grpc-ipsd-client.crt -out grpc-ipsd-client-encode.crt
openssl base64 -A -in grpc-otel-client.crt -out grpc-otel-client-encode.crt
openssl base64 -A -in grpc-otel-server.crt -out grpc-otel-server-encode.crt
openssl base64 -A -in validation-server.crt -out validation-server-encode.crt
openssl base64 -A -in grpc-server.key -out grpc-server-encode.key
openssl base64 -A -in grpc-ca.key -out grpc-ca-encode.key
openssl base64 -A -in grpc-client.key -out grpc-client-encode.key
openssl base64 -A -in grpc-pccd-client.key -out grpc-pccd-client-encode.key
openssl base64 -A -in grpc-ipsd-client.key -out grpc-ipsd-client-encode.key
openssl base64 -A -in grpc-otel-client.key -out grpc-otel-client-encode.key
openssl base64 -A -in grpc-otel-server.key -out grpc-otel-server-encode.key
openssl base64 -A -in validation-server.key -out validation-server-encode.key

  14. The following code creates the K8S Secret object used to store SSL/TLS keys:

    _images/spk_warn.png Important: The syntax in the bottom three lines; grpc-svc.key, priv.key, and f5-ing-demo-f5ingress.key, must be set as in the example.

    echo "apiVersion: v1" > keys-secret.yaml
echo "kind: Secret" >> keys-secret.yaml
echo "metadata:" >> keys-secret.yaml
echo " name: keys-secret" >> keys-secret.yaml
echo "data:" >> keys-secret.yaml
echo " grpc-svc.key: `cat grpc-server-encode.key`" >> keys-secret.yaml
echo " priv.key: `cat grpc-ca-encode.key`" >> keys-secret.yaml
echo " f5-ing-demo-f5ingress.key: `cat grpc-client-encode.key`" >> keys-secret.yaml
echo " grpc-pccd-client.key: `cat grpc-pccd-client-encode.key`" >> keys-secret.yaml
echo " grpc-ipsd-client.key: `cat grpc-ipsd-client-encode.key`" >> keys-secret.yaml
echo " grpc-otel-client.key: `cat grpc-otel-client-encode.key`" >> keys-secret.yaml
echo " grpc-otel-server.key: `cat grpc-otel-server-encode.key`" >> keys-secret.yaml
echo " validation-svc.key: `cat validation-server-encode.key`" >> keys-secret.yaml

  15. The following code creates the K8S Secret object used to store the SSL/TLS certificates:

    _images/spk_warn.png Important: The syntax in the bottom three lines; grpc-svc.crt, ca_root.crt, and f5-ing-demo-f5ingress.crt, must be set as in the example.

    echo "apiVersion: v1" > certs-secret.yaml
echo "kind: Secret" >> certs-secret.yaml
echo "metadata:" >> certs-secret.yaml
echo " name: certs-secret" >> certs-secret.yaml
echo "data:" >> certs-secret.yaml
echo " grpc-svc.crt: `cat grpc-server-encode.crt`" >> certs-secret.yaml
echo " ca_root.crt: `cat grpc-ca-encode.crt`" >> certs-secret.yaml
echo " f5-ing-demo-f5ingress.crt: `cat grpc-client-encode.crt`" >> certs-secret.yaml
echo " grpc-pccd-client.crt: `cat grpc-pccd-client-encode.crt`" >> certs-secret.yaml
echo " grpc-ipsd-client.crt: `cat grpc-ipsd-client-encode.crt`" >> certs-secret.yaml
echo " grpc-otel-client.crt: `cat grpc-otel-client-encode.crt`" >> certs-secret.yaml
echo " grpc-otel-server.crt: `cat grpc-otel-server-encode.crt`" >> certs-secret.yaml
echo " validation-svc.crt: `cat validation-server-encode.crt`" >> certs-secret.yaml

  16. Create a new namespace for the CNF Pods:

    robin namespace add cnf-gateway

  17. Install the Secret key and certificate objects:

    kubectl apply -f keys-secret.yaml -n cnf-gateway
kubectl apply -f certs-secret.yaml -n cnf-gateway

    The command responses should state the Secrets have been created:

    secret/keys-secret created
secret/certs-secret created

  18. The new Secrets will now be used to secure CNFs Pod communication.

Next step

Continue to one of the following guides listed by installation precedence:

  • Optional: Install the Fluentd Logging collector to centralize CNF container logging.
  • Optional: Install the dSSM Database to store session-state information.
  • Required: Install the BIG-IP Controller, Edge Firewall and TMM Pods.

Restarting

This procedure assumes that you have deployed the Controller, Edge Firewall and TMM Pods, and have created a new set of Secrets to replace the existing Secrets. New Secrets will not be used until the Controller and TMM Pods have been restarted.

_images/spk_warn.png Important: Restarting the TMM Pod impacts traffic processing.

  1. Obtain the name and number of Controller and TMM Pods:

    kubectl get deploy -n cnf-gateway

    In this example, there is 1 Controller and 3 TMM Pods:

    NAME                  READY   AVAILABLE
f5ingress-f5ingress   1/1     1
f5-tmm                3/3     3

  2. Scale the number of TMM Pods to 0:

    kubectl scale deploy f5-tmm --replicas=0 -n cnf-gateway

  3. Ensure 0 (none) of the f5-tmm Pods are AVAILABLE:

    NAME                  READY   AVAILABLE 
f5ingress-f5ingress   1/1     1
f5-tmm                0/0     0

  4. Scale the TMM Pods back to the previous number:

    kubectl scale deploy f5-tmm --replicas=<number> -n <namespace>

    In this example the TMM Pods are scaled back to 3:

    kubectl scale deployment f5-tmm --replicas=3  -n cnf-gateway

  5. Ensure 3 (all) of the f5-tmm Pods are AVAILABLE:

    NAME                  READY   AVAILABLE 
f5ingress-f5ingress   1/1     1
f5-tmm                3/3     3

  6. Scale the Controller to 0:

    kubectl scale deployment <name> --replicas=0 -n <namespace>

    For example:

    kubectl scale deploy f5ingress-f5ingress --replicas=0 -n cnf-gateway

  7. Ensure 0 (none) of the Controller Pods are AVAILABLE:

    NAME                  READY   AVAILABLE 
f5ingress-f5ingress   0/0     0
f5-tmm                3/3     3

  8. Scale the Controller back to the previous number:

    kubectl scale deployment <name> --replicas=1  -n <namespace>

    In this example the Controller is scaled back to 1:

    kubectl scale deployment f5ingress-f5ingress --replicas=1 -n cnf-gateway

  9. Ensure the Controller Pod is AVAILABLE:

    NAME                  READY   AVAILABLE 
f5ingress-f5ingress   1/1     1
f5-tmm                3/3     3

  10. The new Secrets should now be used to secure CNFs Pod communication.

Feedback

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

Supplemental Information