82fdfa84b8
## Describe your changes
Native AWS Bedrock requests carry the model in the URL path as a
cross-region inference-profile id (e.g.
`us.anthropic.claude-haiku-4-5`). The request parser normalizes that to
the catalog key (`anthropic.claude-haiku-4-5`) before the router runs,
but the router matched it against the operator's registered provider
models with exact string equality. So a Bedrock provider registered with
the id Bedrock actually uses (`us.anthropic…`) never matched a
normalized request → the request denied with
`llm_policy.model_not_routable` ("no provider configured for model …").
Only a provider registered with the already-stripped catalog id worked,
which is not how Bedrock ids appear.
Fix: introduce a single shared `llm.NormalizeBedrockModel` (the same
ARN/region-prefix/version-suffix stripping the parser already does) and,
in the router's `routeClaimsModel`, normalize a **Bedrock** route's
candidate models before comparing. Now a Bedrock provider registered
with either the raw inference-profile id or the normalized catalog id
matches the request. Non-Bedrock routes keep exact matching.
Surfaced by the new native-Bedrock e2e (`WireBedrock`,
`/model/{id}/invoke`); the old e2e used the Anthropic body shape, which
never normalized either side and so hid this.
The request parser keeps its own identical normalizer for now;
de-duplicating it onto `llm.NormalizeBedrockModel` is a trivial
follow-up.
## Issue ticket number and link
N/A — follow-up to the Agent Network Bedrock support / model-allowlist
work.
## Stack
<!-- branch-stack -->
### Checklist
- [x] Is it a bug fix
- [ ] Is a typo/documentation fix
- [ ] Is a feature enhancement
- [ ] It is a refactor
- [x] Created tests that fail without the change (if possible)
- [x] This change does **not** modify the public API, gRPC protocols,
functionality behavior, CLI / service flags, or introduce a new feature
— **OR** I have discussed it with the NetBird team beforehand (link the
issue / Slack thread in the description). See
[CONTRIBUTING.md](https://github.com/netbirdio/netbird/blob/main/CONTRIBUTING.md#discuss-changes-with-the-netbird-team-first).
> By submitting this pull request, you confirm that you have read and
agree to the terms of the [Contributor License
Agreement](https://github.com/netbirdio/netbird/blob/main/CONTRIBUTOR_LICENSE_AGREEMENT.md).
## Documentation
Select exactly one:
- [ ] I added/updated documentation for this change
- [x] Documentation is **not needed** for this change (explain why)
Internal routing correctness fix; no user-facing surface change.
### Docs PR URL (required if "docs added" is checked)
Paste the PR link from https://github.com/netbirdio/docs here:
https://github.com/netbirdio/docs/pull/__
## Tests
- `proxy/internal/llm`: `NormalizeBedrockModel` unit cases (region
prefixes, version suffixes, ARN).
- `proxy/internal/middleware/builtin/llm_router`: `routeClaimsModel`
matches a Bedrock route registered with the raw `us.anthropic…` id
against a normalized request model; non-Bedrock routes still match
exactly.
Note: full through-tunnel e2e verification of this (the native-Bedrock
`TestProvidersMatrix/bedrock`) also needs the DNS lazy-connection
warm-up (separate PR) to get the client past the proxy-peer gate; they
converge once both land.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Improved Amazon Bedrock model matching across ARN formats, regional
prefixes, and version or throughput suffixes.
* Bedrock routes now correctly match equivalent model identifiers even
when requests and route configurations use different formats.
* Non-Bedrock model matching remains exact.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Netbird Reverse Proxy
The NetBird Reverse Proxy is a separate service that can act as a public entrypoint to certain resources within a NetBird network. At a high level, the way that it operates is:
- Configured routes are communicated from the Management server to the proxy.
- For each route the proxy creates a NetBird connection to the NetBird Peer that hosts the resource.
- When traffic hits the proxy at the address and path configured for the proxied resource, the NetBird Proxy brings up a relevant authentication method for that resource.
- On successful authentication the proxy will forward traffic onwards to the NetBird Peer.
Proxy Authentication methods supported are:
- No authentication
- Oauth2/OIDC
- Emailed Magic Link
- Simple PIN
- HTTP Basic Auth Username and Password
Management Connection and Authentication
The Proxy communicates with the Management server over a gRPC connection. Proxies act as clients to the Management server, the following RPCs are used:
- Server-side streaming for proxied service updates.
- Client-side streaming for proxy logs.
To authenticate with the Management server, the proxy server uses Machine-to-Machine OAuth2. If you are using the embedded IdP //TODO: explain how to get credentials. Otherwise, create a new machine-to-machine profile in your IdP for proxy servers and set the relevant settings in the proxy's environment or flags (see below).
User Authentication
When a request hits the Proxy, it looks up the permitted authentication methods for the Host domain. If no authentication methods are registered for the Host domain, then no authentication will be applied (for fully public resources). If any authentication methods are registered for the Host domain, then the Proxy will first serve an authentication page allowing the user to select an authentication method (from the permitted methods) and enter the required information for that authentication method. If the user is successfully authenticated, their request will be forwarded through to the Proxy to be proxied to the relevant Peer. Successful authentication does not guarantee a successful forwarding of the request as there may be failures behind the Proxy, such as with Peer connectivity or the underlying resource.
TLS
Due to the authentication provided, the Proxy uses HTTPS for its endpoint, even if the underlying service is HTTP.
Certificate generation can either be via ACME (by default, using Let's Encrypt, but alternative ACME providers can be used) or through certificate files.
When not using ACME, the proxy server attempts to load a certificate and key from the files tls.crt and tls.key in a specified certificate directory.
When using ACME, the proxy server will store generated certificates in the specified certificate directory.
Auth UI
The authentication UI is a Vite + React application located in the web/ directory. It is embedded into the Go binary at build time.
To build the UI:
cd web
npm install
npm run build
For UI development with hot reload (served at http://localhost:3031):
npm run dev
The built assets in web/dist/ are embedded via //go:embed and served by the web.ServeHTTP handler.
Configuration
NetBird Proxy deployment configuration is via flags or environment variables, with flags taking precedence over the environment. The following deployment configuration is available:
| Flag | Env | Purpose | Default |
|---|---|---|---|
-debug |
NB_PROXY_DEBUG_LOGS |
Enable debug logging | false |
-mgmt |
NB_PROXY_MANAGEMENT_ADDRESS |
The address of the management server for the proxy to get configuration from. | "https://api.netbird.io:443" |
-addr |
NB_PROXY_ADDRESS |
The address that the reverse proxy will listen on. | ":443 |
-url |
NB_PROXY_URL |
The URL that the proxy will be reached at (where endpoints will be CNAMEd to). If unset, this will fall back to the proxy address. | "proxy.netbird.io" |
-cert-dir |
NB_PROXY_CERTIFICATE_DIRECTORY |
The location that certificates are stored in. | "./certs" |
-acme-certs |
NB_PROXY_ACME_CERTIFICATES |
Whether to use ACME to generate certificates. | false |
-acme-addr |
NB_PROXY_ACME_ADDRESS |
The HTTP address the proxy will listen on to respond to HTTP-01 ACME challenges | ":80" |
-acme-dir |
NB_PROXY_ACME_DIRECTORY |
The directory URL of the ACME server to be used | "https://acme-v02.api.letsencrypt.org/directory" |
-oidc-id |
NB_PROXY_OIDC_CLIENT_ID |
The OAuth2 Client ID for OIDC User Authentication | "netbird-proxy" |
-oidc-secret |
NB_PROXY_OIDC_CLIENT_SECRET |
The OAuth2 Client Secret for OIDC User Authentication | "" |
-oidc-endpoint |
NB_PROXY_OIDC_ENDPOINT |
The OAuth2 provider endpoint for OIDC User Authentication | "https://api.netbird.io/oauth2" |
-oidc-scopes |
NB_PROXY_OIDC_SCOPES |
The OAuth2 scopes for OIDC User Authentication, comma separated | "openid,profile,email" |