## Summary
the `mcp: pass_upstream_access_token` option should take effect even if
no upstream oauth config is set.
## Related issues
<!-- For example...
- #159
-->
## User Explanation
<!-- How would you explain this change to the user? If this
change doesn't create any user-facing changes, you can leave
this blank. If filled out, add the `docs` label -->
## Checklist
- [ ] reference any related issues
- [ ] updated unit tests
- [ ] add appropriate label (`enhancement`, `bug`, `breaking`,
`dependencies`, `ci`)
- [ ] ready for review
## Summary
Currently in core we support weighted URLs like this in the config file:
```yaml
to:
- https://a.example.com,1
- https://b.example.com,2
```
However in the protobuf we use a separate `load_balancing_weights`
field:
```proto
message Route {
repeated string to = 3;
repeated uint32 load_balancing_weights = 37;
}
```
This PR updates the code to convert from protobuf so that it also
supports weights directly in the `to` addresses. The existing
`load_balancing_weights` behavior is preserved and will take precedence
when provided.
## Related issues
-
[ENG-2398](https://linear.app/pomerium/issue/ENG-2398/enterprise-api-upstream-weight-is-not-parsed)
## Checklist
- [x] reference any related issues
- [x] updated unit tests
- [x] add appropriate label (`enhancement`, `bug`, `breaking`,
`dependencies`, `ci`)
- [x] ready for review
## Summary
Update the `RouteID` to use the `policy.ID` if it is set. This makes it
so that updated routes use a stable identifier between updates so if the
envoy control plane is updated before the authorize service's internal
definitions (or vice-versa) the authorize service will still be able to
match the route.
The current behavior results in a 404 if envoy passes the old route id.
The new behavior will result in inconsistency, but it should be quickly
remedied. To help with debugging 4 new fields were added to the
authorize check log. The `route-id` and `route-checksum` as the
authorize sees it and the `envoy-route-id` and `envoy-route-checksum` as
envoy sees it.
I also updated the way we send updates to envoy to try and model their
recommended approach:
> In general, to avoid traffic drop, sequencing of updates should follow
a make before break model, wherein:
>
> - CDS updates (if any) must always be pushed first.
> - EDS updates (if any) must arrive after CDS updates for the
respective clusters.
> - LDS updates must arrive after corresponding CDS/EDS updates.
> - RDS updates related to the newly added listeners must arrive after
CDS/EDS/LDS updates.
> - VHDS updates (if any) related to the newly added RouteConfigurations
must arrive after RDS updates.
> - Stale CDS clusters and related EDS endpoints (ones no longer being
referenced) can then be removed.
This should help avoid 404s when configuration is being updated.
## Related issues
-
[ENG-2386](https://linear.app/pomerium/issue/ENG-2386/large-number-of-routes-leads-to-404s-and-slowness)
## Checklist
- [x] reference any related issues
- [x] updated unit tests
- [x] add appropriate label (`enhancement`, `bug`, `breaking`,
`dependencies`, `ci`)
- [x] ready for review
Add a new 'depends_on' route configuration option taking a list of
additional hosts to redirect through on login. Update the authorize
service and proxy service to support a chain of /.pomerium/callback
redirects. Add an integration test for this feature.
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
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
* Optimize policy iterators (go1.23)
This modifies (*Options).GetAllPolicies() to use a go 1.23 iterator
instead of copying all policies on every call, which can be extremely
expensive. All existing usages of this function were updated as
necessary.
Additionally, a new (*Options).NumPolicies() method was added which
quickly computes the number of policies that would be given by
GetAllPolicies(), since there were several usages where only the
number of policies was needed.
* Fix race condition when assigning default envoy opts to a policy
Add a distinction between TCP routes depending on whether the To URL(s)
have the scheme tcp://. For routes with a TCP upstream, configure Envoy
to terminate CONNECT requests and open a TCP tunnel to the upstream
service (this is the current behavior). For routes without a TCP
upstream, configure Envoy to proxy CONNECT requests to the upstream.
This new mode can allow an upstream proxy server to terminate a CONNECT
request and open its own TCP tunnel to the final destination server.
(Note that this will typically require setting the preserve_host_header
option as well.)
Note that this requires Envoy 1.30 or later.
Remove the deprecated set_authorization_header option entirely. Add an
entry to the removedConfigFields map with a link to the relevant
Upgrading page section.
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.
