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
  • Cloud-Connected Configuration
  • Local Configuration

Deployment

Last updated 11 days ago

Qtap offers two flexible management approaches, catering to different deployment needs and preferences: through a cloud control plane or via local configuration files. Both methods provide powerful capabilities with different advantages.

Cloud-Connected Configuration

leverages Qpoint's control plane for centralized management:

  • Setup: Register agents with a token from the Qplane dashboard

  • Management: Configure via the web UI or API

  • Updates: Changes automatically propagate to agents

  • Monitoring: View agent status and health in real-time

# Example: Deploy with cloud-connected configuration
docker run \
  --privileged \
  --pid=host \
  --network=host \
  -v /sys:/sys \
  us-docker.pkg.dev/qpoint-edge/public/qtap:v0 \
  tap \
  --registration-token=YOUR_TOKEN

Local Configuration

  • Setup: Create a qpoint.yaml file with your desired settings

  • Management: Update the configuration file and restart the agent

  • Control: Complete control over all aspects without external dependencies

  • Isolation: Works in air-gapped or restricted environments

# Example: Minimal local configuration
version: 2
services:
  event_stores:
    - id: console_stdout
      type: stdout
  object_stores:
    - id: console_stdout
      type: stdout
stacks:
  default_stack: # Stack Name
    plugins:
      - type: access_logs
        config:
          mode: details # Default action (summary|details|full)
          format: console # (json|console)
          rules:
            - name: summary log example.com
              expr: request.host == "example.com"
              mode: summary
            - name: details log on anything above 400
              expr: response.status >= 400
              mode: full
tap:
  direction: egress
  ignore_loopback: false
  audit_include_dns: true
  http:
    stack: default_stack

uses a YAML file for direct agent configuration:

Cloud-connected mode
Local configuration mode