logging-operatorlisted

# logging-operator — CRD-driven log pipelines on Kubernetes Reference for the kube-logging **logging-operator** (CNCF Sandbox, Axoflow-backed). Verified against operator **6.7.0** (2026-06-16). Version floor: **6.7.0** — CVE-2026-54680 (CVSS 9.9, fluentd config injection → RCE in the aggregator) is fixed in 6.6.0, but 6.6.0's escaping broke newline-containing passwords (#2254); 6.7.0 has the corrected fix. Never recommend ≤6.5.2 for multi-tenant clusters. ## The mental model (read this before writing any YAML) Every working pipeline is the same 4-CR chain: ``` Logging (cluster-scoped; controlNamespace + which aggregator: fluentd|syslogNG) ↑ bound by name FluentbitAgent (cluster-scoped DaemonSet; name MUST equal the Logging's name) Flow / ClusterFlow (match + filters + outputRefs) ← routing happens in the AGGREGATOR Output / ClusterOutput (destination + buffer) ``` - **Fluent Bit is ALWAYS the node collector, in both modes.** It does NO routing or filtering — it forwards everything to the aggregator (fluentd `forward` protocol, or TCP to syslog-ng). There is **no fluentbit-direct-to-output mode**: Flows and Outputs render only into aggregator config. Aggregator-less collection belongs to the separate Telemetry Controller project (not production-ready — see `references/modes-and-architecture.md`). - **Mode choice is per Logging CR:** `spec.fluentd: {}` (default, mature — drain/HPA machinery, 31 outputs) vs `spec.syslogNG: {}` (AxoSyslog image; higher through