Goals

Current some k8s audit logs are not sent using the standard logging data model envelope. Instead the original JSON is sent directly. However other audit logs (e.g. node audit logs) are  wrapped in the standard envelope. This makes it difficult for customers to process logs in a consistent way.

The goal is to design and implement the best way to resolve this issue.

Non-Goals

Motivation

• Having mixed envelopes for log modes makes it difficult to handle logs consistently.
• Our documentation does not explain the different formats, so they are surprising to users.
• LOG-1464 is an example of this confusion.

Alternatives

Document the existing situation clearly, with examples.

Acceptance Criteria

• Clearly documented, understandable approach to handling audit and non-audit logs.
• Implementation follows the documentation.

Risk and Assumptions

• Backwards compatibility for existing users.

Documentation Considerations

The chosen approach must be easily explained and justified in documentation.

Open Questions

There are several options to consider or combine:

• Wrap audit logs in the standard logging data model envelope
  • Treat them exactly like any other JSON logs.
  • Use the structured-log feature as for any other JSON logs.
• Allow audit logs to have a "special" format
  • need to justify why this is the case
  • need to explain how users can separate logs with different formats.
  • maybe use extended log_type as described in LOG-1592
• Allow multiple formats to be specified at the output
  • support a new consistent format alongside an optional legacy format
  • need a general solution for multiple output formats that can be applied beyond this use case.

Additional Notes