F5 Cloud-Native Functions For Modern Demands - Part 2
This is the second of a multi part series to introduce the latest addition to F5's cloud-native catalog of solutions, BIG-IP Next Cloud-Native Functions.
Part 1 - F5 Cloud-Native Functions in a Nutshell
- Why Cloud-Native Matters
- CNF Overview
- Quick Deployment
Part 2 - F5 CNF Configuration Quick Look
- Cloud-native configuration methodology
- F5 CRDs Overview
- CGNAT with Security Deployment
Extending Kubernetes with CRDs
Kubernetes is meant to orchestrate containers and it does it well. For things like network firewall security, CGNAT, advanced DNS features and other carrier grade functionality, we need to look beyond its default capabilities. Fortunately, Kubernetes also comes with the ability to extend its API so that we can pretty much make it manage any F5 CNF function in a declarative way. Since it's using the same Kubernetes API, this means easy integration with CI/CD and automation toolsets that are a pillar of cloud-native.
Configuration using F5 Custom Resource Definitions
Let's look at an example of F5 CNF custom resources that can be deployed to setup a listener that does NAT64 and L4 security for traffic destined to the Internet.
Details of all the parameters are documented in the release notes: https://clouddocs.f5.com/cnfs/robin/latest/f5-cnf-1.0.3.pdf
Nat Policy
Here we define the NAT type as "dynamic-pat", the address block or range used for translation, along with other commonly used CGNAT settings.
apiVersion: "k8s.f5net.com/v1"
kind: F5BigNatPolicy
metadata:
name: "nat-policy"
spec:
sourceTranslation:
- name: "dest4"
type: "dynamic-pat"
addresses:
- "12.12.112.0/24"
port: "1025-65535"
routeAdvertisement: true
mapping:
mode: endpoint-independent-mapping
inbound:
mode: "endpoint-independent-filtering"
eifTimeout: 300
hairpinMode: true
clientConnectionLimit: 2000
rule:
- name: rule4
sourceTranslation: "dest4"
Log Profile
Define how and when to log requests and responses.
apiVersion: "k8s.f5net.com/v1"
kind: F5BigLogProfile
metadata:
name: logprofile
spec:
firewall:
enabled: true
network:
publisher: publisher1
events:
aclMatchAccept: true
aclMatchDrop: true
translationFields: true
format:
type: user-defined
userDefinedFieldList: "${date_time},${bigip_hostname},${management_ip_address},${src_ip},${src_port},${dest_ip},${dest_port},${translated_src_ip},${translated_dest_ip},${translated_src_port},${translated_dest_port},${date_time},,${protocol},${action}"
protocolInspection:
enabled: true
publisher: publisher1
dns:
enabled: true
publisher: publisher1
responseLogging: true
Firewall Policy
This CR will define what traffic to accept and/or reject or drop, like how you would configure a network firewall.
apiVersion: "k8s.f5net.com/v1"
kind: F5BigFwPolicy
metadata:
name: "fwpolicy"
spec:
rule:
- name: accept-ue
ipProtocol: any
action: "accept"
source:
vlans:
- "ue-vlan"
logging: true
- name: accept-client
ipProtocol: any
action: "accept"
source:
addresses:
- "220a:c000::/24"
destination:
addresses:
- "220a:c000::/24"
logging: true
- name: default-reject
action: "reject"
logging: true
Listener
This CR will include soft references to the aforementioned resources and define the listener address where traffic will be picked up and processed according to the policies defined.
apiVersion: "k8s.f5net.com/v1"
kind: F5BigContextSecure
metadata:
name: sc64
spec:
ipv6destinationAddress: "64:ff9b::/96"
ipProtocol: "any"
natPolicy: "nat-policy"
logProfile: "logprofile"
firewallEnforcedPolicy: "fwpolicy"
The Result
While I have omitted some detail regarding configuration and call flow, this article aims to provide a general overview of how to deploy and configure a data plane pod that accepts client IPv6 traffic and applies a CGNAT policy and firewall security to the traffic before sending it out to the Internet over an IPv4 path. Since F5 implements fluentd based logging, integrating with a visibility stack like below using Kafka is very simple using readily available plugins.