* upgrade to go v1.24
* add a macOS-specific //nolint comment too
---------
Co-authored-by: Kenneth Jenkins <51246568+kenjenkins@users.noreply.github.com>
Remove the previous conversion logic in NewPolicyFromProto() for the
jwt_issuer_format field. This would prevent the new "unset" state from
working correctly. Add a unit test to verify that all three values
(unset, "hostOnly" and "uri") will successfully round trip to the proto
format and back again.
Also add a test case for the Options.ApplySettings() method to verify
that an unset jwt_issuer_format will not overwrite the existing value
(if any) in the settings.
* Refactor trace config to match supported otel options
* use duration instead of int64 for otel timeouts
* change 'trace client updated' log level to debug
When applying the settings proto, update the JWT groups filter option
only if the filter set is non-empty.
This is important when deploying Pomerium via the Ingress Controller in
combination with Pomerium Enterprise. In this scenario there is a
settings proto applied from both Ingress Controller and the Enterprise
console, and we want to make sure the one from Ingress Controller does
not overwrite the filter settings from Enterprise.
Add a new option for filtering to a subset of directory groups in the
Pomerium JWT and Impersonate-Group headers. Add a JWTGroupsFilter field
to both the Options struct (for a global filter) and to the Policy
struct (for per-route filter). These will be populated only from the
config protos, and not from a config file.
If either filter is set, then for each of a user's groups, the group
name or group ID will be added to the JWT groups claim only if it is an
exact string match with one of the elements of either filter.
* initial core-zero import implementation
* Update /config/import openapi description and use PUT instead of POST
* update import ui tests
* Add 413 as a possible response for /config/import
* Options/Settings type conversion tests and related bugfixes
* Fixes for proto type conversion and tests
* Update core-zero import client
* Update core-zero import client
* Update import api and environment detection
* update go.mod
* remove old testdata
* Remove usage of deleted setting after merge
* remove extra newline from --version output
The client_ca and client_ca_file settings were deprecated in v0.23.
Remove these options and add a link to the corresponding explanation on
the Upgrading docs page.
Add an environment variable to allow forcing either the stateful or the
stateless authenticate flow.
Split the existing integration test clusters "single" and "multi" into
four new clusters: "single-stateful", "single-stateless",
"multi-stateful", and "multi-stateless", so that the integration tests
will run for both the stateful and the stateless authenticate flows.
(The "kubernetes" cluster is not currently being run, so I've left it
alone for now.)
Update the initialization logic for the authenticate, authorize, and
proxy services to automatically select between the stateful
authentication flow and the stateless authentication flow, depending on
whether Pomerium is configured to use the hosted authenticate service.
Add a unit test case to verify that the sign_out handler does not
trigger a sign in redirect.
* core/config: update file watcher source to handle base64 encoded certificates
* fix data race
* core/config: only allow files in certificates
* remove test
* re-add test
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.
Currently the GetSetResponseHeadersForPolicy() method may add entries to
the global SetResponseHeaders map, which can lead to one route's headers
being applied to other routes.
Instead, make a copy of the SetResponseHeaders map before adding any
route-specific response header entries.
Add additional unit tests for GetSetResponseHeaders() and
GetSetResponseHeadersForPolicy().
Fix the logic around when to add the default invalid_client_certificate
rule: this should only be added if mTLS is enabled and the enforcement
mode is not set to "policy". Add a unit test for this logic.
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.
Update bindEnvs() to add support for binding nested fields of the
Options struct to environment variables. The variable names are formed
by joining the nested fields' mapstructure tags with underscores (after
first converting to uppercase).
This is in preparation for adding a new nested struct for downstream
mTLS settings that will look something like this:
downstream_mtls:
ca_file: /path/to/CA/cert.pem
enforcement: reject_connection
With this change, these fields would be bound to the variables
DOWNSTREAM_MTLS_CA_FILE and DOWNSTREAM_MTLS_ENFORCEMENT.
Allow users to clear the default IdP auth code options, by explicitly
setting an empty idp_request_params map.
To do this in a YAML config file, set:
idp_request_params: {}
