F5 Cloud-Native Functions For Secure Ingress

Outline:

• Securing Ingress to Your Clusters
• How F5 can help
• Technical bit on how it works 

This is an addition to a series of articles that introduce some features of the latest release of F5's BIG-IP Next Cloud-Native Functions.

Securing Ingress to Your Clusters

In addition to routing traffic through the TMM proxy pod to the Internet, you can now use the same pod to load balance directly to workloads running inside Kubernetes. This improves performance, latency, and resource consumption, which are especially important in use cases such as for Multi-Access Edge Computing (MEC). This is part of an ongoing effort to merge existing features in BIG-IP Next Service Proxy for Kubernetes (SPK) into a single software bundle, making it even simpler for telco operators to consolidate 5G data plane functionality.

As Kubernetes projects move past the initial rollout of application workloads and confirm basic access from external clients, many users are now exploring how to secure that traffic flow in and out of the worker nodes with a carrier-grade network firewall to address the below issues:

• Lack of a central point for network traffic for both ingress and egress 
• Lack of an easy way to apply access control lists consistently across deployments and clusters
• Lack of visibility of North-South traffic

How F5 can help

As mentioned in a previous article, F5 CNFs can extend Kubernetes with more capabilities and even protect your cloud-native 5G infrastructure by enabling granular control and visibility of traffic to the network functions deployed within your clusters. 

Technical Overview

The two features you can use to achieve this are the ContextSecure and Firewall Policy which give you many parameters for protecting ingress traffic. These are custom resource definitions (CRDs) deployed using the Kubernetes API. This means there is native integration with K8s and also the ability to seamlessly plug into your automation or CI/CD toolset of choice. 

A quick diagram shows what this achieves:

The below policy will enable the use of access control lists (ACLs) that define the set of users to allow or deny access to resources beyond the firewall. Statistics and logging are built in to provide telemetry data and visibility into any potential bad actors, which you can easily mitigate against using native yaml manifests for policy configuration.

Firewall Policy CR

Below is an example Firewall policy that can be referenced and enabled in your ContextSecure listener custom resource. 

apiVersion: "k8s.f5net.com/v1"
kind: F5BigFwPolicy
metadata:
  name: "fwpolicy"
spec:
  rule:
     - name: accept-test
      ipProtocol: any
      action: "accept"
      source:
        addresses:
          - "10.1.20.1/24"
        vlans:
          - "ue-vlan"
      logging: true
    - name: reject-test
      ipProtocol: any
      action: "reject"
      source:
        addresses:
          - "10.1.10.5"
      logging: true
    - name: drop-test
      ipProtocol: any
      action: "drop"
      source:
        addresses:
          - "10.1.10.6"
      logging: true
    - name: drop-all
      action: "drop"
      logging: true
      ipProtocol: any
      source:
        addresses:
          - "::0/0"
          - "0.0.0.0/0"

 

When this policy is applied to a listener that is processing ingress traffic, you can control any combination of single IP addresses, IP ranges, ports, and IP protocol. 

Context Secure CR

Below is an example Context Secure listener that references the above policy. 

apiVersion: "k8s.f5net.com/v1"
kind: F5BigContextSecure
metadata:
  name: sc1n1
  namespace: ns-1n1
service:
  #The k8s service object name for the internal applications (Pods), and creates a round-robin load balancing pool using the Service Endpoints
  name: "nginx-1n1-svc"
  #the k8s service object port value
  port: 80
spec:
  destinationAddress: "100.100.200.155"
  destinationPort: 80
  profile: "fastL4"
  ipProtocol: "tcp"
  profile: "tcp"
  snat:
    type: automap
  logProfile: "logprofile"
  firewallEnforcedPolicy: "fwpolicy"
  vlans:
    vlanList:
    - ue-vlan

 

Here is the application workload running in Kubernetes in a namespace watched by F5 CNF.

