Since v0.26, Pomerium configures Envoy to use a custom HTML error page
format string for most errors served by Envoy itself. This format string
uses %COMMAND% directives to include details about the error.
The HTML error page template also includes any branding options set via
the corresponding Enterprise settings. We need to ensure that any %
signs in the branding options strings are escaped to %% so that Envoy
will not interpret them as the start of a %COMMAND% directive, which
could lead to Envoy rejecting the format string as invalid.
* Refactor trace config to match supported otel options
* use duration instead of int64 for otel timeouts
* change 'trace client updated' log level to debug
* update tracing config definitions
* new tracing system
* performance improvements
* only configure tracing in envoy if it is enabled in pomerium
* [tracing] refactor to use custom extension for trace id editing (#5420)
refactor to use custom extension for trace id editing
* set default tracing sample rate to 1.0
* fix proxy service http middleware
* improve some existing auth related traces
* test fixes
* bump envoyproxy/go-control-plane
* code cleanup
* test fixes
* Fix missing spans for well-known endpoints
* import extension apis from pomerium/envoy-custom
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.
The previous default sample rate of 0.0001 is very low, so traces are
unlikely to be visible after enabling them until many thousands of
requests have been sent. This could be confusing to users.
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.
Currently Pomerium will always generate a wildcard certificate for use
as a fallback certificate.
If any other certificate is configured, this fallback certificate will
not normally be presented, except in the case of a TLS connection where
the client does not include the Server Name Indication (SNI) extension.
All modern browsers support SNI, so in practice this certificate should
never be presented to end users.
However, some network scanning tools will probe connections by IP
addresses (without SNI), and so this fallback certificate may be
presented. The presence of this certificate may be flagged as a problem
in some automated vulnerability scans.
Let's avoid generating this fallback certificate if Pomerium has any
other certificate configured (unless specifically requested by the Auto
TLS option). This should prevent false positive reports from these
particular vulnerability scans.
* envoyconfig: cleanup
* remove listener access log for mtls for insecure server which can't use mtls
* use new functions
* rename method
* refactor common code
* Initial test environment implementation
* linter pass
* wip: update request latency test
* bugfixes
* Fix logic race in envoy process monitor when canceling context
* skip tests using test environment on non-linux
This also replaces instances where we manually write "return ctx.Err()"
with "return context.Cause(ctx)" which is functionally identical, but
will also correctly propagate cause errors if present.
Most fields in the config.Options struct are populated by the
mapstructure package, but the SetResponseHeaders field is handled
separately. As a result, when the set_response_headers key is present,
it also shows up as an unknown config option.
Add this key to the ignoreConfigFields map, to avoid logging an
incorrect "unknown config option" message when set.
* 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
Config options concerning the TLS connection from databroker to storage
backend are now unused. TLS options for this connection can instead be
set directly in the databroker storage connection string.
This reverts commit fdefcf9a16.
This was originally intended for a specific integration test use case,
but it did not end up being needed. Additionally, the environment
variable names can conflict with Kubernetes service environment variables.
