BIG-IP Next Edge Firewall CNF for Edge workloads

Introduction 

The CNF architecture aligns with cloud-native principles by enabling horizontal scaling, ensuring that applications can expand seamlessly without compromising performance. It preserves the deterministic reliability essential for telecom environments, balancing scalability with the stringent demands of real-time processing. More background information about what value CNF brings to the environment, https://community.f5.com/kb/technicalarticles/from-virtual-to-cloud-native-infrastructure-evolution/342364

Telecom service providers make use of CNFs for performance optimization, 

• Enable efficient and secure processing of N6-LAN traffic at the edge to meet the stringent requirements of 5G networks.
• Optimize AI-RAN deployments with dynamic scaling and enhanced security, ensuring that AI workloads are processed efficiently and securely at the edge, improving overall network performance.
• Deploy advanced AI applications at the edge with the confidence of carrier-grade security and traffic management, ensuring real-time processing and analytics for a variety of edge use cases.

CNF Firewall Implementation Overview

Let’s start with understanding how different CRs are enabled within a CNF implementation this allows CNF to achieve more optimized performance, Capex and Opex.

The traditional way of inserting services to the Kubernetes is as below,

Moving to a consolidated Dataplane approach saved 60% of the Kubernetes environment’s performance

The F5BigFwPolicy Custom Resource (CR) applies industry-standard firewall rules to the Traffic Management Microkernel (TMM), ensuring that only connections initiated by trusted clients will be accepted. When a new F5BigFwPolicy CR configuration is applied, the firewall rules are first sent to the Application Firewall Management (AFM) Pod, where they are compiled into Binary Large Objects (BLOBs) to enhance processing performance.

Once the firewall BLOB is compiled, it is sent to the TMM Proxy Pod, which begins inspecting and filtering network packets based on the defined rules.

Enabling AFM within BIG-IP Controller

Let’s explore how we can enable and configure CNF Firewall. Below is an overview of the steps needed to set up the environment up until the CNF CRs installations

• [Enabling the AFM] Enabling AFM CR within BIG-IP Controller definition 

global:
   afm:
     enabled: true
     pccd:
       enabled: true 

f5-afm:
   enabled: true
   cert-orchestrator:
     enabled: true
   afm:
     pccd:  
       enabled: true
       image:
        repository: "local.registry.com"

• [Configuration] Example for Firewall policy settings 

apiVersion: "k8s.f5net.com/v1"
kind: F5BigFwPolicy
metadata:
  name: "cnf-fw-policy"
  namespace: "cnf-gateway"
spec:
  rule:
    - name: allow-10-20-http
      action: "accept"
      logging: true
      servicePolicy: "service-policy1"
      ipProtocol: tcp
      source:
        addresses:
          - "2002::10:20:0:0/96"
        zones:
          - "zone1"
          - "zone2"     
      destination:
        ports:
          - "80"
        zones:
          - "zone3"
          - "zone4"

    - name: allow-10-30-ftp
      action: "accept"
      logging: true
      ipProtocol: tcp
      source:
        addresses:
          - "2002::10:30:0:0/96"
        zones:
          - "zone1"
          - "zone2"
      destination:
        ports:
          - "20"
          - "21"
        zones:
          - "zone3"
          - "zone4"

    - name: allow-us-traffic
      action: "accept"
      logging: true 
      source:
        geos:
          - "US:California"
      destination: 
        geos:
          - "MX:Baja California"
          - "MX:Chihuahua"

    - name: drop-all
      action: "drop"
      logging: true
      ipProtocol: any
      source:
        addresses:
          - "::0/0"
          - "0.0.0.0/0"

• [Logging & Monitoring] 

CNF firewall settings allow not only local logging but also to use HSL logging to external logging destinations.

apiVersion: "k8s.f5net.com/v1"
kind: F5BigLogProfile
metadata:
  name: "cnf-log-profile"
  namespace: "cnf-gateway"
spec:
  name: "cnf-logs"
  firewall:
    enabled: true
    network:
      publisher: "cnf-hsl-pub"
      events:
        aclMatchAccept: true
        aclMatchDrop: true
        tcpEvents: true
        translationFields: true

• Verifying the CNF firewall settings can be done through the sidecar container

kubectl exec -it deploy/f5-tmm -c debug -n cnf-gateway – bash

tmctl -d blade fw_rule_stat

context_type context_name
------------ ------------------------------------------
virtual      cnf-gateway-cnf-fw-policy-SecureContext_vs

rule_name                            micro_rules counter last_hit_time action
------------------------------------ ----------- ------- ------------- ------
allow-10-20-http-firewallpolicyrule            1       2    1638572860      2
allow-10-30-ftp-firewallpolicyrule             1       5    1638573270      2

 

Conclusion

To conclude our article, we showed how CNFs with consolidated data planes help with optimizing CNF deployments. In this article we went through the overview of BIG-IP Next Edge Firewall CNF implementation, sample configuration and monitoring capabilities. More use cases to cover different use cases to be following. 

Related content 

• F5BigFwPolicy 
• BIG-IP Next Cloud-Native Network Functions (CNFs) 
• CNF Home