Add a new reason "client-certificate-required" that will be returned by
the invalid_client_certificate criterion in the case that no client
certificate was provided. Determine this using the new 'presented' field
populated from the Envoy metadata.
* config: add customization options for logging
* config: validate log fields
* proxy: add support for logging http request headers
* log subset of headers
* fix test name
* dont use log.HTTPHeaders for access logs
* canonicalize http/2 headers
Currently we always add an invalid_client_certificate deny rule to all
PPL policies. Instead, let's add this rule only when a client CA is
configured. This way, if a user is not using client certificates at all,
they won't see any reason strings related to client certificates in the
authorize logs.
Change the "valid-client-certificate-or-none-required" reason string to
just "valid-client-certificate" accordingly.
Pass the main Evaluator config to NewPolicyEvaluator so that we can
determine whether there is a client CA configured or not. Extract the
existing default deny rule to a separate method. Add unit tests
exercising the new behavior.
In authorize_test.go, the policy 'to' URLs are numbered from 1 to 11.
However, there is no number 8 (it looks like it was removed in commit
c178819). Update the URLs with numbers 9 through 11 to remove this gap.
Update the "any authenticated user" test case to use the corresponding
AllowAnyAuthenticatedUser policy (currently this case passes because
it's using the policy that allows any GET request, but it's not testing
what it says it should).
Configure Envoy to validate client certificates, using the union of all
relevant client CA bundles (that is, a bundle of the main client CA
setting together with all per-route client CAs). Pass the validation
status from Envoy through to the authorize service, by configuring Envoy
to use the newly-added SetClientCertificateMetadata filter, and by also
adding the relevant metadata namespace to the ExtAuthz configuration.
Remove the existing 'include_peer_certificate' setting from the ExtAuthz
configuration, as the metadata from the Lua filter will include the full
certificate chain (when it validates successfully by Envoy).
Update policy evaluation to consider the validation status from Envoy,
in addition to its own certificate chain validation. (Policy evaluation
cannot rely solely on the Envoy validation status while we still support
the per-route client CA setting.)
Update OPA to v0.54.0, which changes the JSON serialization behavior for
large integers. Remove the formatting workaround and the unit test that
verified that the workaround was still needed.
Rego will sometimes serialize integers to JSON with a decimal point and
exponent. I don't completely understand this behavior.
Add a workaround to headers.rego to convert the JWT "iat" and "exp"
timestamps to a string and back to an integer. This appears to cause
Rego to serialize these values as plain integers.
Add a unit test to verify this behavior. Also add a unit test that will
fail if the Rego behavior changes, making this workaround unnecessary.
* sessions: add impersonate_session_id, remove legacy impersonation
* show impersonated user details
* fix headers
* address feedback
* only check impersonate id on non-nil pbSession
* Revert "only check impersonate id on non-nil pbSession"
This reverts commit a6f7ca5abd.
