Couchbase logs can inadvertently contain sensitive PII or credentials, and sharing them without redaction poses a security risk.
Let’s see how Couchbase logs can be managed to protect sensitive information.
Imagine you’re troubleshooting a performance issue with Couchbase. You’ve gathered logs from your cluster nodes, perhaps to send to Couchbase support or to an internal security team. But wait – your logs might be spewing out user IDs, session tokens, or even plain-text passwords. This is a critical security vulnerability.
Here’s a sample log snippet you might see:
[INFO] 2023-10-27 10:30:05.123, my_app_node_1:2112 [conn_mgr] <28765> Client <10.0.0.5:54321> connected. User: admin, SessionID: abcdef1234567890, AuthToken: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
[INFO] 2023-10-27 10:30:05.123, my_app_node_1:2112 [conn_mgr] <28765> Authenticated user 'admin' successfully.
[ERROR] 2023-10-27 10:31:15.456, my_app_node_1:2112 [query_engine] <12345> Error executing query: SELECT * FROM users WHERE username = 'testuser' AND password = 'MySuperSecretPassword123!';
Notice the User: admin, SessionID: abcdef1234567890, and password = 'MySuperSecretPassword123!'. These are exactly the kinds of things you want to hide.
Couchbase’s logging framework is built around ns_server and various service components. The log levels (DEBUG, INFO, WARN, ERROR, FATAL) control the verbosity, but not necessarily the content’s sensitivity. When a connection is established or an operation requiring authentication occurs, these details are often logged by default for debugging purposes.
The primary mechanism for controlling what gets logged and how is through the Couchbase Web Console’s Settings > Logging page. Here, you can adjust log levels for different services (e.g., kv, n1ql, index, diag). However, this console interface doesn’t offer direct redaction capabilities. Redaction needs to be a post-processing step or configured at a lower level if possible.
To effectively redact sensitive data, you typically need to process the log files after they are generated. This is often done using standard Unix/Linux command-line tools or scripting.
Example: Redacting common patterns using sed
Let’s say you want to redact session IDs and passwords. You can use sed to find and replace patterns.
First, locate your log files. They are usually in /opt/couchbase/var/lib/couchbase/log/.
To redact a pattern like SessionID: <some_value>, you can use:
sed -i 's/SessionID: [^,[:space:]]*/SessionID: ***REDACTED*** /g' couchbase.log
This command finds SessionID: followed by any characters that are not a comma or whitespace, and replaces the entire match with SessionID: ***REDACTED*** . The -i flag modifies the file in place.
For passwords, which might appear in queries or authentication attempts, you might have a pattern like password = '<some_password>'.
sed -i "s/password = '[^']*'/password = '***REDACTED***'/g" couchbase.log
This sed command targets values enclosed in single quotes after password = .
If you need to redact PII like User: <username>, you can use:
sed -i 's/User: [^,[:space:]]*/User: ***REDACTED*** /g' couchbase.log
Combine these commands to cover multiple patterns in a single file. It’s good practice to first make a backup of your log file before applying in-place edits.
cp couchbase.log couchbase.log.bak
sed -i 's/SessionID: [^,[:space:]]*/SessionID: ***REDACTED*** /g' couchbase.log
sed -i "s/password = '[^']*'/password = '***REDACTED***'/g" couchbase.log
sed -i 's/User: [^,[:space:]]*/User: ***REDACTED*** /g' couchbase.log
For more complex scenarios or recurring tasks, consider writing a Python or Perl script that can handle more sophisticated pattern matching and logging logic.
The critical insight is that Couchbase’s default logging is designed for detailed diagnostics, not for secure sharing. You are responsible for implementing the sanitization layer. Many administrators overlook this, assuming logs are inherently safe or that changing log levels is sufficient. Neither is true; sensitive data can still leak even at higher log levels if the specific log message contains it.
The next challenge is ensuring consistent application of these redaction rules across all nodes in a cluster and for all log files generated over time.