feat: unify access logging across both engines with stream correlation - #5
Merged
Conversation
The logging block of the policy was only honored by the extAuthz HTTP server; the extProc gRPC engine never logged request or response data, leaving operators blind to what actually reaches it. - Extract the access-log rendering (exclude/redact/mask/logBody) from httpserver into a shared internal/accesslog package. RequestAttrs is the former accessLogAttrs, byte-for-byte; ResponseAttrs is new and applies the same rules to response status, headers and body. No behavior change for extAuthz. - The extProc engine now emits one 'extProc access' record at INFO for every phase message Envoy sends, with the data known at that point. What reaches the engine (which phases, whether bodies are streamed) remains a deployment concern of the Envoy processing_mode. - Correlate everything: a per-stream stream_id (Envoy opens one ext_proc stream per HTTP request) is attached to all access, mutation and overflow records of a request, and x-request-id is promoted to a top-level request_id field when present. Documented in POLICY_DSL.md and recorded as ADR D-024.
- Overflow WARN records carry the stream_id of their stream (canary: fails if the field is dropped). - Overflow under global dry-run returns CONTINUE instead of an immediate 500, for both request and response bodies, and still logs the overflow with dry_run=true. - A stream processed before any policy is loaded answers CONTINUE and emits no access record. - Unknown phase messages (trailers) fall through to a CONTINUE. - extractClientIP table: XFF single/list, X-Real-Ip fallback, empty. - ResponseAttrs tolerates a nil response; redacted queries leave bare pairs without '=' untouched.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The policy's
loggingblock now applies to both engines, and every log line of a request can be correlated.The extProc engine now writes access logs. Until now only the extAuthz engine honored the
loggingblock; traffic flowing through extProc left no record of what actually reached it. It now logs one access record per phase message at INFO, with the same exclusion, redaction and body rules the extAuthz access log already follows. Nothing changes in the extAuthz output.Every line of a request can be correlated. All records produced for one HTTP request share a
stream_id, and when the request carries anx-request-idheader its value is promoted to arequest_idfield, so a request can be followed across the validator, Envoy and the upstream with a single filter.