# kubectl get po -owide -n ns-1n1
NAME                        READY   STATUS    RESTARTS   AGE   IP                                  NODE                                 NOMINATED NODE   READINESS GATES
nginx-1n1-57dcb5c8d-g74xn   1/1     Running   0          13d   fd74:ca9b:3a09:868c:172:18:0:4a2b   worker-116.f5tokyo.local             <none>           <none>

To test, we can use curl to send a simple request from a client that is in the "allowed list".

curl http://100.100.200.155

 

You'll be able to see that depending on the client IP address as defined in the firewall policy above, the corresponding accept, drop, or reject rules get hit and counters incremented. These are stats that are "pullable" or "scraped" by API so can be easily integrated in solutions like Prometheus.

 

tmctl command is available in the debug container

In the logs, you can see the destination matches the internal IP address of the NGINX pod. Note that all of these logs can be sent to a central stack that manages your telemetry and logging messages that enable a comprehensive view of your cluster.

Logs for accept:

Message from syslogd@f5-tmm-7c487f59c7-l58qh at Jan 29 10:23:43 ...
 tmm[41]Jan 29 2024 01:24:22,f5-tmm-7c487f59c7-l58qh,fd74:ca9b:3a09:868c:172:18:0:4a32,10.1.10.2,36812,100.100.200.155,80,fd74:ca9b:3a09:868c:172:18:0:4a32,fd74:ca9b:3a09:868c:172:18:0:4a2b,18027,8080,Jan 29 2024 01:24:22,,TCP,Accept
 
Message from syslogd@f5-tmm-7c487f59c7-l58qh at Jan 29 10:23:43 ...
 tmm[41]Jan 29 2024 01:24:22,f5-tmm-7c487f59c7-l58qh,fd74:ca9b:3a09:868c:172:18:0:4a32,10.1.10.2,36812,100.100.200.155,80,fd74:ca9b:3a09:868c:172:18:0:4a32,fd74:ca9b:3a09:868c:172:18:0:4a2b,18027,8080,Jan 29 2024 01:24:22,,TCP,Established
 
Message from syslogd@f5-tmm-7c487f59c7-l58qh at Jan 29 10:23:43 ...
 tmm[41]Jan 29 2024 01:24:22,f5-tmm-7c487f59c7-l58qh,fd74:ca9b:3a09:868c:172:18:0:4a32,10.1.10.2,36812,100.100.200.155,80,fd74:ca9b:3a09:868c:172:18:0:4a32,fd74:ca9b:3a09:868c:172:18:0:4a2b,18027,8080,Jan 29 2024 01:24:22,,TCP,Closed

 

Logs for reject:

# curl http://100.100.200.155
curl: (7) Failed connect to 100.100.200.155:80; Connection refused #immediate rst
 
 
Message from syslogd@f5-tmm-7c487f59c7-l58qh at Jan 29 10:15:16 ...
 tmm[41]Jan 29 2024 01:15:56,f5-tmm-7c487f59c7-l58qh,fd74:ca9b:3a09:868c:172:18:0:4a32,10.1.10.2,36786,100.100.200.155,80,,,,,Jan 29 2024 01:15:56,,TCP,Reject

 

Logs for drop:

# curl http://100.100.200.155
<retries occur>
curl: (7) Failed connect to 100.100.200.155:80; Connection refused
 
Message from syslogd@f5-tmm-7c487f59c7-l58qh at Jan 29 09:13:18 ...
 tmm[41]Jan 29 2024 00:13:57,f5-tmm-7c487f59c7-l58qh,fd74:ca9b:3a09:868c:172:18:0:4a32,cccc::100,49058,64:ff9b::a01:461e,80,,,,,Jan 29 2024 00:13:57,,TCP,Drop

 

 

These are just a couple of simple examples showing how easy it is to further enable security for your Kubernetes infrastructure using the same engine that powers this protection in all F5 hardware and software.