Add a parameter to evaluator.New() for the previous Evaluator (if any).
If the evaluatorConfig is the same, reuse any PolicyEvaluators for
policies that have not changed from the previous Evaluator.
Use the route IDs along with the policy checksums to determine whether a
given policy has changed. Similarly, add a new cacheKey() method to the
evaluatorConfig to compute a checksum used for determine whether the
evaluatorConfig has changed. (Store this checksum on the Evaluator.)
Remove the deprecated set_authorization_header option entirely. Add an
entry to the removedConfigFields map with a link to the relevant
Upgrading page section.
Set the Envoy option only_verify_leaf_cert_crl, to avoid a bug where
CRLs cannot be used in combination with an intermediate CA trust root.
Update the client certificate validation logic in the authorize service
to match this behavior.
Currently Pomerium replaces dynamic set_request_headers tokens
sequentially. As a result, if a replacement value itself contained a
supported "$pomerium" token, Pomerium may treat that as another
replacement, resulting in incorrect output.
This is unlikely to be a problem given the current set of dynamic
tokens, but if we continue to add additional tokens, this will likely
become more of a concern.
To forestall any issues, let's perform all replacements in one pass,
using the os.Expand() method. This does require a slight change to the
syntax, as tokens containing a '.' will need to be wrapped in curly
braces, e.g. ${pomerium.id_token}.
A literal dollar sign can be included by using $$ in the input.
Add a new match_subject_alt_names option to the downstream_mtls settings
group. This setting can be used to further constrain the allowed client
certificates by requiring that certificates contain a Subject
Alternative Name of a particular type, matching a particular regex.
When set, populate the corresponding match_typed_subject_alt_names
setting within Envoy, and also implement a corresponding check in the
authorize service.
Move the parseCRLs() method from package 'authorize/evaluator' to
'pkg/cryptutil', replacing the existing DecodeCRL() method. This method
will parse all CRLs found in the PEM input, rather than just the first.
(This removes our usage of the deprecated method x509.ParseDERCRL.)
Update this method to return an error if there is non-PEM data found in
the input, to satisfy the existing test that raw DER-encoded CRLs are
not permitted.
Delete the CRLFromBase64() and CRLFromFile() methods, as these are no
longer used.
Add a new max_verify_depth option to the downstream_mtls settings group,
with a default value of 1 (to match the behavior of current Pomerium
releases).
Populate the corresponding setting within Envoy, and also implement a
depth check within isValidClientCertificate() in the authorize service.
Update the isValidClientCertificate() method to consider any
client-supplied intermediate certificates. Previously, in order to trust
client certificates issued by an intermediate CA, users would need to
include that intermediate CA's certificate directly in the client_ca
setting. After this change, only the trusted root CA needs to be set: as
long as the client can supply a set of certificates that chain back to
this trusted root, the client's certificate will validate successfully.
Rework the previous CRL checking logic to now consider CRLs for all
issuers in the verified chains.
Add support for a new token $pomerium.client_cert_fingerprint in the
set_request_headers option. This token will be replaced with the SHA-256
hash of the presented leaf client certificate.
Add an "enforcement" option to the new downstream mTLS configuration
settings group.
When not set, or when set to "policy_default_deny", keep the current
behavior of adding an invalid_client_certificate rule to all policies.
When the enforcement mode is set to just "policy", remove the default
invalid_client_certificate rule that would be normally added.
When the enforcement mode is set to "reject_connection", configure the
Envoy listener with the require_client_certificate setting and remove
the ACCEPT_UNTRUSTED option.
Add a corresponding field to the Settings proto.
Update isValidClientCertificate() to also consult the configured
certificate revocation lists. Update existing test cases and add a new
unit test to exercise the revocation support. Restore the skipped
integration test case.
Generate new test certificates and CRLs using a new `go run`-able source
file.
Partially revert #4374: do not record the peerCertificateValidated()
result as reported by Envoy, as this does not work correctly for resumed
TLS sessions. Instead always record the certificate chain as presented
by the client. Remove the corresponding ClientCertificateInfo Validated
field, and update affected code accordingly. Skip the CRL integration
test case for now.
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.
