Open
Description
Problem
Currently, the audit logging middleware uses the same logger instance as the rest of the application (logger.Info()
). This creates several concerns:
- Log mixing: Audit logs are mixed with application logs, making it harder to separate them for compliance and analysis
- Configuration conflicts: Audit logs may need different log levels, formats, or destinations than application logs
- Compliance requirements: Audit logs often need to be stored separately and have different retention policies
- Performance impact: Audit logs might need different buffering or batching strategies
Current Implementation
In pkg/audit/auditor.go
, the logEvent
function uses:
logger.Info(string(eventJSON))
Proposed Solution
Implement a dedicated audit logger that:
- Separate configuration: Allow audit logs to have their own log level, format, and output destination
- Structured output: Ensure audit logs are always in structured JSON format regardless of application log format
- Dedicated destinations: Support sending audit logs to different outputs (files, syslog, external systems)
- Compliance features: Add features like log rotation, retention policies, and integrity verification
Implementation Ideas
- Add an
AuditLogger
interface in the audit package - Provide default implementations (file-based, syslog, etc.)
- Allow configuration of audit logger separately from application logger
- Consider integration with audit log aggregation systems
Related
This issue was identified during the implementation of #204 (audit log middleware).