Transport Layer Security (TLS) secures network traffic between observability components that may carry complete message payloads or accidentally recorded sensitive fields. In Fluent Bit, network-based plugins share SSL/TLS foundations, so TLS settings apply consistently to network inputs and outputs. section 3.6.3 section 3.9
Enable TLS with `tls on`; it defaults to off. A certificate is required. Certificate validation is controlled by `tls.verify`: a self-signed certificate has no recognized certificate authority (CA) to verify it, so verification must be off, whereas production deployments should use a CA-provided certificate. CA records also support certificate revocation tracking. section 3.6.3
Listing 3.8 HTTP input example: https.conf
[SERVICE] flush 1 log_level debug [INPUT] name http #1 listen 0.0.0.0. port 9882 #2 successful_response_code 200 success_header x-fluent-svc fluent-bit tag http tls on #3 tls.ca_path /etc/pki/tls/certs/ #4 #ts.ca_file /etc/pki/tls/certs/fb-book #5 tls.key_file /etc/pki/tls/certs/fb-book.key tls.verify off #6 [OUTPUT] name stdout match *
This HTTPS input configuration enables TLS, supplies a CA path and private-key file, and disables verification for a self-signed setup. It also exposes the HTTP listener on port 9882 and writes received events to stdout. section 3.6.3
TLS fits network event flows in two common ways:
- Secure an HTTP input that accepts events, using shared network-plugin TLS attributes. section 3.6.3
- Secure Fluent Bit-to-Fluentd forwarding with `tls on`; that connection can additionally use basic authentication or a shared token. section 5.9
Forward events over a protected connection
Configure a forward output with its host and port, then enable TLS and provide the same TLS values used for an HTTP plugin. When communicating with Fluentd, add username/password authentication or a shared token when the deployment requires another access-control layer. section 5.9
