Skip to main content

Definitions and marketplace

Everything the agent executes comes from signed definitions. The console makes that auditable and, with the marketplace, extendable.

The definitions catalog​

Settings, Definitions lists every definition your fleet can receive: name, version, the minimum agent version it needs, what it matches, and how many of your hosts currently match it. Click any probe to preview exactly what it does, down to the literal command, query, or path it will run, before anything runs anywhere. The page also shows the publisher key fingerprint the signatures verify against.

This is the "no black boxes" guarantee in one screen: if a security review asks "what exactly does this thing execute on our servers", the answer is a page, not a promise.

The marketplace​

The Marketplace module extends the catalog beyond what Wakora maintains. It is laid out like the Hosts page: a card (or a row) per template, filter chips for the catalog and for the packages you installed, and a click on a card opens the template itself: the exact definition text, what it matches, what it will collect, how many workspaces run it (as a range, not a count), and the Install button. Three trust tiers, strictly separated:

  • Verified: community-submitted definitions that passed review and were signed with the same publisher key as the official catalog. They behave like native catalog entries for everyone.
  • Your templates: definitions your workspace writes (a JSON editor with a live template; authorship is Pro and above). They apply to your own fleet immediately.
  • Community, unverified: templates other workspaces published but nobody reviewed. Installing one shows the full probe preview and an explicit warning, and it applies only to your workspace.

What a template is allowed to do​

Every template declares the capabilities it needs, and the editor shows the line as you type: credentials, running commands, database queries, reading files, network access, device access, skipping TLS verification. Matching a service, probing a port and calling an HTTP endpoint without a credential cost nothing to declare. When you install someone else's template, you grant its capabilities one by one, and your agents refuse anything the template tries beyond the grant with a visible failed check rather than a silent skip. A template can only ever write metrics under its own service name (and the device namespace for device templates), so it cannot pose as nginx or MySQL in your charts. Host-level and APM probes are reserved for the official catalog.

Pinned versions​

Installing a template pins the text you approved. When its author publishes a new version, your fleet keeps running the one you read; the card offers take vN with a diff and with any capability the new version added switched off until you grant it. A template withdrawn centrally for being broken or malicious is withdrawn from your fleet too, pin or no pin: the kill switch always wins.

How custom definitions stay safe​

Custom and community definitions run under the same hard rules as the official catalog, plus an extra trust boundary:

  • They live in their own namespace (community_...), so a template can never shadow or replace an official service definition.
  • They are signed with a per-workspace key; your agents pin that key on first use and reject anything signed differently afterward, so a swapped key cannot inject logic into your fleet. A refusal is never silent: every refused definition reports a failing check on the host that names the reason and the way out (reset the pinned key on that host and let it pin again), and a device that depends on a refused definition raises nobody polls the device rather than fading away unnoticed.
  • The same execution rules as everywhere: commands only from the allow-list, no shell, secrets referenced by name and resolved on the host only, and only within the capabilities you granted. The capability check runs before a probe of any kind starts, so a template cannot reach a credential, a command or a listener through a probe type that the matrix did not foresee.
  • Per-host opt-out stays available: any service, marketplace or not, can be switched off on any host.
  • A published template that turns out to be broken or malicious gets unpublished centrally, which withdraws it from every workspace that installed it, with an event in each.

Older agents that predate the marketplace simply never receive workspace-signed definitions.

Network device definitions composed by the Devices module ride the same workspace-signing tier in their own namespace, with the same guarantees.