Trap Configuration¶

A trap service is a simple server that can handle SNMP traps sent by SNMP devices, such as routers or switches.

Trap configuration file¶

The trap configuration is kept in the values.yaml file in section traps. values.yaml is used during the installation process for configuring Kubernetes values.

See the following trap example configuration:

traps:
  communities:
    1:
      - public 
    2c:
      - public
      - homelab
  usernameSecrets:
    - secretv3
    - sc4snmp-homesecure-sha-des

  # Overrides the logLevel tag whose default is the chart
  logLevel: "WARN"
  # disableMongoDebugLogging is used to disable extensive debug logging for MongoDB+pymongo while logLevel is set to DEBUG.
  disableMongoDebugLogging: true
  # controls whether to add the context_engine_id field to v3 trap events
  includeSecurityContextId: false
  # replicas: Number of replicas for trap container should be 2x number of nodes
  replicas: 2
  #loadBalancerIP: The IP address in the metallb pool
  loadBalancerIP: 10.202.4.202
  resources: 
    limits:
      cpu: 500m
      memory: 512Mi
    requests:
      cpu: 200m
      memory: 256Mi

Define communities¶

communities defines a version of an SNMP protocol and an SNMP community string, which should be used. The communities key is split by protocol version, with 1 and 2c as supported values. Under the version section, you can define the SNMP community string.

See the following example:

traps:
  communities:
    1:
      - public 
    2c:
      - public
      - homelab

Configure user secrets for SNMPv3¶

The usernameSecrets key in the traps section defines the SNMPv3 secrets for the trap messages sent by the SNMP device. usernameSecrets defines which secrets in “Secret” objects in k8s should be used, as a value it needs the name of “Secret” objects. For more information on how to define the “Secret” object for SNMPv3, see SNMPv3 Configuration.

See the following example:

traps:
    usernameSecrets:
      - sc4snmp-homesecure-sha-aes
      - sc4snmp-homesecure-sha-des

Define security engines ID for SNMPv3¶

SNMPv3 TRAPs require the configuration of SNMP Engine ID of the TRAP sending application for the USM users table of the TRAP receiving application for each USM user. The SNMP Engine ID is usually unique for the device, and the SC4SNMP as a trap receiver has to be aware of which security engine IDs to accept. Define all of them under traps.securityEngineId in values.yaml.

By default, it is set to a one-element list: [80003a8c04], for example:

traps:
    securityEngineId: 
      - "80003a8c04"

The securityEngineID is a substitute of the -e variable in snmptrap. The following is an example of an SNMPv3 trap:

snmptrap -v3 -e 80003a8c04 -l authPriv -u snmp-poller -a SHA -A PASSWORD1 -x AES -X PASSWORD1 10.202.13.233 '' 1.3.6.1.2.1.2.2.1.1.1

Updating trap configuration¶

If you need to update part of the traps configuration, you can do it by editing the values.yaml and then running the following command to restart the pod deployment:

microk8s kubectl rollout restart deployment snmp-splunk-connect-for-snmp-trap -n sc4snmp

Info

The name of the deployment can differ based on the helm installation name. This can be checked with the following command:

microk8s kubectl get deployments -n sc4snmp

Define external gateway for traps¶

Using MetalLB LoadBalancer¶

If you use SC4SNMP on a multinode setup, configure loadBalancerIP. loadBalancerIP should be an IP assigned from your MetalLB address pool in the same subnet as your cluster nodes can reach. See the following example:

traps:
  loadBalancerIP: 10.202.4.202

If you have enabled IPv6 dual‑stack, provide both IPv4 and IPv6 addresses as a comma‑separated list: See the following example:

traps:
  loadBalancerIP: 10.202.4.202,2001:0DB8:AC10:FE01:0000:0000:0000:0001

Using NodePort¶

For single‑node clusters or simple setups without a load balancer, you can expose the traps receiver on a fixed port across all node IPs with NodePort:

traps:
  service: 
    type: NodePort
    externalTrafficPolicy: Cluster
    nodePort: 30000

This way the trap receiver will be available on all node IPs on port 30000.

Using Cloud Load Balancer¶

You can also deploy the traps receiver without MetalLB or NodePort, using Kubernetes Service annotations supported by your cloud platform. For example, on AWS EKS you can enable an AWS Network Load Balancer with annotations:

traps:
  service:
    usemetallb: false
    annotations:
      service.beta.kubernetes.io/aws-load-balancer-type: external
      service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
      service.beta.kubernetes.io/aws-load-balancer-scheme: internal

Define number of traps server replica¶

replicaCount defines that the number of replicas per trap container should be 2 times the number of nodes.

traps:
  #For production deployments the value should be at least 2x the number of nodes
  # Minimum 2 for a single node
  # Minimum 6 for multi-node HA
  replicaCount: 2

Define log level¶

The log level for trap can be set by changing the value for the logLevel key. The allowed values areDEBUG, INFO, WARNING, or ERROR. The default value is WARNING.

Define annotations¶

In case you need to append some annotations to the trap service, you can do so by setting traps.service.annotations, for example:

traps:
  service:
    annotations:
      annotation_key: annotation_value

Aggregate traps¶

In case you want to see traps events collected as one event inside Splunk, you can enable it by setting traps.aggregateTrapsEvents, for example:

traps:
  aggregateTrapsEvents: "true"

Then the upgrade command can be executed.