Commit Graph
5 Commits
Author SHA1 Message Date
riccardom c71fd1d841 [management,client] Default to NetBird's upload service when nothing is configured
The previous commit made a peer with no destination — no MDM override, no URL
named by the caller, nothing published by its management server — refuse to
upload and keep the bundle local unless it was enrolled with NetBird's cloud.
That closed the reported data-boundary concern, but it broke the default for
everyone who uploads a bundle as part of their day: a self-hosted user opening
a support ticket got a refusal where the command used to work.

Product decision (NetBird's, not the reporter's): the knob to keep bundles
inside your own infrastructure is what this branch provides, and it is enough.
The default stays the service NetBird runs, self-hosted included. An admin who
needs the bundles to stay in-house configures the destination; until then the
everyday flow keeps working.

So ResolveUploadURL drops the cloud check, the sentinel error and the
managementURL argument, and never fails:

    MDM  >  explicitly named URL  >  published by management  >  NetBird's service

Nothing observable changes for a deployment that configures nothing, which also
removes two edge cases the fail-closed default had: a peer still enrolled on the
legacy api.wiretrustee.com host would have been classified self-hosted and
refused, and an upgrade would have silently stopped uploads for self-hosted
deployments relying on them. The privilege gate is unaffected — a host other
than the default one still requires a privileged caller, so pointing the CLI
somewhere other than what management published needs root.
2026-09-10 16:38:41 +02:00
riccardom 9f6d17b9e8 [management,client] Take the debug-bundle upload destination from management
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.
2026-09-10 16:38:41 +02:00
Maycon Santos 1081ca006d [management,client] Add anonymize level and upload URL to remote debug bundle jobs (#7147)
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.
2026-09-01 11:45:20 +02:00
Viktor Liu feecb993f4 [client] Restrict debug bundle log path and upload destinations (#6975) 2026-07-31 19:12:56 +02:00
Zoltan Papp 58daa674ef [Management/Client] Trigger debug bundle runs from API/Dashboard (#4592) (#4832)
This PR adds the ability to trigger debug bundle generation remotely from the Management API/Dashboard.
2026-01-19 11:22:16 +01:00