Is it possible to target specific pods or namespaces via the configuration?

[rileydakota]

Hello! I am playing around with qtap for some security usecases, and want to know if it possible to constraint the capture of traffic to a set of Kubernetes resources? For example: "All Pods with the label app=compromised or "The namespace bad-thing-here."

Thank you!

[Devin-qpoint]

Great question! Yes, absolutely - qtap can filter traffic capture based on Kubernetes resources like pod labels and namespaces.

Key Point: Container Runtime Socket Mounting

Important: For Kubernetes pod attribution (namespace, labels, etc.) to work, qtap needs access to the container runtime socket. This is crucial - without it, the src.pod.* fields won't be populated.

For Kubernetes deployments:

volumeMounts:
  - name: containerd-socket
    mountPath: /run/containerd/containerd.sock
volumes:
  - name: containerd-socket
    hostPath:
      path: /run/containerd/containerd.sock
      type: Socket

Configuration Examples

1. Filter by Namespace

stacks:
  compromised_namespace:
    plugins:
      - type: access_logs
        config:
          mode: none
          format: console
          rules:
            - name: "Capture compromised namespace traffic"
              expr: src.pod.namespace == "bad-thing-here"
              mode: full

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

2. Filter by Pod Labels

stacks:
  compromised_pods:
    plugins:
      - type: access_logs
        config:
          mode: none
          format: console
          rules:
            - name: "Capture compromised app traffic"
              expr: src.pod.labels.app == "compromised"
              mode: full

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

3. Multiple Conditions (Namespace OR Label)

stacks:
  security_monitoring:
    plugins:
      - type: access_logs
        config:
          mode: none
          format: console
          rules:
            - name: "Monitor suspicious traffic"
              expr: |
                src.pod.namespace == "bad-thing-here" or 
                src.pod.labels.app == "compromised" or
                src.pod.labels.risk == "high"
              mode: full

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

4. Using Arrays for Multiple Values

stacks:
  security_monitoring:
    plugins:
      - type: access_logs
        config:
          mode: none
          format: console
          rules:
            - name: "Monitor multiple suspicious resources"
              expr: |
                src.pod.labels.app in ["compromised", "suspicious", "malware"] or
                src.pod.namespace in ["bad-thing-here", "quarantine", "untrusted"]
              mode: full

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

5. Complex Security Use Case

stacks:
  default_stack:
    plugins:
      - type: access_logs
        config:
          mode: none  # Don't log normal traffic
          format: console
          
  security_stack:
    plugins:
      - type: access_logs
        config:
          mode: summary  # Basic info for all security-relevant traffic
          format: json   # Structured output for easier processing
          rules:
            - name: "Full capture for high-risk pods"
              expr: |
                src.pod.labels.security-risk == "high" or
                src.pod.labels.app == "compromised"
              mode: full
            - name: "Detailed capture for suspicious namespaces"
              expr: |
                src.pod.namespace in ["quarantine", "untrusted", "investigation"]
              mode: details

tap:
  direction: egress
  ignore_loopback: true
  audit_include_dns: false
  http:
    stack: default_stack
  endpoints:
    # Apply security stack to all traffic from suspicious sources
    - domain: "*"
      http:
        stack: security_stack
      # This will be evaluated against the rules in security_stack

Available Kubernetes Fields

You can filter on these Kubernetes-specific fields:

• src.pod.name: Pod name (e.g., frontend-5d4d7d4b45-2jrvs)
• src.pod.namespace: Kubernetes namespace (e.g., production)
• src.pod.labels.<label-name>: Pod labels (e.g., src.pod.labels.app)
• src.container.name: Container name
• src.container.labels.<label-name>: Container labels

Pro Tips for Security Use Cases

1. Start with Wide Capture, Then Filter

stacks:
  security_stack:
    plugins:
      - type: access_logs
        config:
          mode: summary  # Capture metadata for all
          format: json   # Easier for automated processing
          rules:
            - name: "Full capture for investigation targets"
              expr: |
                src.pod.namespace == "investigation" or
                src.pod.labels.security-status == "compromised"
              mode: full

2. Layer Your Monitoring

stacks:
  layered_security:
    plugins:
      - type: access_logs
        config:
          mode: none
          format: json
          rules:
            # Layer 1: Basic monitoring for all suspicious traffic
            - name: "Monitor untrusted namespaces"
              expr: src.pod.namespace in ["untrusted", "quarantine"]
              mode: summary
            # Layer 2: Detailed monitoring for medium risk
            - name: "Monitor medium risk pods"
              expr: src.pod.labels.risk-level == "medium"
              mode: details
            # Layer 3: Full capture for high risk
            - name: "Full capture for high risk"
              expr: |
                src.pod.labels.risk-level == "high" or
                src.pod.labels.app == "compromised"
              mode: full

3. Combine with Process Filtering

tap:
  direction: egress
  ignore_loopback: true
  audit_include_dns: true
  http:
    stack: security_stack
  filters:
    groups:
      - kubernetes  # Ignore standard k8s processes
      - qpoint      # Ignore qtap itself
    # Don't add custom filters if you want to monitor everything

Remember the Socket Mount!

The container runtime socket mounting is essential - without it, qtap won't have access to the Kubernetes metadata needed for this filtering to work. Make sure your deployment includes the appropriate volume mount for your container runtime (containerd, docker, etc.).

This approach gives you fine-grained control over what gets captured based on your security investigation needs, while minimizing noise from non-relevant traffic.