Adding Tigera Calico via Syslog

Overview

Calico is a network policy engine (CNI) for Kubernetes, developed by Tigera. This article explains how to forward the log lines produced by Calico's Felix dataplane component (running inside the calico-node pod on each cluster node) to Logsign Unified SecOps Platform via syslog, for security analytics and forensic purposes.

Prerequisites

• A Kubernetes cluster running Calico as the CNI. Felix (Calico's per-node dataplane agent) writes its log lines to the calico-node pod's stdout/stderr, the standard container logging path — Calico itself does not send syslog directly.
• A node-level log forwarder (for example rsyslog, Fluent Bit, or Fluentd) already configured to read the node's container log files (typically /var/log/containers/*.log, in the CRI log format Kubernetes writes by default) and relay them onward. Configuring that forwarder is part of your cluster's own logging stack and is outside Logsign's scope; this article covers what to point it at and what Logsign's parser expects to receive.
• Network reachability from the nodes' log forwarder to the Logsign syslog collector on the port you configure.

Configure On Your Kubernetes Nodes

Unverified: the exact configuration steps depend on which log forwarder your cluster uses (rsyslog, Fluent Bit, Fluentd, or another shipper) and were not verified against a specific product's console during this research. The points below describe the log shape Logsign's parser expects, not a specific vendor's menu path — consult your log forwarder's own documentation for the exact syntax.

• Point your node-level log forwarder at the Logsign syslog collector's IP address and port.
• Logsign's parser expects a syslog envelope (timestamp, node hostname, tag) followed by the container runtime's CRI fields (a received timestamp, the stream name stdout/stderr, and an F/P full-or-partial tag) and then the raw Felix log line. This is the layout most log shippers produce by default when reading Kubernetes' standard /var/log/containers files, so most deployments need no special formatting beyond pointing the shipper at Logsign.
• If your pipeline ships these logs through Fluent Bit's Elasticsearch output (a common pattern when the same pipeline also indexes into an ES cluster), Logsign recognizes that JSON-wrapped shape automatically as well — see "Log Format and Supported Events" below. No separate configuration is needed for this variant; both shapes can arrive on the same syslog source.

Add Device in Logsign USO

Open the Logsign Unified SecOps Platform web interface and click the + Device button under Settings > Data Collection. In the Source Type Selection page, choose Syslog as the collection method, select Tigera as the vendor, and Calico as the product.

Click Save to add the source. Once your log forwarder is relaying Calico logs to the configured host/port, events should begin appearing under Search.

Log Format and Supported Events

Logsign recognizes two shapes of the same underlying Felix log line, both illustrated below (synthetic examples, not captured live traffic):

Plain CRI-wrapped line

Aug 19 23:59:59 master03 kubernetes-containers 2026-08-19T23:59:59.239000+04:00 stdout F 2026-08-19 19:59:59.238 [INFO][1026703] felix/int_dataplane.go 2040: Received *proto.HostMetadataV4V6Update update from calculation graph msg=hostname:"master02" ipv4_addr:"10.0.0.29/24"

This is Felix's own log line, forwarded as-is by the node's log shipper with a syslog + CRI envelope in front of it.

Fluent Bit-wrapped line

Aug 19 23:59:59 master02 kubernetes-containers 2026-08-19T23:59:59.685+04:00 stdout F {"@timestamp":"2026-08-19T19:59:59.240Z","stream":"stderr","kubernetes":{"pod_name":"calico-node-zq5g8","namespace_name":"kube-system","container_name":"calico-node","container_image":"quay.io/calico/node:v3.29.1","host":"worker07"},"log":"2026-08-19 19:59:59.240 [ERROR][1050617] felix/int_dataplane.go 1540: Failed to apply dataplane updates error=connection refused\n","time":"2026-08-19T23:58:30.240+04:00"}

Some pipelines that also index into Elasticsearch via Fluent Bit produce this JSON-wrapped form instead. Logsign unwraps it automatically and extracts the same fields as the plain form, plus the pod name, container name/image, namespace, and node hostname carried in the kubernetes block.

Extracted fields

Every event also carries the Felix source file and line (Module / Details), the free-text message (Event Info), the process ID, and which stream it came from (stdout/stderr). When the Fluent Bit-wrapped form is used, the pod name and image (Object), namespace (Tenant), container name (Application), and the actual Kubernetes node hostname (Device) are populated as well; the plain CRI form does not carry these and only reports the log-shipper's own hostname under Device.

Notes and Limits

• Only Felix's own log line format (<timestamp> [LEVEL][pid] file line: message) is parsed. Other container log lines present on the same node — etcd, kube-proxy, klog-based components, or application logs sharing the same log path — are not matched by this plugin and fall through to Logsign's generic classification rather than being misparsed as Calico events.
• Elasticsearch bulk-action lines that some Fluent Bit pipelines emit alongside the JSON-wrapped format (for example {"create":{"_index":"..."}}) are recognized and silently dropped; they carry no event content.
• A line truncated mid-transmission (for example by a log shipper's maximum message size setting) is dropped rather than misparsed. If you notice fewer events than expected, check whether your log shipper is truncating long Calico lines.
• This is a syslog-based, parser-only integration; there is no API poller or credential to configure on the Logsign side.

Verification

• Confirm the source is receiving data under Settings > Data Collection (event count should increase).
• Search for the source's Device Name/Tag under Search to confirm parsed events show Vendor Tigera, Product Calico, and fields such as Event Module, Event Info, and Severity populating correctly.