Documentation
  • Introduction
    • How It Works
    • Architecture & Data Flow
    • Why another Agent?
    • eBPF Concepts
    • Use Cases
  • Deployment
  • Qtap
    • Getting Started
    • System Requirements
    • Installation
      • Linux Binary
      • Docker Container
      • Helm Chart
      • Kubernetes Manifest
    • Configuration
      • Storage Configuration
      • Traffic Processing with Plugins
      • Traffic Capture Settings
      • Configuration Examples
  • Qplane
    • Getting Started
      • Create an Account
      • Install Qtap
      • Review your Dashboards
    • Installation
      • Linux Binary
      • Docker Container
      • Helm Chart
    • Configuration
  • Security & Compliance
  • License
  • Appendix
    • Qcontrol (Beta)
    • Java
    • Object Storage
      • Google Cloud Storage
    • S3 Credentials for Qtap using Kubernetes Secrets
  • FAQ
Powered by GitBook
On this page
  • Basic Configuration
  • Traffic Direction Settings
  • Network Interface Settings
  • Process Filtering
  • Domain-Specific Rules
  • Complete Example
  1. Qtap
  2. Configuration

Traffic Capture Settings

The tap section in your Qtap configuration controls what traffic is captured and how it's processed. This section provides fine-grained control over which network connections to monitor, what traffic to include or exclude, and how to apply different processing stacks to specific domains.

Basic Configuration

Here's the structure of a basic tap configuration:

tap:
  direction: egress
  ignore_loopback: false
  audit_include_dns: true
  http:
    stack: default_stack

Traffic Direction Settings

The direction parameter controls which traffic flows Qtap captures:

Option
Description

egress

Captures all outgoing traffic (both internal and external)

egress-external

Only captures traffic to external networks

egress-internal

Only captures traffic to internal networks

ingress

Only captures inbound traffic

all

Captures all traffic (inbound and outbound)

tap:
  direction: egress-external  # Only capture traffic going to external networks

Network Interface Settings

Loopback Traffic

The ignore_loopback parameter controls whether traffic on the loopback interface (localhost) is captured:

tap:
  ignore_loopback: true  # Don't capture localhost traffic
  • When set to true, traffic to addresses like 127.0.0.1 or localhost is ignored

  • When set to false, local traffic is included in capture

DNS Traffic

The audit_include_dns parameter controls whether DNS queries are captured:

tap:
  audit_include_dns: true  # Include DNS traffic in audit logs

This is useful for:

  • Troubleshooting DNS resolution issues

  • Tracking which domains your applications are trying to reach

  • Identifying potential DNS-based data exfiltration

Process Filtering

The filters section allows you to control which processes Qtap monitors:

tap:
  filters:
    groups:
      - kubernetes
      - qpoint
    custom:
      - exe: /usr/bin/curl
        strategy: exact
      - exe: /usr/bin/python3
        strategy: prefix
      - exe: .*ruby.*
        strategy: regex

Predefined Process Groups

The groups parameter allows you to ignore specific types of processes:

Group
Description

kubernetes

Standard Kubernetes processes

container

Container runtime processes

gke

Google Kubernetes Engine processes

eks

Amazon Elastic Kubernetes Service processes

qpoint

Qpoint's own processes (prevents self-monitoring)

When a group is included in the list, traffic from those processes is ignored.

Custom Process Filters

The custom parameter allows you to define specific processes to ignore:

custom:
  - exe: /usr/bin/curl
    strategy: exact

Each entry requires:

  • exe: The executable path

  • strategy: Matching strategy, which can be:

    • exact: Exact path match

    • prefix: Path prefix match

    • regex: Regular expression match

Domain-Specific Rules

The endpoints section allows you to apply different processing stacks to specific domains or patterns:

tap:
  http:
    stack: default_stack  # Default stack for most traffic
  endpoints:
    - domain: 'api.payment-processor.com'
      http:
        stack: payment_stack  # Special stack for payment processor traffic
    - domain: 'internal-api.example.com'
      http:
        stack: debug_stack  # Debug stack for internal API traffic

Each endpoint entry consists of:

  • domain: The domain pattern to match (supports wildcards)

  • http.stack: The stack to apply for matching HTTP traffic

This allows you to:

  • Apply detailed logging to specific APIs

  • Handle sensitive traffic differently

  • Focus debugging efforts on problematic domains

Complete Example

Here's a comprehensive example that demonstrates all the main features:

tap:
  direction: egress
  ignore_loopback: true
  audit_include_dns: true
  http:
    stack: default_stack
  filters:
    groups:
      - qpoint
      - kubernetes
    custom:
      - exe: /usr/bin/wget
        strategy: exact
      - exe: /usr/bin/curl
        strategy: exact
  endpoints:
    - domain: 'api.github.com'
      http:
        stack: debug_stack
    - domain: 'api.google.com'
      http:
        stack: debug_stack

This configuration:

  1. Captures all outgoing traffic (direction: egress)

  2. Ignores localhost traffic (ignore_loopback: true)

  3. Includes DNS queries in audit logs (audit_include_dns: true)

  4. Applies the default_stack to most HTTP traffic

  5. Ignores traffic from Kubernetes and Qpoint processes

  6. Ignores traffic from specific executables (wget, curl)

  7. Applies the debug_stack to all traffic to api.github.com and api.google.com domains

PreviousTraffic Processing with PluginsNextConfiguration Examples

Last updated 8 days ago