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.
Add a corresponding global setting for the existing route-level
jwt_issuer_format option. The route-level option will take precedence
when set to a non-empty string.
* identity: add support for verifying access and identity tokens
* allow overriding with policy option
* authenticate: add verify endpoints
* wip
* implement session creation
* add verify test
* implement idp token login
* fix tests
* add pr permission
* make session ids route-specific
* rename method
* add test
* add access token test
* test for newUserFromIDPClaims
* more tests
* make the session id per-idp
* use type for
* add test
* remove nil checks
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.
