CrowdSec

An HTTPS request can appear in both Traefik's access log and a backend web server's log. Feeding both to the same detector could count one request twice. For HTTP detection, the host's CrowdSec engine reads the shared Traefik log. A separate component, the firewall bouncer, polls for decisions and blocks matching addresses through native nftables. A block at this layer can affect several applications that share the ingress.

Detection is not enforcement

Installing a parser or scenario does not prove that requests are read, parsed, turned into decisions, collected by the bouncer, or blocked on the actual traffic path. Those layers are validated independently.

Traffic addressed to a host service crosses the firewall's input hook. Public HTTPS forwarded to Traefik through K3s ServiceLB crosses the forward hook. In a controlled test, a decision was active for the external client's address, yet its request still reached Traefik. Adding a forwarding rule to the original iptables setup also left the request unblocked.

With the native nftables bouncer covering both hooks, the same test increased the matching DROP counter and the test request never appeared in Traefik's log. Removing the decision cleared its address from the managed set. Supplying the decision directly let this test isolate packet blocking from the question of whether real traffic triggers a detection scenario.

The address carrying an active administrative session is not used for ban testing. Acquisition health and firewall enforcement are diagnosed separately, so an empty log stream is not mistaken for a bouncer failure and a healthy parser is not mistaken for proof that packets are blocked.

The source-address behavior that feeds this pipeline is described in K3s.

For routine review, the security report and doctor collect detection and control-health evidence. Follow an unusual result back through acquisition, parsing, decisions and enforcement to identify which part needs investigation.

Readiness after startup

Post-reboot observations established automatic engine and bouncer startup, useful Traefik parsing, recent Local API pulls and the expected native input/forward enforcement structure. Each observation answers a separate question: the process started, requests reached the parser, the bouncer communicated with the API, and the expected firewall chains were present.

Acquisition counters need traffic context. A zero parsed count immediately after startup is a reason to inspect the input, not enough evidence to identify a parser failure. Benign requests followed by increases in both read and parsed counts establish that new access records traverse the acquisition chain. Remaining unparsed lines need their own investigation before assigning a cause.

Collection was also observed across a real log rotation. The kubelet replaced the active Traefik log file, a subsequent HTTPS request succeeded, and CrowdSec continued reading and parsing new records. This exercised the handoff to a new file while the ingress was serving traffic.

Startup and structural checks complement the controlled packet-path test above. They do not independently prove that an external request is blocked, and a healthy process does not replace either form of evidence.