To let Faddom connect to a Kubernetes cluster, you need to provide a kubeconfig file to allow access to the cluster APIs or AWS credentials for EKS. This will allow Faddom to see the Kubernetes cluster. If you also want to see the traffic inside the cluster, you need to set up the nodes to send sFlow traffic to Faddom. For details on using host sFlow our Capturing network traffic using agents guide.

Here are the steps to integrating a Kubernetes cluster in Faddom:

Go to Settings
Select Data Sources
Press on the Kubernetes icon
Provide the kubeconfig file or AWS EKS or AKS credentials

Note: Name needs to be identical to the name of your Kubernetes cluster. For example if the name is Faddom-Kubernetes this is what needs to be added

When using a kubeconfig file, the file should not contain references to other files on the file system. For example, you should use the client-certificate-data field to embed the certificate data in the file instead of using the client-certificate field which references an external file. Once you have added a configuration file, Faddom will be able to access the Kubernetes APIs to add information on the services running on that cluster.

Traffic Collection for Cilium and OpenShift

For clusters running Cilium or OpenShift, Faddom supports dedicated methods of traffic collection.

OpenShift

The IPFIX exporter is not enabled by default in OpenShift. To enable it, configure the Cluster Network Operator (CNO) with your Faddom server, sensor, or proxy as the collector IP.

1. Create a patch file with the following configuration:

spec:
  exportNetworkFlows:
    ipfix:
      collectors:
        - <FADDOM_IP>:4739

2. Apply the configuration:

oc patch network.operator cluster --type merge -p "$(cat <path_to_patch_file>.yaml)"

Alternatively, apply the change from the OpenShift web console:

In the console, navigate to the Network resource under the operator.openshift.io API group, open its Instances view, and select the instance named cluster.

Note: Do not edit the CustomResourceDefinition itself, and do not select EgressRouter, as both are different resources in the same area of the console.

Important: Do not use the spec.exporters syntax (type: IPFIX, targetHost, targetPort, etc.) on this resource. That syntax belongs to a FlowCollector resource managed by the Network Observability Operator, not to operator.openshift.io/v1 Network. Adding it here will cause the resource to fail schema validation.

3. Verify the configuration was applied:

oc get network.operator cluster -o jsonpath="{.spec.exportNetworkFlows}"

Confirm the network operator remains healthy:

oc get clusteroperator network

Expected: AVAILABLE=True, PROGRESSING=False, DEGRADED=False

Confirm Open vSwitch has picked up the IPFIX target on every node:

for pod in $(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}'); do
  echo "=== $pod ==="
  oc -n openshift-ovn-kubernetes exec -c ovnkube-controller "$pod" -- bash -c 'ovs-vsctl find ipfix'
done

Each node should show targets : ["<FADDOM_IP>:4739"].

Confirm Faddom is listening for the flows (run on the Faddom collector):

sudo ss -lunp | grep ':4739'

Generate traffic and search Faddom for a current pod IP, the node IP, or port 4739 to confirm connections appear.

Rollback

To disable all configured OpenShift network-flow collectors:

oc patch network.operator cluster --type='json' 
-p='[{"op":"remove","path":"/spec/exportNetworkFlows"}]'

Prerequisites:

OpenShift CLI (oc) installed
Logged in with cluster-admin privileges
Faddom server, sensor, or proxy reachable from the cluster nodes

For full details, see the official Red Hat documentation on tracking network flows.

Important notes

Flow export adds processing overhead on each node, be sure to monitor cluster performance after enabling it.

UDP delivery cannot be confirmed with TCP-only tools such as Test-NetConnection.

Service IPs are virtual cluster addresses. When correlating traffic in Faddom, search using current pod IPs rather than service IPs, and re-check them after pods are recreated, since their addresses change.

Do not confuse the OpenShift IPFIX collector port with unrelated flow-export ports used elsewhere in your environment (for example, a separate VMware NetFlow sensor port).

If editing the resource through the console after copying a full object, fetch a fresh copy immediately before applying changes (metadata.resourceVersion is server-generated and can go stale).

Cilium

Faddom collects traffic from Cilium clusters via Hubble Relay using a lightweight pod deployed on the cluster.

Prerequisites:

Cilium CNI with Hubble Relay enabled (hubble.relay.enabled=true)
Faddom server, sensor, or proxy reachable from the cluster
Internet access from cluster nodes to pull from Docker Hub (faddom/hubble-agent) (or a private registry for air-gapped installations)

Deployment:

1. Download the deployment files: faddom-hubble-agent.yaml, deploy-faddom-hubble-agent.sh, and optionally network-policy.yaml (for egress restriction) — see the bottom of this article for files.

2. Run the deployment script and follow the prompts: ./deploy-faddom-hubble-agent.sh Or, to apply the manifest directly, first edit faddom-hubble-agent.yaml and replace SENSOR_IP_ADDRESS with your Faddom sensor, proxy, or server IP, then run: kubectl apply -f faddom-hubble-agent.yaml

Configuration:

All settings are environment variables in the deployment YAML:

Environment Variable	Default	Description
`SENSOR_ADDRESS`	(required)	IP or hostname of your Faddom sensor or proxy
`HUBBLE_RELAY_ADDRESS`	`hubble-relay.kube-system.svc.cluster.local`	Hubble Relay service DNS name
`HUBBLE_RELAY_PORT`	`80`	Hubble Relay service port
`OBSERVATION_DOMAIN_ID`	`0`	Set a unique value per cluster when multiple clusters send to the same sensor
`HUBBLE_FLOW_FILTERS`	(empty)	Optional JSON flow filters (see below)
`FLOW_SAMPLE_RATE`	`1`	`1` = every flow. x = 1 in x flows. Increase on large clusters to reduce load. The lower x is, the more responsive Faddom will be to changes

Updating the sensor IP:

kubectl -n faddom-discovery edit configmap faddom-hubble-agent-config kubectl -n faddom-discovery rollout restart deployment faddom-hubble-agent

Updating other settings (triggers automatic pod restart):

kubectl -n faddom-discovery set env deployment/faddom-hubble-agent FLOW_SAMPLE_RATE=10

Flow Filters (Optional):

Filters are applied at the Hubble Relay level before flows reach the agent. DROPPED and ERROR verdicts are always excluded automatically.

# Exclude DNS traffic HUBBLE_FLOW_FILTERS: '[{"destination_port": ["53"], "blacklist": true}]'  # Exclude kube-system namespace HUBBLE_FLOW_FILTERS: '[{"source_pod": ["kube-system/"], "blacklist": true}]'

Changing log level at runtime (no restart required):

kubectl -n faddom-discovery edit configmap faddom-hubble-agent-logging # Change level="INFO" to level="DEBUG" — takes effect within ~65 seconds

To uninstall:

kubectl delete namespace faddom-discovery

network-policy.yaml

faddom-hubble-agent.yaml

deploy-faddom-hubble-agent.sh

How To Integrate My Kubernetes Cluster With Faddom?

Traffic Collection for Cilium and OpenShift

OpenShift

Rollback

Cilium

Configuration: