The debug-bundle paths that upload without a human picking a destination
compiled the vendor endpoint in: the mobile clients and the desktop UI hold
`https://upload.debug.netbird.io/upload-url` as a constant, the CLI defaults its
flag to it, and the remote job falls back to it when nothing else is set. A
self-hosted deployment therefore shipped peer logs, routes, DNS and firewall
state to NetBird-run infrastructure without its operator ever configuring that,
and had no way to point those paths anywhere else. #7147 and #7153 gave the
remote job a per-job URL and an MDM override, but neither reaches the mobile,
UI or CLI paths, and both fail open when unset.
Publish the destination from the management server instead, on the channel that
already carries stun/turn/signal/relay/flow/metrics:
- `NetbirdConfig.debug.upload_url`, sourced from the new account setting
`debug_bundle_upload_url` (REST + dashboard) and falling back to the new
`DebugUpload.URL` in the management server config, which a self-hosted install
can set once so a fresh account is not left on the vendor default. Both are
validated as https-with-host where they are written; a change fans out to
connected peers rather than waiting for the next login.
- One resolver on the client, `debug.ResolveUploadURL`, used by every path:
MDM override > explicitly named URL > destination published by management >
the NetBird service, but only for a peer enrolled with NetBird's cloud.
Anything else fails closed with ErrNoUploadDestination and the bundle stays
local, which is the behaviour change: a self-hosted deployment that names no
upload service no longer uploads at all.
- The engine keeps the published value (`Engine.DebugUploadURL`) so the bundle
paths, which run off the engine loop, do not have to read it back out of the
opt-in sync-response store.
- The daemon request grows `upload`, so "upload to wherever this deployment
says" is expressible; an empty `uploadURL` no longer has to mean "no upload".
The privilege gate is unchanged and still applies only to a URL the local
caller named — a destination published by management is the operator naming
their own service.
- The desktop UI stops carrying a vendor URL of its own and sends the intent.
Reported privately as GHSA-hf99-43rj-h577.
This introduces a disabled-by-default allow-remote-jobs setting that
controls whether the management server may run jobs (such as debug
bundles) on a peer. The flag propagates end to end: through client
configuration, the daemon SetConfig and Login requests, authentication,
and system info, up to management, where it is stored on the peer and
exposed on the peers API as remote_jobs_allowed. The client refuses any
management-requested job unless the peer has opted in. Because enabling
remote jobs crosses the user-to-root boundary, turning it on requires
privilege, mirroring the SSH-server gate. Administrators can enforce the
setting through MDM policy on both macOS and Windows, and MDM can also
override the debug-bundle upload URL. The change ships policy
documentation and generated profile templates, and adds configuration,
conflict, and enforcement tests covering the opt-in, privilege, and MDM
paths.
This extends the management-requested remote debug-bundle job with two
new, optional parameters. anonymize_level selects how aggressively the
bundle is scrubbed: "default" keeps internal (private) IP ranges
readable, while "strict" also anonymizes private, CGNAT and link-local
addresses; the value is trimmed and lowercased, and an unknown level is
rejected at creation. upload_url lets an operator point the peer at a
specific upload service instead of the default one; it must be a
well-formed https URL with a host, and an empty value falls back to the
default upload server. Both fields flow through the job workload API and
are surfaced in the create-debug-job modal on the dashboard. Validation
is shared so the client executor and the management boundary agree on
what a valid upload URL is, preventing drift between the two checks.
riccardom