You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Much of the data logged in the authorize log is similar to the data logged in the access log, but there are some subtle differences:
the ip field in the access log will respect the xff_num_trusted_hops setting, while the ip field in the authorize log will not
the authorize log can be configured to log all request headers, while the access log cannot currently be configured in this way
And of course, the main difference is that only the authorize log includes the output of Pomerium policy evaluation: the allow / deny results and the allow-why- / deny-why- reason strings.
I find this all a little confusing.
Could it make sense to unify all the information from these two logs into one combined access log?
Describe the solution you'd like
Configure the authorize service to emit its policy evaluation results as Envoy dynamic metadata. Configure the gRPC access log service to consume this metadata and include fields for the allow / deny / reason strings in the access logs.
In principle this should let us consolidate all information from the authorize logs and access logs in one place.
With one consolidated access/authorize log, we could remove the current "authorize check" log entries from the authorize service, or we could add a configuration option to control this. (This option would be off by default, but could be enabled by any users who want to continue receiving the current authorize service logs — this might be desirable for some deployments using the split service mode.)
Describe alternatives you've considered
n/a
Explain any additional use-cases
A consolidated access/authorize log should help avoid needing to cross-reference data between these two logs, like in this issue:
Is your feature request related to a problem? Please describe.
Much of the data logged in the authorize log is similar to the data logged in the access log, but there are some subtle differences:
ip
field in the access log will respect thexff_num_trusted_hops
setting, while theip
field in the authorize log will notAnd of course, the main difference is that only the authorize log includes the output of Pomerium policy evaluation: the
allow
/deny
results and theallow-why-
/deny-why-
reason strings.I find this all a little confusing.
Could it make sense to unify all the information from these two logs into one combined access log?
Describe the solution you'd like
Configure the authorize service to emit its policy evaluation results as Envoy dynamic metadata. Configure the gRPC access log service to consume this metadata and include fields for the
allow
/deny
/ reason strings in the access logs.In principle this should let us consolidate all information from the authorize logs and access logs in one place.
With one consolidated access/authorize log, we could remove the current
"authorize check"
log entries from the authorize service, or we could add a configuration option to control this. (This option would be off by default, but could be enabled by any users who want to continue receiving the current authorize service logs — this might be desirable for some deployments using the split service mode.)Describe alternatives you've considered
n/a
Explain any additional use-cases
A consolidated access/authorize log should help avoid needing to cross-reference data between these two logs, like in this issue:
Additional context
Envoy API reference:
The text was updated successfully, but these errors were encountered: