The Patch() method was intended to skip any records that do not
currently exist. However, currently inmemory.Backend.Patch() will return
ErrNotFound if the last record in the records slice is not found (it
will ignore any other previous records that are not found).
Update the error handling logic here to be consistent with the postgres
backend, and add a unit test to exercise this case.
Update the AccessTracker, WebAuthn handlers, and identity manager
refresh loop to perform their session record updates using the
databroker Patch() method.
This should prevent any of these updates from conflicting.
* core/config: refactor file watcher
* add comments
* updates
* only use the polling watcher
* fix test
* fix test
* try to fix test again
* remove batching
* dont rely on file modification timestamp
* remove benchmark
* try fix again
Add a Patch() method to the databroker gRPC service.
Update the storage.Backend interface to include the Patch() method now
that all the storage.Backend implementations include it.
Add a test to exercise the patch method under concurrent usage.
Remove the Redis databroker backend. According to
https://www.pomerium.com/docs/internals/data-storage#redis it has been
discouraged since Pomerium v0.18.
Update the config options validation to return an error if "redis" is
set as the databroker storage backend type.
Add a new Patch() method that updates specific fields of an existing
record's data, based on a field mask.
Extract some logic from the existing Get() and Put() methods so it can
be shared with the new Patch() method.
Add a method to copy selected fields from one proto message to another
(of the same type), using a FieldMask. This is intended for use in a new
databroker Patch method.
Remove the deprecated set_authorization_header option entirely. Add an
entry to the removedConfigFields map with a link to the relevant
Upgrading page section.
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 client_certificate criterion that accepts a "Certificate
Matcher" object. Start with two certificate match conditions:
fingerprint and SPKI hash, each of which can accept either a single
string or an array of strings.
Add new "client-certificate-ok" and "client-certificate-unauthorized"
reason strings.
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.
Move downstream mTLS settings to a nested config file object, under the
key 'downstream_mtls', and add a new DownstreamMTLSSettings struct for
these settings.
Deprecate the existing ClientCA and ClientCAFile fields in the Options
struct, but continue to honor them for now (log a warning if either is
populated).
Delete the ClientCRL and ClientCRLFile fields entirely (in current
releases these cannot be set without causing an Envoy error, so this
should not be a breaking change).
Update the Settings proto to mirror this nested structure.
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.
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.
Fetch the HPKE public key only when configured to use the hosted
authenticate service. Determine whether we are using the hosted
authenticate service by comparing the resolved authenticate domain with
a hard-coded list of hosted authenticate domains.
Extract this list of hosted authenticate domains to the internal/urlutil
package in order to keep a single source of truth for this data.
* support loading route configuration via rds
* fix any shadowing
* fix test
* add fully static option
* support dynamically defined rds
* fix build
* downgrade opa
