rules-fluentd

fluent-plugin-elasticsearch is the community plugin; for Elasticsearch 8.x+ compatibility use fluent-plugin-opensearch (OpenSearch) or the official Elastic fleet/agent integration. Verify the plugin version matches your cluster version to avoid API compatibility issues that silently drop records.

Fluentd @type exec plugin runs an OS command for each log record — CWE-78. If log data is interpolated into the command string without sanitization, a malicious log line can inject arbitrary shell commands. Prefer dedicated output plugins (e.g., @type elasticsearch, @type s3) that use native APIs. If exec is required, validate all interpolated values strictly.

Fluentd forward output lacks TLS — CWE-319. Log data forwarded between Fluentd nodes travels in plaintext, exposing potentially sensitive log records to network interception. Add a 'transport tls' block with a certificate and key, or enable TLS via the 'tls_cert_path'/'tls_key_path' options.

Hardcoded credential in Fluentd config — CWE-798. Hard-coding passwords or shared_key values in fluent.conf means every developer with repo access has credentials to your log aggregation layer. Use environment variable interpolation ('#{ENV["LOG_PASSWORD"]}') or a secrets manager.

Fluentd HTTP input source (@type http) is configured without authentication — CWE-306. An unauthenticated HTTP endpoint accepts log records from any host, enabling log injection and potentially data exfiltration to your log pipeline. Add 'authentication basic' with a strong shared secret or restrict the bind address to loopback/trusted networks.

Fluentd record_transformer with enable_ruby true — CWE-94. This allows arbitrary Ruby expressions in filter rules. If log fields are interpolated into Ruby code, a malicious log line can execute arbitrary Ruby. Use enable_ruby only for trusted, static expressions; disable it and use simple field transformations otherwise.