Architecture of Universal Cloud Tap - Container

UCT-C enables the capture of network traffic directly from Kubernetes workload pods and facilitates its redirection to designated tunnel destinations, such as V Series appliances or monitoring and security tools.

The controller is deployed as a Kubernetes Deployment with a replica count set to 1, ensuring that only a single instance of the controller operates within the Kubernetes cluster. A corresponding Controller Service is created to enable seamless communication with the controller.

The Universal Cloud Tap - Container works with the following components:

GigaVUE-FM Fabric Manager is a browser-based fabric management and orchestration interface that provides a single pane of glass visibility, management, and orchestration of both the physical and virtual.
UCT-C Tap is the primary UCT-C module that collects the workload traffic, filters it, and tunnels the filtered traffic directly to the tools or through the GigaVUE V Series Nodes. It also sends the traffic policy statistics and heartbeats to the UCT-C Controller. UCT-C Tap must run as a privileged pod.
Note: UCT-C uses eBPF (extended Berkeley Packet Filter) to tap traffic from user pods. eBPF runs on the Linux kernel and requires privileged pod permission in Kubernetes. UCT-C Tap pods require SYS_ADMIN and NET_ADMIN privileges to attach eBPF Hooks, run commands in other namespaces, and run low-level networking commands.
UCT-C Controller is the management component of UCT-C that controls and communicates with UCT-C Tap. UCT-C Controller collects the data from UCT-C Taps and sends the collected statistics and heartbeats to GigaVUE-FM.

The following diagram illustrates the various components involved in the UCT-C solution.

The UCT-C Controller acts as the central communication link between GigaVUE-FM and UCT-C Taps, managing registration, policy deployment, data collection, and statistics reporting. The process begins with the UCT-C Controller registering with GigaVUE-FM, after which the UCT-C Taps are also registered through the Controller. Once registered, GigaVUE-FM communicates with the UCT-C Taps exclusively through the UCT-C Controller, ensuring a structured flow of configuration and data.

When GigaVUE-FM deploys traffic policies, the controller receives and distributes them to the connected UCT-C Taps, instructing them on how to filter and process network traffic. The filtered network packets are then either tunneled directly to connected monitoring and security tools or sent through GigaVUE V Series Nodes deployed within a supported GigaVUE Cloud Suite environment.

The UCT-C Controller also manages ongoing communication and monitoring by collecting data from the UCT-C Taps, including traffic statistics and system health information. It consolidates these details and transmits them back to GigaVUE-FM, ensuring continuous visibility into network activity. Additionally, the controller sends periodic heartbeats to confirm the status and availability of UCT-C Taps, enabling GigaVUE-FM to monitor the system’s overall health and performance.

The UCT-C solution can tap mirrored and Precryption traffic (refer to the architecture diagram above). UCT-C provides multiple tunneling options to send the acquired traffic to external systems for further processing or analysis. The supported tunneling types are:

■

Layer 2 Generic Routing Encapsulation (L2GRE): A tunneling protocol that encapsulates Layer 2 traffic to transport it over an IP network.

■

Virtual Extensible LAN (VXLAN): A network virtualization technology that encapsulates Layer 2 Ethernet frames inside Layer 3 UDP packets. It is typically used to create a virtualized Layer 2 network that runs over a Layer 3 infrastructure, allowing for better scalability and flexibility in cloud environments.

■

Transport Layer Security - PCAPng (TLS-PCAPng ): A secure tunneling method that captures traffic in a standardized PCAPng format, encrypted using TLS, ensuring the confidentiality and integrity of the data during transmission.

These tunneling protocols allow the UCT-C to send the captured traffic to the GigaVUE V Series Nodes or external network monitoring tools, ensuring that all network traffic data is securely transmitted and available for analysis.

Traffic Tapping in Kubernetes Using GigaVUE-FM

Kubernetes inventory sync:

When the Controller starts, it gathers inventory information about the Kubernetes cluster in which it runs, including data on worker nodes, Kubernetes services, and Pods. The controller then sends this information to GigaVUE‑FM. It also registers with the Kubernetes cluster to receive real-time notifications of any changes in the cluster's inventory. As changes occur, the controller pushes these updates to GigaVUE‑FM.

UCT-C Tap Registration and Inventory Sync:

When a UCT-C Tap starts on a node, it sends its registration message to the controller, which then forwards it to GigaVUE‑FM. This way, GigaVUE‑FM knows which UCT-C Tap runs on which worker node.

GigaVUE-FM Tap Selection Based on Inventory:

Access to inventory information and knowing which UCT-C Taps are running on which nodes allow GigaVUE‑FM to apply configuration policies and rules. You can choose which pods should be tapped for traffic based on Kubernetes resources such as nodes, namespaces, and pods.

Policy-Based Traffic Tapping in GigaVUE-FM:

When a user configures a policy for tapping, GigaVUE‑FM determines the list of worker pods that need to be tapped based on the Source Selection criteria. It also identifies the nodes on which these pods are running. Subsequently, GigaVUE‑FM requests the controller to configure the UCT-C Tap on each node to tap traffic from the specified worker pods.

GigaVUE-FM Policy Transmission to Controller:

When GigaVUE‑FM sends this policy to the controller.

Controller Forwards Policy to UCT-C Tap:

The controller forwards the policy configuration to the UCT-C Tap, which is responsible for implementing the policy. The UCT-C Tap then applies the policy to tap traffic from the specified worker pods.

UCT-C Tap Tunnels Traffic using eBPF Hooks:

After this, the UCT-C Tap adds eBPF hooks at the TC layer to get the traffic and tunnel it to the designated endpoint specified in the policy. Once this process is complete, traffic to and from these pods is tunneled to the destination outlined in the policy.